There is an adage in software development:
- First you make it Work
- Then you make it Good
- Then you make if Fast
Of course it is not always that straightforward. It may not be good, if it is not fast. And it may only be possible to make it fast at the expense of making it good.
But that does not mean it is not a useful way to describe the process to someone who is not experienced in the suffering of the average software developer.
What is often missing in the explanation to the non-experienced manager is that the time between each of those steps may be double the previous.
Imagine a form where a user is going to enter a delivery address.
A basic working version may have all the necessary fields, a name, a couple of generic address fields, perhaps a city, county, postcode and country. It will save to the database on submission.
But making it good and making it fast require significantly more effort. Addresses are complex. Maybe some form of postcode search or global address autocomplete would be better, but that's a big database to manage yourself. Validation sounds easy, but not every country has postcodes. And even searching for your country in a list is a pain if you have to scroll through a lot of them just to find the United Kingdom. Perhaps the most common countries that use your website should go at the top.
There's lots of little decisions that make it good. And some skilled technical know-how to make it fast.
When you want me to estimate something, is it just to make it work? Or do you want it to be good? And if you want it to be fast, then how long have you got?
It may take a week to make the feature work. Two weeks to make it good. And four weeks to make it fast.
The quality of a software product is often determined by which of those the manager is willing to bear.
And the quality of a software developer is often determined by how much they care about making it good.