Advogato: Software Models. Good or Bad ?

Software Models. Good or Bad ?

Posted 2 Nov 2001 at 10:26 UTC by Marooned

My company just started with the company wide implementation of the CMM practices. Which means a lot more documentation, more task lists, more reports, more forms to be filled, rigid templates and in general more structure to whatever we have been doing in the past.

The thing is supposed to add to the profitibilty of the company and bring in some order. We always had followed the practice of writing good documentation and following plans, but working to some particular model like CMM, is some sort of working in bounds. Have any of the people worked within such environments ? Would like to know the benefits as well as the disadvantages.

Structure is a good thing, posted 2 Nov 2001 at 14:39 UTC by AlanShutko » (Journeyer)

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..., posted 2 Nov 2001 at 15:12 UTC by asleep » (Journeyer)

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.

Process OK, details not., posted 2 Nov 2001 at 17:59 UTC by movement » (Master)

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.

eXtreme programming?, posted 3 Nov 2001 at 00:34 UTC by splork » (Master)

Is this not the opposite of extreme programming?

Who reads the docs?, posted 3 Nov 2001 at 03:40 UTC by richieb » (Journeyer)

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

It's going to help the stupid, posted 7 Nov 2001 at 17:47 UTC by exa » (Master)

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.

Generally useful, posted 8 Nov 2001 at 22:04 UTC by arafel » (Apprentice)

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. :-)

Designing software though research and strict quality control guidelines. , posted 26 Nov 2001 at 15:07 UTC by Gregory » (Apprentice)

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