Self Indulgent Engineering
So, my last post was about Over Engineering and I want to maybe go over a couple of more points regarding this. Hopefully this could help teams and engineers recognise when over-engineering is taking place and give them some guidelines for when to take a step back.
I was having a conversation with a colleague about my last blog post and he compared it to musicians who are playing simply for themselves. “Self indulgence” I said, he agreed. And it’s 100% correct.
I have been thinking this more and more as of late… over engineering is sometimes software engineers way of showing off. Like everything there is a time and place for that. Circumstances where that cannot be the case:
- When a project has overran and behind schedule.
- When trying to deliver an MVP feature/product, these things are about testing hypotheses, validated learning and failing fast.
If a project is in no-man's land and the team are struggling, its far more valuable to the business to have the product/feature/tool to be functionally complete than it is having beautiful code. Sometimes, if we catch yourself refactoring over and over, we need to ask “does this need to be done now?” and if the answer is no, don’t forget about — add a tech debt ticket. There is no shame in having tech debt (I will talk about this in a later post). This work can be prioritised by the team and not a single individual wither how important that refactoring is. Also, once the project is complete the team could try and argue for a week or two of cleanup time.
Minimum Viable Product, this isn’t about having the sexiest code, this is proving a theory e.g. Will someone buy a subscription for our new product? It’s key in these times to fail fast. If you find a team member refactoring, or trying to optimise early, stop there. The product is more likely to be shipped out, and have very little traction (a little depressing but it’s true), so wait until you have signs of success before you start pleasing oneself.
Overall there are times to write some gnarly code, research, personal projects, and I’m sure others. But in these aforementioned scenarios I find it best to Keep It Simple, Stupid.