Is it more important to build the right software or more important to build the software right? The lazy answer is something like “…they’re equally important…”. Let’s not be lazy. Let’s think about this.
Build the Right Software
You can build the world’s best software system but if it doesn’t do what the customer needs, you’ve wasted time and money. For example, if you’ve built a system to generate comprehensive enterprise reports but the customer needs a system to do big-data analytics, you’ve failed. The reports may be easy to create and a pleasure to read but without the big-data analytics piece, they’re lipstick on a pig.
It’s astounding to me that this happens as often as it does. Everyone seems to think they understand what the “right software” is and what it needs to do. Yet when the system is ultimately delivered, key stakeholders conclude that critical features are missing. Then the blame game begins.
Build the Software Right
The other perspective is building the software right. Software that does exactly what the customer needs but is unreliable, fails. If the system was built is such a way that it’s slow and crashes frequently, no one will be happy. It’s great that it solves the specified business problem but if no one can effectively use it, what’s the point?
This too happens far more often than it should. There’s a joke among software developers who say “It works on my machine.” Just because the software works well in controlled environments like development and QA doesn’t mean it will work in real world environments.
There’s No Simple Answer
So which is more important? Would you rather have good, reliable software even it’s missing critical features and functions or poor, unreliable software that includes all the things you need it to do?
It’s clearly a rhetorical question. You’d need a lot more information to answer it. What features are missing? How often does it crash? Can the missing features be added quickly? Can the software defects be fixed readily? Of course, most delivered software systems fall between these two extremes — some features are missing and some aspects of the software are unreliable but, in general, things usually work fairly well.
Here’s the problem. When features and functions are left out — completely left out as in no one considered them — adding them to the system after delivery may be an incredible amount of work. The software may need to be deconstructed and rebuilt to include the missing pieces. Imagine building a house and failing to include a bathroom at the far end of the structure. Carving out the space and running the piping could be an enormous job. It would have been simple when the house was merely a shell, but not now.
Reliability problems discovered late in the effort are not so easily corrected either. I’ve seen software systems taken apart and reconstructed to resolve performance problems. I’ve seen defects that appeared to be minor result in major changes to the code. Imagine that bathroom again. If the plumbing and electrical services are inadequate to meet the needs of the bathroom fixtures, major rework will be needed to upgrade those systems. It will be highly disruptive.
You Can Have It All
It appears that the lazy answer — “…they’re equally important…” — may be the best answer. We need to define the software right and we need to build it right. Ultimately, it takes both to deliver great software.Why settle for good or adequate when you can deliver great?
How do you do that? Follow basic agile development principles.
- Be sure that the business and technical teams collaborate early and often.
- Deliver working software regularly and schedule formal review meetings to get feedback.
- Expect changes and be open to new ideas.
- Study software frameworks and good design practices. Use them!
photo credit: marsmet471 via photopin cc