Software quality, unlike beauty, can be measured and quantified. There are basic tenets in place - like maintainability, portability, scalability and so on. Somehow that notion has been completely replaced by over emphasizing on the form rather than the substance. What do I mean by this?
I was recently involved in a project executed by a CMMi level 5 company. The code was written in 2008/9 and the project went live in June 2009. In March this year the client wanted to do some enhancement work on the system. I was asked to come and look at the overall architecture of the system.
What was startling was that this project was executed by one of the largest and most prestigious IT vendors from where I am from. To start with, the program was delivered in 2009 with many bugs, had 13 *.sln files within a single system, 7 databases and 17 web-service solutions. My first reaction was - what is going on?
Soon I realized what the true problem was, the Internal QA was obsessed with the Project Management Plan ("PMP"), the Project Manager was scrutinizing the schedule to the last detail and the users were obsessing over the specification and nobody actually bothered with the real fundamentals - building software solutions that actually work.
While it is great to have a quality process in place - it is an unforgivable sin to compromise on the basics - code quality and design principals. The lesson learnt is that improvements in the maturity models such as CMM or CMMi's without corresponding improvements in the software quality assurance process can be counter productive.
Ironically, improving the process of poor coding standards makes the software quality unbearably lousy.
One of my first year University books was entitled, "The Arts and Science of Programming." Now, would you put Da Vinci through the CMMi process? I guess not....
