Software Models. Good or Bad ?

The last place I worked was CMM level 2 and ISO9001 with TickIT. In general, things worked more often and were easier to fix when things go wrong, and it didn't impact our creativity.

At any big software place, there are lots of things that have to be done at various parts of the development process. For example, when checking in code, you may need to update other things which depend on that file and check them in. You probably have a set of things which need to be tested to make things still work. Depending on your release procedure, you may need to tag things for a specific release. You probably want to update the internal issue as fixed.

The point of the added documentation, task lists, structure, etc. is to ensure that these things aren't done. By making sure everything which needs to be done gets done, and documenting it so you can look back later and confirm that it was done, you're less likely to see trivial problems. And when you see problems, you can rule out trivial causes, and spend more time on real debugging.

The important thing to realize is that not everything in the new procedures need to be done by hand. In general, you should automate whatever you can! That way, you know the procedure was followed correctly without the drudge work of actually following it.

Before I worked at that company, I was not a fan of rigorous procedure, but I now am. My wife seems to be the poster child for why one might need procedures. She's a grad student, and is often trying to guess where in her experiments things went wrong... and she doesn't always know that the materials she started out with were good. A test procedure could alleviate the hassles she has.

I've focused on the coding elements in my examples, but the same benefits accrue to the design process, where they can save even more time and hassle. Getting requirements right up front can save having to recode the whole thing.

My basic point is that whether they're documented or not, there are things in every organization that need to be done lest things break. The only difference between a CMM shop and a non-CMM shop is that the former knows what needs to be done and knows that they have been done.

I WISH I would work someplace that had CMM practices. I know it might sound odd to those of you that have to deal with it now, but I'm so used to working in duct-taped environments that I'd love that type of structure.
In-code comments are often not enough to help one hacker out with another hackers code.

I used to work under CMM, contracting for a big telecoms company.

Whilst the process was definitely a good thing (everything code reviewed) I found a lot of the forms etc. pretty pointless. More often than not, the things ended up getting filled in later on before an audit.

Only good leadership by the good developers and managers is really going to change anything. You can't force good results via forms. Your good developers will resent the paperwork, and the bad ones won't do it properly. There are rarely enough good developers around to look after the bad ones.

It seems to me that it was very much a marketing thing, rather than any strong process that really aided development. I spent far too much of my time leaving documentation trails for stuff I'd done properly.

Is this not the opposite of extreme programming?

Of the documentation that you've written, how much was read by others? Did they find it helpful?

...richie

And it's going to have no effect otherwise.

What you need is some veteran coder leading the project. Formalization without domain knowledge is the basis of total failure.

The company I work for is partly CMM level-2 certified (some departments are, some aren't yet). From what I've seen, it's generally a good thing, as long as it doesn't require *too* much paperwork for doing trivial tasks.

It does tend to produce better planned code and projects, and it does seem to mean that things come in closer to on-time than they were before, as well as helping with resource allocation. As someone else has said, though, it's no substitute for people who know what they're doing.

So - overall useful, as long as it's done sensibly. :-)

I agree with Movement models are really a marketing tool. Most developers I've worked with don't tend to even look at UML models and charts. I say stand over them with a big stick and hit them every time they some how alter the software's structural design :D

Lets face it many of the business managers who tend to be are clients are dumb and only really understand rudimentary charts. Half the so called technical reports I've ever wrote as a Tec Arch where to mainly written to humour them:)

On a more serious note, formal quality control guidelines and design metrics should really be established before the start of a project. Lead developers may be highly experienced coders however they don't tend to understand applied software design or make especially good replacement software engineers. An in depth understanding of a software systems core structural design and any key functional algorithm process is naturally desirable and central to understanding how to improve a systems efficiency.

"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C. A. R. Hoare