The Digital Lumberjack

The word quality applied to software is full of false stereotypes and misconceptions. You should blame the materialistic view of other engineering disciplines have forced unto us. People hear quality and instantly they make a connection with high quality materials. All high quality building, car, machines, etc. have high quality steel. The main expectation from a high quality restaurant is a tasty dish with fresh ingredients and from a high quality hotel a big room furnished with luxus furniture.

So what do most people expect from high quality software? Programmers themselves and even IT managers have problems defining that word. In our field, even facing the doubt of what it is exactly, we all are 100% sure of at least one thing: it must be awfully expensive.

Take this further and you will immediately find a division within most IT companies. On one side you have the humble programmers facing all that mumbo jumbo from the QA department made of business graduates, social workers and God knows what other clans who insist in the importance of having the right page margins for their printed test reports. I have fond memories of a QA department that every time, after writing down three remarks forced us to make a new release and rewrite all manual test reports again before continuing with something with so many errors. For these programmers quality is all that nonsense that prevents real work getting done.

On the other side you have the managers, for whom the QA department is the least of their problems. It is usually all that whining and crying about how the code is such rotten ball of mud that cannot be fixed without being rewritten from scratch, or at least some serious refactoring. If the programmer is young then the solution is as easy as dumping evil Windows and alienating with the heavenly light force of Linux, open source software and super powerful language X.

Going along the lines of physical products and classical marketing mindset there is also a disturbing term but very lucrative: software tester. You know, those guys who receive the final product, or something that resembles it, and make sure that the quality is good enough for the users.

All I have been telling you so far is how most people experience and/or approach software quality. In my humble opinion the root of all this evil misconception when adding the word quality to software is thinking in a final product. Software engineering unlike many other engineering disciplines has hardly anything to do with a final product but with a process. The marketing department is the one that give it a face and make it a real product, software engineers only know about a process.

Think for a moment about the term high quality doctor. It sounds stupid and for sure it is a term you would never use. You might prefer a term such as good doctor, but I want you to even think about the difference between a good doctor and a quality doctor.

Quality for a doctor is usually a must and not an option. A quality doctor must find the best diagnostic and avoid spending money on expensive tests unless necessary (pressure of their hospitals and insurance companies). In a battle field they must endure stress, perform with scare resources and still be creative. Outside the industrial world their status and income depends on how long their patients stay healthy. Mistakes can be expensive and when they occur, they come back to hunt them down until the patient dies or sues.

Think about that last sentence. Here there is also a false association with physical products. Everybody knows that a low quality thing breaks sooner than a high quality one. This is also true with software, but there is one big difference. If a physical product deteriorates the consumer must face the cost of replacing it or fixing it. With software it is usually the other way around. Even if the company is not liable for solving the deterioration, its reputation and future sales are at stake. Software erosion cost money to the manufacturer, and this is solved with quality. This is becoming even more critical when most of our industry is switching from the make money selling new versions style to the make money providing a service.

The fact that Software Engineering is such a young discipline make it also more vulnerable to propaganda. I remember as a kid advising my parents which car to buy because the one I saw on TV could go under a dune and fly over a river (even though we did not have any of those around). Since the beginning big SW companies have been bombarding us with their advertisement and how all our problems would go away with their tools, languages and methods.

These days I am relieved that Unix came into existence and brought some freedom and common sense into our world. I am not only thankful because of the open tools but for the freedom to combine them, scripting, functional programming and above all a mindset looking for an alternative way of doing software beyond pure OOP. If you are old enough, you might remember how much money and obsession was placed into awfully expensive tools molding you into UML, one single language and one single OO programming style. If so, you will have noticed that today we face far less advertisement for software building tools. Our profession is evolving and we no longer have to pay for expensive tools (although there are amazing and unique paid ones).

One thing were I do not agree with most people is that high quality software must always be well tested and well document. Personally I believe that real quality lies in the balance between minimum cost and maximum profit from the economical and user experience point of view.

Most software projects are just trials to see if they work and can be sold. Here you can loose your hair and go wild for a while to see if it is really viable. As soon as you see a future, start taking more serious your process. So no, no that lovely documentation, automation, lovely UML diagrams and testing from day 0. Mmmm, maybe the UML diagrams could be ignored even when so many people insist they are a trait of high quality.

Although being a TDD believer, I am OK with non tested prototypes. What I am not so OK with is that awful false delusion of working during months or years without tests or documented code because it is just a prototype. The story goes like this:

No, we do not care about X because we just have a protype
(any pointy-haired person at this very moment)

Suddenly one day some manager from high above commands a day of work for the removal of the word prototype in all the documentation. This achieves in less than 24 hours the final product ready for testing and finishes the excuse for breaking all the broken software engineering rules and the crimes against science, software and above all, that group of life forms called programmers. So you see, at the end they are not liable to be sent to hell, sorry.

A prototype is code you throw away and only reuse what you learnt from the problem domain, that is, requirements and design. Even if you write it in something as low level as C++ or Java it is probably not a prototype.

High quality software uses continuous refactoring because of software erosion. Sadly when many people hear that word, the first thing that comes to their mind is a whole new fork that paralyzes the project and a bunch of programmers adding spaces to perfectly align their comments, painting nice diagrams fulfilling their UML porno with object-oriented-pattern fantasies.

There are far more refactoring patterns than the famous 23 object patterns. Halting a software project for more than a couple of days to improve something is not refactoring, it is a crime and the symptom that something really bad is happening.

Software quality is not something that must be sold or produced at a high cost. If you spend more time automating, writing tests or thinking about the problem than it is really necessary you got it wrong too, that is not quality either.

Software engineering is all about the process of building software. Since the user do not get the process but the result, software quality is something that mostly affects the manufacturer.

High quality software can be sold cheaper and adapted faster than the one of your competitors. The choice of technologies is realistic with the market and available pool of engineers.

Managers must find out which complains of their programmers are really necessary, but never ignore them completely because past the big ball of mud and garbage the next stage is the one of the big nightmare: Everything is so messed up that only the veteran programmers can understand the project.

If a programmer cannot be replaced or rotated at a reasonable cost, it is not quality software. Are you telling me that I need more than one month before I can do something useful for the project? Then the software quality really smells bad.

Projects in the nightmare level stage are burn out projects where programmers are constantly complaining about their life at work and specially at home. Managers should work hard to avoid this, because reached this point it is hard to find people who want to stay. The best guys fly away, and you are left mostly with the ones who do not care if the software breaks every day and new bugs cannot be avoided. The whole story about a minimum design, structure and quality is also to be able to hire and retain good workers.

Real quality is a combination of intellectual and creative work balanced at the lowest price possible to attain something reasonable, so please, starting today stop thinking that high quality software is something necessary expensive, it is just something awfully hard to achieve. Or do you want me to explain to you now what is a high quality painter?

Related Posts

• 01 Feb 2012 » You Are The Evil One
• 22 Nov 2011 » Your Credit or Your Life
• 17 Sep 2011 » Apple's Dirty Secret