ZING!

No, I meant UML - just the pictures, not the process.

I did use RUP once, but fell foul of the awful quality of Rational
Rose's fondness for crashing. As many have noted, if the process is so
good, why is the end product so flakey?   (Hmmm...... why am I reminded
of XP there too?)

Right on.

Decompose the requirements, produce a good modular design with built in
scalability and ways round bottlenecks (e.g. some parts of the design
may need configurable parallelization). Specify to the module level and,
while you're doing this design in performance measurement, system-level
tracing/debugging and restart & recovery. All of these WILL be used
unless you're designing a simple stand-alone program.

Resist all attempts to start coding until this point has been reached or
you'll waste endless time during integration testing, when you suddenly
find that the system can't be started or stopped cleanly and that
modules developed by different groups don't talk to each other.

Then and only then code, preferably using some form of top-down
incremental development method. AFAICT all the fashionable extremely
agile team scrums are merely elaborations of this. IMHO unit testing and
regression testing are non-optional parts of module development.

Integration testing can start as soon as the various modules can
demonstrate basic functions in unit testing and the problems that
integration testing find can be fed back into module development.

Finally, system test against test cases developed directly from the
original requirements. This should be reasonably short and sweet if all
the above was done adequately but will stretch into next century,
finding endlessly multiplying bugs if the previous stages were skimped.

It's hard to find a process that will work when people who don't know
how to code are doing a lot of the coding.  Maybe that's why
document-centric approaches work better for some organizations.  It
gives all the bad coders something to do besides breaking the code.

Well we all know that, what was is?, "1000 monkies hitting a typewriter
will eventually write Shakespeare" is not realistic, its a statistical
possibility, and that's it. Same goes with coding, you have to have able
and earnest programmers to create good code. If you don't, then of
course they are going to write crap, so either you have to teach them or
get read of them. I have worked in companies where they only hire expert
programmers. The type of programmer that writes larger and
semi-complicated code in a couple of days, while others might use 2
weeks, and the code is almost flawless. I know it sounds like an
exaggeration, but I witnessed it myself in the beginning and it left me
speechless. And from that I learned what good programming is and allows
me to do, if done correctly.

Btw, I forgot a couple of points when writing my previous post, so I
will make the additions now.

Just writing the code in it self is not good enough. You have to have
some structure to the procedure of writing the code. There should be an
agreement on what needs to be done and how to do it. In the above
example, there was usually an task/architecture meeting between the
programmer, the project leader and a senior programmer managing the code
base for that part of the system. The point of the meeting was to have a
common understanding of what to do, how to do it and how to use the code
base to achieve it. If there were any details that needed to be
recorded, we used bugzilla. Bugzilla was the overall archive of all
things coded, and every piece of code checked in to subversion had to
correspond to a bugzilla bug and had to be relevant. To ensure this,
senior programmers had control over the master branch, the senior
performed a code review and the final checkin (even for each other). If
there were any questions during programming, a senior was consulted. So
the senior programmers acted as the guardians of the code base and hence
the code was kept to premium quality. There where other parts such as
testing procedures and bug verification procedures, but that are details
I wont go into here now.

This kept the development process light, capable of supporting change
and above all helped us write excellent and functioning code. This made
programmers and management happy because everybody could focus on their
main tasks instead of long meetings and endless specification
discussions. Tasks were divided into smaller parts so it could be done
by one or two programmers and so that no single task took too long time
to complete. Everything was checked by several people by way of small
meetings, or coffebreak discussions, without having to resort to a paper
mill production. By working iteratively and hands on from the start we
learned to understand things intimately from the start and could avoid
problems and pitfalls before they even existed.

As another point, later I worked on a project where the management tried
to enforce a rigid structure and force us to use xp, scrum etc
indiscriminately. The project soon fell apart, in dissent. I, and
shortly after, another, walked away from the company. They did not
consider the team or the individuals and how they work best together.

tom

In my opinion.and experience, there are two kinds of programmers (ignoring
beginners, who have to be treated specially).  Those who can and do, or could,
safely and correctly use "Just Write The Damn Code(tm)"; and those who are
largely incapable of writing anything substantial no matter how much decoration
you put around the development process.

Please note: I am not claiming that all good programmers /do/ use JWTDC(tm) --
only that they /could/.

   -- chris