Quality is something we all look for in the “shelves” today, be it physical or digital. The best television, the best car, the best clothes, the best education, the best trip, the best book, simply the best “put the name here”, we can even go further and talk about the best experiences and feelings.
And what does this all have to do with programming? Cars are getting self-controlled, houses are getting smart, planes have auto-pilot, robots are getting better, virtual reality is starting to flourish, health systems are becoming computer aided solutions. The list goes on beyond our imagination.
Ok the connection of where I want to get is still not written, since technology is everywhere and programming is the basis of it what happens if our code is poor in quality? Hope you’re not in the plane in which you made that “workaround”.
Now you probably got it, I’m talking about code quality. The kind that should make us all want to talk about but seems to give shivers instead.
Quality in software development compete to a full set of solutions beyond writing unit tests.
- writing clean and understandable code
- writing concise and meaningful code
- writing code under best design and architecture practices
- covering your code with unit, integration, behavior, UI and other pertinent tests
- putting your software under continuous integration and continuous delivery
This list relates more with the technical aspects of software quality than anything else. We could talk about user experience quality above profitability, but that would be a theme for another post.
And if you know what I’m talking about then you know where the shivering comes from. Although I would love to say that any professional working with software crafting cares about the output of its products and the impacts in its users’ lives I would be lying if I affirmed that to be always true, and even when it is true there are degrees of responsibility implied in the truth.
The problem is so deep that sometimes asking for people to follow a code guideline, to write new variables to keep everything named correctly or to pay attention to business rules sometimes almost causes a full fledged war on the subject. Most of the conflicts come from the first 3 points and the reason is that those points are mostly relative to preferences and community/company guidelines.
And pay attention when I say mostly relative, besides the characteristics sometimes seeming like preference, in general there are reasons why we choose to do things in some ways.
One of the best and saddest examples of it is this apple bug generated because brackets weren’t used in an if instruction. “But that is an isolated case right? Was just one’s incompetence right?”, sorry to say NO. If you look into the internet you’re going to find a bunch of those situations, where the lack of quality turned out to be a huge problem.
Pause for a minute, what if that mistake makes a plane get out of route? What if it was a robot-assisted surgery failing in a middle of any surgery?
Now that is my point, no quality decision is as stupid as you think.
Yet is there a point where it is too much? Yes there is, when things get overrated, a burden, a problem, inconsistent or out of control.
You should try to fit guidelines to your reality, but remember working quality software is the goal, do not soften things just to shoot down the conflicts or challenges. Eventually things will start to get better, way better than before.
So, in order to start the journey on quality an initial point must be set, this time the focus will be precisely to attack writing better code, but instead of extending the discussion some references are left bellow
- Clean Code Episode 1 by Uncle Bob <- Must watch!
- Clean Code: A Handbook of Agile Software Craftsmanship
- The Clean Coder: A Code of Conduct for Professional Programmers
Clean code always looks like it was written by someone who cares. by Michael Feathers
The ratio of time spent reading (code) versus writing is well over 10 to 1 … (therefore) making it easy to read makes it easier to write. by Robert “Uncle Bob” Martin