Axioms are self-evident truths. The axioms of Software Development isolate key basics underpinning successful software development. These axioms build on each other. Understanding the first one will aid your understanding of the subsequent ones. This is part of the series on the Axioms of Software Development. If you haven’t read the previous axioms - you can see them here.
It’s my aim that by helping you understand these axioms, I can help you resolve problems associated with coordinating developers, time and resources and ensuring your software project is successful.
7. Prefer Stability Over Features
The theme here is that you need an application that performs the core features well, not an application that does a multitude of functions in a really buggy way.
Nothing will turn off end-users more than an application that can’t do what it says it can.
This comes back to that first axiom - desired features will always exceed available budget.
So, you really want to identify: what are the key aspects of this app that absolutely need to work? This is sort of a Minimum Viable Product. And then focus on the points that make up that MVP. Really it comes to the desired features exceeding budget idea and getting those critical items out first.
But it also comes into play when you launch. Just because you’ve built a feature doesn’t make it stable and usable, and it doesn’t mean it will perform under load.
You need to build in some time to go and do some bug fixing because it doesn’t matter how well you develop, you will always find some bugs in any software application, it’s just inevitable.
In many cases, bugs are just unimplemented features.
An example I ran into of this was relating to recording a value over set periods, and changing the frequency of the report.
When first building it out - you enter a value every Friday and the application takes that value and saves it. On a weekly basis you could look at a graph and you would see the average value increase or decrease week-on-week. It would look correct.
But, then you realise there is a benefit to viewing this information with monthly totals. So, you filter the values and take the sum of values recorded in April as one data point and the values from June as the next data point and so on. But wait, every second month, it seems like there is five times the average weekly value instead of four times. You realise that it doesn’t look right because in April there was less activity, but the value is higher.
You ask the developer why this anomaly, and they say “Oh, that’s because we are only recording the value every week and in April, there are five Fridays but in February there are only four. And the extra Friday that is in April is just the first day in April, so all the values of the other 6 days that make up that week are being counted in April, when they really belong in March.”
Immediately you think - that’s a BUG! This is unusable. We must fix it! It is stupid.
Actually, no, it isn’t a bug, it is just an unimplemented feature. The unimplemented feature is when you are entering a weekly value, if that week spans two months, the system needs to be smart enough to recognise that and ask the user if they want to split the value over two months.
This is where you might start to look at bugs and features in a new light.
Sometimes there are genuine bugs, the system is simply doing the wrong thing.
Usually it is because the feature has not been developed enough to handle the edge cases of the real world. Software is generally an attempt to replicate the real world and the real world is not black and white. There are lots of grey areas in the real world.
So, software has to have ways to handle that. A computer can’t intelligently figure it out on its own, because a computer is not intelligent. All computers get any apparent intelligence from their Human creators.
So, it is ideal to prefer stability over features wherever possible.
This isn’t to say that everything should be perfect before exposing customers to your platform. There is definite value in the idea that: “We need to get something running so that we can get some traction.” But, just be aware if you do a push to rapidly get some features out, you need to include in your plan going back to pay down that stability or technical debt on the project and make the features more stable.
On my own software-as-a-service projects, I regularly tell my developers that I need them to spend three days fixing whatever they know needs fixing. Go to the bug tracker and close off some bugs, do some re-factoring for performance or stability.
If your developer knows their stuff they will know the bottle-necks in the system that need the architecture tweaked a little, or code that can be cleaned up to be more efficient and stable. I tell them to go for it.
Every bug to a developer is also a stability issue and something that they don’t like and want to fix.
Are These Axioms Helping You?
I hope you are getting value from these axioms. Please send me through your feedback and thoughts.
