Much has been said about quality of software, and even more attention has been given to it. Further, a lot of methodology, and general how-to-do-stuff from project management to code implementation, even design and testing is focused on quality, including the ubiquitous “best practices” and framework collections out there. But then it struck me. All the software i “actually” work with is buggy.
It’s good enough, get’s the job done and i live with it, mostly. And like any good web-theme, the software will be replaced (read: recycled) soon enough, so why the big fuss about quality anyway?
If you got a good idea, get it out, sort the bugs out later, and if your idea is any good, you’ll break even before you manage to iron out most your major bugs, by which time it won’t really matter anyways. Uhuh, i hear a lot of “but that won’t work with real business software”. Really?
How many projects you code, pick up, migrate, port, patch, fix, debug or rewrite because business was complaining that they were (now) “too buggy”? But they were using them, right? And probably surviving pretty well with the “broken software” since now they can afford a software team to code, pick up, migrate, port, patch, fix, debug or rewrite. And the job would be done “ok” except that now, quality is an issue.
Reactionary management has a lot to do with it, but it leads astray and breeds a buzz which forges a plethora of blogging on delivery quality, all under the guise and good name of “it’s what the customer wants”- which they do. But not actually :p
When last did you use bug-free software to pay the rent?
Disclaimer: naturally, this is not a call to “down with quality”, or even “forget about tests”. it’s just a very radical and extreme (for me, at any rate) reflection on the focus we give to quality. For one, i groove on quality 🙂 while at the same time i can secretly admire that *some* manage to manage buggy software better than they can actually write it 😀