Over the years I have been in a multitude of software development environments, and bar none, the biggest reason as to why software projects fail can be overwhelmingly attributed to quality assurance. More precisely it is either the complete and utter lack of a QA process (let alone a team), or simply the absence of sufficient testing procedures.
Quality of software isn’t simply the fit, finish and packaging. It is a whole encompassing methodology through which the program(s) involved are designed, revised, (when the time comes) patched, and upgraded. It has been a long held observation of mine that coders in general don’t think of QA for several reasons.
◊ They feel that their programs were well designed and that they’ve accounted for all scenarios.
◊ The program(s) is/are too short to possibly have any error(s).
◊ They can be their own quality/testing department.
◊ They can/have figure(d) out all the necessary permutations of possible interactions that user(s) would possibly consider entering.
◊ There is no budget, nor push for a proper QA department and/or QA procedures.
While the above is a very, very small subset of all the possible reasons that I’ve seen/heard, the reality of it is that these are being given as actual excuses when confronted about what QA processes are in place. The reality of it is that there are a lot of substandard, unprofessional software developers out there, who despite all the best practices of established community acknowledged developers and software engineers, continue to believe that it isn’t worth their time.
The outlook is sadly very grim from where I stand. All too often there is considerable resistance from management, and more so from other coders when the topic of writing tests first, something we have been reminded of recently from (most notably) XP and Agile development circles. Managers don’t want to waste time on a tight deadlined project writing code that will never make it out of the door and to the customer(s), and other coders in so many situations feel it is boring and unnecessary.
The reality of it all is that those mentalities doom its transgressors to a endless of cycle of bug chasing and failure. The impression that the end-user/client receives of a given software firm/group/coder is based almost entirely on the quality of their work, but there simply doesn’t seem to be the necessary forethought by those responsible to make the decisions toward quality.
Quality isn’t simply a department which points out and/all flaws in a product, and quite frankly shouldn’t be taken as such. Coders, particularly bad ones despise a proper quality arrangement because it points out all of their flaws without ever really providing an equal amount of praise. Developers as a whole like to hear positive affirmation about their work. The code produced as, such as an artists, an extension of their being, and thus hearing about problems with their work, they all too often take it personally. They see it as an attack on their character, and that which makes them who they are. This is something I would expect of a child, but not a professional.
It doesn’t have to be this way. We as a collective group of software developers, engineers and architects are the ones responsible for ensuring that quality of not an afterthought. We have to make it a priority to build quality into ever facet of not only our software, but every facet of our varied processes. The size of the application is immaterial. Whether a simple shell script, or a half-billion lines of code suite, the same level of attention to quality is a pre-requisite for success.
This includes the planning process as well. Writing tests before actual code is produced is wonderful, and needs to always occur. This requires discipline, which many seem to lack and/or overlook as a legitimate need. It goes further than that though, all the way to the planning stages. What is the point of having a high quality-focused mindset at the code level, if the project itself is lacking the same on so many other levels.
We need to demand this mindset from the get go. It is our responsibility to ensure that the necessary practises are put into place from the beginning, because no one else is going to care, let alone take the initiative. If you take pride in your work, you need to ensure that it does as it is/was requested, and that requires the right methodology as well as mindset. Not to imply that our lives depend upon this, but in reality it does.
It isn’t as if all of this effort isn’t without reward. We need to teach the next generation of coders to start with quality as their foundation, and it will simply become a ubiquitous piece of the process. The benefits of this holistic view are many, and among them are:
◊ Stable code
◊ No surprises
◊ Happy clients
◊ Time to work on the next big thing (tm)
◊ Less stress
◊ Future business
◊ Peer appreciation
Quality is everyone’s responsibility, and that means it has to start with each individual, no exceptions. So if you, or others which fit the bill as prescribed above have hangups on this issue, then it is time to think long and hard about it and either hangup your coding chaps, or take that next step and better yourself in your field, kicking your
In future editions of the codedevl.com journal, I will be taking a more detailed look at each of the phases of the quality aspects of the software life-cycle.
No comments:
Post a Comment