Don't Finish Your Software Systems
Since our software systems operate in a constantly changing environment (humans, other software systems, companies) they have to adapt to stay relevant. A bit like the survival of the fittest in IT.
That means it’s pointless to build a system that’s finished since there will always be new features to add, bugs to fix and component to upgrade. What we actually mean by ‘finished’ is fit for purpose (or “good enough”). What fit for purpose means, is something you decide with your team, client or boss (your stakeholders, actually).
It sounds easier than done though, since we programmers are often opinionated and stubborn when it comes to software systems. At least, I am. So when we’re building we might decide that feature XYZ is a stupid idea, so we give it less attention than it deserves or leave it out altogether. Or we follow through with our own idea, which we collectively decided not to implement. This is risky business, because:
- Too little effort means less business value.
- Too much effort means you’re wasting resources.
‘Just right’ sounds easy but it can be pretty hard to get right. Some of the crimes we commit which prevent us getting it right:
- Premature optimization.
- Unnecessary abstractions which complicates the system.
- Polishing temporary solutions.
- Unit testing getters/setters for the sake of code coverage.
- Trying to add value in a field that’s not your expertise (e.g. designing or polishing UIs while having a designer on board).
- Refusing to add value in a field that’s not your expertise (e.g. refusing to test; “I’m a programmer, not a tester”).
- Making risky assumptions about vague requirements.
- (name your own…)
How to get it right?
- Find out what’s important for each of your stakeholders (don’t forget the people who will be operating production).
- Be agile: keep checking if we’re still doing the right thing (the world changes and so do our stakeholders).
- Determine what’s the minimum you have to achieve (call it MVP, if you want).
- You have a limited amount of effort to spend in a set of fields, so determine how much effort to spend on what.
- Find out where the “low hanging fruit” is, these are your easy wins.
- Find out where which areas are risky, requiring an unknown amount of effort and handles these with care.
Remember: you can always spend more time to make things better, faster, safer or nicer. It comes down to the question: is it worth the effort?