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.
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 »
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.
Of the documentation that you've written, how much was read by others?
Did they find it helpful?
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 »
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
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
"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