I’ve been thinking on how we rationalise different kinds of development tasks that engineering teams get up to.
For example, critical bugs absolutely need to be fixed now. Product features and improvements satisfy our customers who pay the bills that keep the lights on. We’ve even made strides in substantial classes of Tech Debt in terms of an on-going operational “tax” of sorts.
But what about the category of tasks that atones for the sins of the coders past, particularly in legacy software? Contemptible modules that lurk within the monolith? Arcane relics that work, but make the team feel less-than-proud to be custodians thereof?
It came to me in a random exchange:
“there is great value in not feeling ashamed of the code that we work on”.
My proposal is an epic# called the “Grimace Epic” for a category of work that helps engineering teams feel less 😬 of our creations. Work that reduces cognitive friction, increases happiness (and therefore productivity) and inspires a team to take greater ownership, pride and care of the code that they tend to.
The Grimace Epic is an acknowledgement that instinct and emotions play an important role in the creation and operation of software. It affirms that software engineering is equal parts art and science – just because something hasn’t been priced doesn’t mean it doesn’t have value.
This is not to say that we should just go by our guts, throwing all logic and reason to the wind. On the contrary, I expect that the true value of such work to be discovered retrospectively, so that the wisdom (or folly) that was once instinctual would be incorporated into the greater body of software engineering knowledge.
# In JIRA an Epic is a common mechanism that teams use to categorise development work. The terminology is also pretty… epic.