Code quality as a winning factor

Software development seems to me like the only discipline where practitioners can get away with producing crap. If you’re a doctor and you screw up surgery or treatment, in the worst case you will kill your patient, in the best you will not make his/her situation worse. If you’re a bridge builder and you’ll make a mistake during construction, in the worst case the bridge will collapse killing people, in the best case, the bridge will be usable only after adding some additional support to it. If you’re a lawyer and you fail to properly drive your case, in the worst scenario you’ll lose it along with millions of €/$ of compensation or lost profits or you’ll cause unjustified damage to someone, in the best, well, you can only hope the fallout will be low.

In all those cases the outside world will know, that you did something wrong. Not in software development. If you produce crappy software, that actually works and fulfils customers’ needs, then the outside world will be happy, …for now. What they don’t realize is that you also produced a problem for everybody. Next time business will ask for a feature they’ll be unhappy because it will take more time than necessary, developers also would need to work with hard to read and maintain code.

I admit we are still, as an industry, struggling to define how to measure code quality. Code coverage is a very bad one. Counting places with DRY principle violated would be a nice one, easy to automate (it is already automated in fact, see PMD for example), but still far not enough. Something that measures how much SOLID principles are obeyed is even impossible to implement, for example for Open/Closed principle it would be necessary to know if and where such openness is desired/necessary. Unfortunately, this lack of a generally accepted way of assessing software quality leads to crappy code.

But we will have to, soon, define industry standards. The reason is, more and more things depend on software. Robert C. Martin writes about this in his blog. Plus we also reached a point in time, where software bugs cost more and more, including people lives, for example issues with the braking system in Toyota cars or Therac-25 radiation therapy machine. If not killing, then causing serious damage from sending companies bankrupt like in Knight Capital Group case to loosing Mars Climate Orbiter. For more just search the web for “famous software bugs”.

Of course, for most developers making a mistake will not have such dramatic consequences. Maybe the application would be just crashing every now and then, maybe a customer will not be able to place an order for half a day or maybe single link on a page will not be working properly. But, unfortunately, most of the time those errors we’re doing will be completely invisible to the outside world, the systems will be working correctly, probably with good enough performance, maybe even with good security. The problem would manifest only when someone would like to change the code. So-called technical debt will be killing productivity, someone would need to understand unreadable code, adapt the code in all those places that seem completely unrelated, yet apparently necessary to be changed, rework half of tests that now started failing for no obvious reason (better(?) case) or write the tests from ground up (worse(?) case). You get the picture.

What I really don’t understand is: why are we doing this to ourselves? It’s us, developers, who need to work with crappy code on a daily basis. Business gets what they need, maybe after delays, maybe it’s a bit cumbersome to use the system, but it’s working for them, they’re happy. What about us? Are we happy with working with our “big balls of mud”, “spaghetti code”, “pieces of crap” or however you’re calling your code? Wouldn’t it be better, that we could work with clean code, simple and elegant, highly cohesive, with concepts clearly separated from one another? Apparently not, I’ve yet to find such a system. Maybe I really need to start reading code, that someone else wrote, just to see how others are doing things. I know this as a good learning technique.

I know software development is far from being easy, and sometimes code gets messy because of lack of skill. In my career, I’ve learned about ideas of clean code or code quality only a few years after I’ve finished university. What’s more, I remember attending a meetup where software craftsmanship idea was presented and, at that time, I didn’t even understand it. Recently I’ve been looking through courses, that my university offers, to see if there’s something related to code quality, but found nothing. Honestly, there actually should be nothing, quality should be built into every course, that has something to do with code! I was happy to find a few days ago, by accident, that there’s an online course on Coursera about crafting quality code. I didn’t check it, so cannot tell how good is it, but it’s there. Apparently, not only people or companies, that are making money out of it, are doing such courses. And I certainly don’t mean they’re doing a bad thing by earning money on this!

It’s all in our, developer’s, hands though, we have the power to change all that. Not only we will help our businesses move faster in an ever-changing world, but also make our life much more pleasant and fun. All we need to do is to finally take responsibility, ownership of what we’re doing. Every time we’re being asked to do something, do it properly, the best we can, not necessarily the fastest, even under pressure. We’re being hired as professionals and experts (and are being paid quite a lot of money), we need to start behaving accordingly. Business expects us to bring good solutions, even if they cannot recognize its quality immediately. This requires a bit of work on our side, but it’s a win-win scenario. Don’t you want that?

BTW, this post was simultaneously posted on two blogs: Zooplus Tech Blog and my private one. Please feel free to go to the other one and check it out!