The quality paradox in software products
While working as a software developer I’ve been more or less accused of: “focusing too much on quality”, “polishing too much”, “overanalysing”, “not letting work go”, or “lacking in commitment”. As you can tell, by reading the previous sentence, the level of crap in the statements tends to rise towards the end, culminating with crap project managers utter after 4 failed sprints — hail SCRUM! I ended up calling myself a software over-engineer, to set expectations from the start.
Anyway, it’s that over-engineering that constantly drove me to think about these questions:
Is quality important in software projects? What does quality mean? For who? Who should care about quality and who actually does care?
So the internal committee, in my head, started debating and they immediately started taking sides. Half of them were saying that it is not. The other half, that it is.
So this got me thinking even further:
Does it make a difference to the end user if the code is shiny? Does it drastically improve their experience with the app?
It doesn’t! If the app is loading reasonably well, with minor cache-related bugs that can easily be fixed by the good old page refresh, then it is O.K. . My performance optimizations, spread operators, destructuring and other wizardry are of no use.
Are code quality and performance valuable at all? Are they just excuses for developers to indefinitely polish a feature until it matches the divine version proposed by an arbitrarily-chosen style guide, from a company that can buy your whole team with the money they spend on a week’s worth of company-paid lunches?
No, they’re not and yes, they are!
Performance optimizations and code quality are of no value, by themselves. They might prove valuable to you, but if the client has a team that maintains the code, unless you’re using their style guides and toolchains, then you’re already doing it wrong, at least in their perspective.
And even if you do use everything the client’s team is using, some of them might quit by the time you hand over the project. New style guides appear. You’re still not delivering value by investing in code quality alone.
The paradox is that there is tremendous value in code quality, and performance optimization. Even in the exaggerate kind! It’s not end-user value, though, it’s client value.
But there’s a catch! They’re not valuable by themselves.
It’s not obvious why you should focus on higher quality, of course. Why should you get your team not just to “ship faster” but to also “ship better”? Some may even argue that it’s implicit that you give a quality product to your clients. To that I say: “You’re totally right!”. You are currently providing the quality level you have in your team. My plea is that you invest more time, on your part, not only in learning to write clean code, but to learn techniques that drastically improve product maintainability. To use patterns that are suitable for the type of business the product serves, to focus on the type of developers that usually work on products in that area and to try to emulate their coding practices and patterns so that hiring is easier for the client, if the need arises.
These are the “premium features”! To savvy clients, this is pure gold.
Of course, the first time you mention this during client discussions you might get some weird stares. It’s obvious that you need to get the client to buy in on this type of quality, if they’re not used to it. But if your client is supposed to maintain the product you’re delivering, internally, and for an indefinite period of time, they should be aware that paying extra for the premium polish and the wax might goes a long way. Especially if the whole livelihood of their business is going to depend on the product you’re shipping.
So next time you think about quality, don’t just think about neatly aligned properties and values, in an object literal. Don’t think about writing lines of code that are no longer than 80 characters. Those things should be implicit, we have tools for that! It should be second nature to you. Think about the ways you can help your client in the long run, to operate, enhance and ultimately get their money’s worth, out of the products you build.
Cheers!
Image credits