Software Development Quality

I came across this mind map in a post on Twitter (I’ve tried to find the original again to credit the author, but no luck), and it changed how I think about what to work on first when I build software.

Before this, I never thought about priorities at all. I just built things, and I kept falling into the same traps. For example, when building a data pipeline, I’d get obsessed with performance and spend my time making a job faster. And when building a web app, I’d get obsessed with the UI and UX instead, so the layout and how it feels to click around got all my attention.

Neither of those is wrong to care about. But while I was deep in one branch, I’d forget the tree had any other branches, and this picture made that obvious to me the first time I saw the whole tree laid out at once.

Performance is one branch out of eight, and usability is another one. The two at the top, functionality and reliability, are the ones everything else depends on. A pipeline that’s fast but produces the wrong numbers is worse than a slow one, because people trust its output and make decisions with it. And a nice-looking web app that falls over the moment someone uses it slightly differently than I expected isn’t done, no matter how good the screenshots look.

So now the order in my head is roughly this. First, the software does the right thing, completely and correctly. Second, the software keeps doing the right thing, which means it tolerates failures and I can recover from a break. Only then do I get to everything else, including the parts I personally enjoy the most, like making it fast or making it pretty.

If the map looks familiar, it’s very close to ISO/IEC 25010, the standard software product quality model, which has almost the same eight characteristics.

It’s a simple picture, but it set up the mindset I build software with now. Before I start optimizing or polishing anything, I check whether the first two branches are actually done.