This is my personal thoughts, opinions and musings place. I will also rant about things, especially politically-correct things that irritate me. And sci-fi. Did I mention sci-fi? There'll be lots of sci-fi stuff here. And movies, too. Mmmmm... Movies

Wednesday, March 30, 2005

CMM, and the world of tomorrow!

CMM, or the Capability Maturity Model, is an international standard that will help you, the software developing public, produce better software faster with fewer defects and make the customers worship the ground you float on! Or so it is claimed.

To sell you on all this, the people with a stake in this sort of thing(the instructors and Process Department heads) will dazzle you with all sorts of charts and graphs, each claiming how much more efficient and error-free your software development cycle will be if only you would implement CMM Level 2, followed by Level 3, and beyond to Level 5 if you're big enough, like NASA. Every organization is considered to be Level 1 if it hasn't implemented any institutionalized process.

They'll give you actual numbers, in millions of dollars or tens of thousands of man-hours of effort. They'll even tell you how many mistakes(ie., bugs) you make when you're at Level 1, and how many fewer you'll make at L2 and L3. If it took you X hours to make that application at L1, at L2 it'll take you X-Y%, and at L3 it'll be X-Z%. Just don't ask where these numbers come from, nobody knows. They'll tell you that official process will make your life easier, that it has management support from the very top. They'll tell you that after you get used to it, you won't even notice the process itself.

Don't believe a word of it.

It's not that they'll lie to you, it's just that they'll grossly exaggerate, if for no reason other than that their livelihoods depend on companies adopting their process. The problem with CMM isn't that it adds process to your development efforts, it's that it gets taken to extremes. When you're talking about a project that has a thousand developers and is going to take ten years, CMM is probably is a good idea. But most of us don't work on projects like that.

What they fail to tell you, mostly because none of the people selling this stuff are or were developers, is that what these people consider “process” is something entirely different from what developers consider “process”. You see, the trouble is that the people selling CMM are basically bureaucrats, and have therefore a vast love for paperwork. There are ten phases in a CMM project, only two(2) of which have anything to do with development. Each has massive documentation requirements that developers are expected to produce, and project management becomes nothing more than an anal-retentive exercise in file naming conventions and filing of proper documentation and the distribution thereof.

To support the CMM initiatives of your organization and maintain your CMM Level approval, you must mature, adapt and change your process on a regular basis. This means you need a department wholy responsible for CMM itself. You need groups of people who will 'audit' your CMM documentation and make sure it fits the model. These people are not interested in the technical aspects and merits of the contents of the documents, merely in how closely they match CMM directives in terms of style and file naming. Oh, and versions. One of the major aspects of CMM is improvement of the process itself, and this creates various versions of the various documents, and every time you need a new form, you're supposed to take it from the repository. This creates an interesting patchwork of versions being used on the same project, something you eventually get dinged on in the audits, mostly because nobody in the “Process Team” thinks about maintaining separate repositories for the different versions.

What CMM really attempts to do is to formalize what decent developers already do as a matter of course. We may not have formalized the process, but we already write business requirements, software design, test plans and cases, and everything else that goes along with successful software development. When you're writing programs that are tens of thousands of lines long, it is not really possible to do it successful unless you're following some kind of process, even it it's your own. When making changes to existing programs, yes I do know that I have to test the pieces I'm modifying(unit test) as well as how it affects the other components(regression testing).

What CMM accomplishes, however, is to burden me, the developer, with at least a twenty percent overhead, if not more. On some projects, there's a week(or less) of actual development work, surrounded by at least four weeks of “process”, and I'm not talking about analysis and design.

Why does all this happen? Marketing, for one thing. If you're selling your organization as a potential business partner to some large company, it is considered helpful if you can show that you follow some industry-recognizable process. Once in place, CMM takes on a life of its own, demanding whole departments to do nothing but maintain it. One well-known world wide company has a website called, “Process Management Process”. Think about it: they have process just to do process management. What's next? Process Management Process Process?

I've found that with this system in place, you end up spending more time and effort worrying about the format and look of your process documents than what's actually contained therein. Some documents, when required, are simply copied from other projects, application names changed, resaved with different names and filed. If you don't file it, you get dinged on your audit, but nobody ever reads the document contents.

None of this is to suggest that you don't need process; quite the contrary, process is required when developing any complex thing, especially software. But it should be transparent to developers. It is a sad state of affairs when a summer co-ed student learns more about writing time estimates than about actual programs.


Post a Comment


Links to this post:

Create a Link


Copyright © 2005 Yury D.   All Rights Reserved