I strongly consider that the following three items are of high relevance for software project quality:
- Developer workplace conditions
- Tracking data of past projects
- Management commitment to quality
In this article I will give an overview of them, providing some personal experience about each.
Developer Workplace
Enhancing the workplace of software developers, is an often overlooked fact that has to do with both human resource management and quality management; both aspects are affected when working conditions are not properly met.
The classic book “Peopleware” focuses on the problem of the inadequate developer workplace. DeMarco and Lister correctly point out the highly intellectual nature of software development, and the fact that the most successful software companies are those that provide developers with quiet workplaces.
“Open spaces”, in this sense, are one of the most important reasons to blame for low output quality, and if I have to refer to my own personal experience, I can only confirm this fact. The places where I have been able to deliver my highest quality work are those where noise, interruptions and distractions were reduced to the minimum. This allows developers to reach a state of “flow”, where the notion of time seems to disappear completely.
In this state, the level of concentration is maximum and the quality of the work is usually the highest; software developers are able to handle in their heads lots of elements, that have not only to do with the lines of code that they are currently editing, but also with their relationships and dependencies. This notion of “dependency” is key to software architecture and development, and the best software developers are those that can hold and remember the relationships between the current lines under their eyes and those in other modules, so that they effectively reduce coupling and the risk of bugs, while enhancing encapsulation and reuse, all factors that have to do directly with the quality of the code produced.
Moreover, good working conditions reduce turnover, which is one of the most extreme, expensive and feared forms of corporate memory loss.
Past Project Data Tracking
Smart companies have good memory. They are able to tell, from past projects, the rate of success and failure, the context, the errors made, the level of accuracy of their methods, and the success rating of the most accurate analysts. All of this, when systematically stored and retrieved, helps organizations to have a higher level of quality, since from the very beginning they can tell what works and what does not work. “Been there, done that”; not all corporations are able to say this phrase.
I have worked in companies of both kinds, and I can say that the level of “corporate awareness” helps a lot to define project plans and to make good estimations for projects. For every project, a database of similar projects, coupled with experienced teams helps making good decisions in future endeavors. These good decision have a direct impact on the perceived quality of these organizations.
Management Commitment
One of my past employers was certified ISO 9000, while another was going through the evaluation for some CMMI certification. And I can tell that certificates are worth nothing if the management does not have a strong commitment to quality.
In one case, the ISO certification was only a way to attract corporate customers, and nothing else. There was a bunch of quality procedures stored somewhere in a closed intranet (to which strangely enough, developers had no access). There was a “Quality Manager” that knew next to nothing about the day to day job of consultants. There was a complete lack of professionalism from the project managers, who relied upon the ignorance of some big clients to get contracts and some cash. That was it. Oh, and we were told, once a year, to be kind to the ISO people that came to verify that the quality procedures were still in place, in order to renew the certification (this is absolutely true). All of this impacted our day-to-day work enormously, needless to say, since the image we got from our managers was that quality was only good for brochures; interacting with them was far from pleasant, and the output of our work as teams was less than desirable.
On the other company, they had set up every possible practice in the road to certification; just to give an idea, their product consisted of a couple of million lines of source code, which were built every night, with thousands of unit and functional tests run automatically after the build; reports and API documentation were created automatically and dispatched to key stakeholders; daily stand-up meetings were held every day; internal training done every week; and the first person to follow all the guidelines and principles was the CEO, who happened to be also the architect and the biggest committer in the source control system. New features were evaluated by senior members, and change management procedures were religiously followed. The commitment to quality goes up and down the hierarchy levels as I had never before seen it, but with a strong example set by the upper levels. The quality of the source code is unparalleled (the product is 10 years old already), and I think that those who worked with complex system know how important is, for maintenance, performance and readability purposes, to have strong quality standards with it.
As in other aspects of project management, the commitment of upper levels of the hierarchy is fundamental for the quality of the final output as well.
Conclusion
Having better working conditions, with a management aware of past project experiences, and commited to quality enhancements are important factors, that can impact positively the final quality of a project.
References
Tom DeMarco & Timothy Lister, “Peopleware - Productive Projects and Teams, 2nd Edition”, 1999, Dorset House Publishing, ISBN 0-932633-43-9