On my terms

Quality is one of the most talked about, and yet the most ignored aspect of software development through out the industry. Organizations take a lot of efforts to create a buzz about the quality of delivery. In one of the software companies that I worked for, every week someone from HR would put up a new poster in each employee’s cabin, featuring inspirational quotes about quality, and it’s benefits. Such efforts do create awareness, but rarely do they translate into the production quality.

One may wonder if quality is just a nice to hear thing, or if there is a tangible definition to it. There is of-course no common definition to it. Quality means different things to different people. For some, it may be about a polished & chic user interface, for some other it may be low memory foot print & zero leaks, and for some others it may be just about the number of bugs filed by the quality team. It is not essential to have a common definition of quality, but what is essential is to have a definition - to each one his own.

Quality has very commonly been seen as an outcome rather than as a process. All the examples stated in the last paragraphs are the outcomes of the development activity for a software. They are just ways to quantify quality. And more often than not, that is where the story ends. Organizations follow rapid development models, with minimal thought. The understanding is - time not spent on coding, is time wasted. They would make the software in what they think is the minimal possible time, and would then devote the last phase to quality by fixing as many bugs as possible. And that is what they call making quality software. What this process conveniently ignores is that quality is not a top-down process, it is bottom-up. In a top-down process, one just makes sure that the software works at least in scenarios which are important by putting patches, hacks or whatever comes to rescue. The result, as you can imagine, is that in every two-three releases the entire software gets scrapped and needs to be rewritten so as to accommodate the new requirements.

Software development has been plagued with the can-do approach for a very long time. Anyone reasonably comfortable with the programming language constructs is considered fit to write software. How can one believe that a few programming courses can make someone a programmer. This is like expecting the leadership courses to actually produce great leaders.

Then there are some really disastrous myths that exist.

• Adhoc development can help you make a quick prototype. Oh, I see people doing this all the time. They write the code in a day’s time, try to make it work for the next 2 weeks, and then spend another month to accommodate a requirement they forgot to take care of. And still the program crashes, if one clicks on a button in quick succession.
• A well designed software can not run fast. Ahh, as if the software gives you extra credits for reckless programming.

Disclaimer: This article is not intended to preach a way of programming, or to define quality. It is just a plea to care enough to think before churning out code. A software can do much better with a fewer lines of code put at the correct places.