The Biggest Problem in Software Development

A long time ago, someone asked me in an interview: “What is the biggest problem in software development?”

It was a broad, open-ended question. I gave an answer at the time, though I honestly cannot remember what it was. What I do know is that I would not give the same answer today, being older, having seen and experienced more.

The biggest problem I can see now is poor end-to-end quality management.

Too often, decision-making happens too early, when the least amount of information is available, and quality feedback arrives too late, when the cost of fixing problems is at its highest.

We should listen to L. David Marquet

“Push authority to information, not information to authority.”

People making architectural or technical choices at the start of a project rarely have the feedback loops to know if those decisions will hold up in real-world use. At the same time, quality checks and issue detection are often delayed until testing or even production, when fundamental flaws have already been baked into the system.

Quality needs to be built in from the start rather than checked in later.

Decisions should be made as late as responsibly possible, using the best available information, by those who possess that information. At the same time, feedback should move earlier in the process to ensure quality is continuously improved rather than patched up at the last minute.

As W. Edwards Deming put it:

“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product.”

The same principle applies to software. No amount of testing, bug fixing, or late-stage process improvements will save a fundamentally flawed system. If we want better software, companies need to rethink how they manage quality across the entire development lifecycle.

“Build quality in” is on everybody’s lips today. And yet, so many companies don’t do it.