Chris Uppal said:
Are they any good ? if they are then you are probably trying to teach
them
stuff that they've known since you were in the cradle. If not, then why
bother at all ?
It's a standard cycle:
Year N. Situation is that there are a variety of "methodologies"
available,
but none of them seem to work very well in real life. That's to say that
there are people who can produce good (in whatever sense matters in
context) programs,
but that their presence on a team doesn't correlate with the methodology
used by the team (or to the dedication which that team applies it).
(The literal year numbers in the above should not be taken seriously, of
course -- I think the cycle time is more like 10 years than 5).
Well said that man.
To which I would add: it's not new that managing software development is
hard. Frederick Brooks 'The Mythical Man Month' may be more than thirty
years old, but it's still one of the most thoughtful (and in my opinion
best) books on the subject.
http://www.amazon.com/dp/0201835959/
The core of the issue is that the best programmers are an order of
magnitude more productive than average programmers. It's seductive to
believe that if you could encapsulate the methods of those best
programmers into a methodology, you could raise the standard of the
average very significantly. Sadly, this turns out not to be true.
Consequently Brooks recommends not trying to develop methods which would
try to smooth out the difference between the best and the average, but
instead to build 'surgical' teams around the best, where the team
comprises
* one 'surgeon' - the recognised highly productive programmer, who does the
majority of the actual code-cutting work, and is boss to the rest of the
team
* one 'co-pilot' - a less experienced programmer who is being groomed to
become a 'surgeon' and who sits with the surgeon, discussing the work and
methods as required
* one 'administrator' - an office manager type person, reporting to the
surgeon (NOT the other way around) whose job it is to handle all
organisational problems relating to the team and its resources
* one 'editor' - responsible for generating and maintaining
documentation of the code and of design decisions
* two secretaries, one each reporting to the administrator and the editor
* one 'program clerk' - responsible for maintaining all project files
including released deliverables
Brooks also advises 'plan to throw one away' - in other words, rapid
prototype. Note that this has quite a lot in common with modern XP
methodologies.
I have to say that in my twenty years of personal experience as a
programmer and manager of programmers, and as technical director of
software companies:
(1) Brooks' recipe as described above definitely works (very well),
although these days with improved office support software and version
control systems you can probably do away with the secretaries and roll the
program clerk job description into either the co-pilot's or the
administrator's. Obviously, if you appoint the wrong people as surgeons,
this approach fails; but if you appoint the right people, it is hugely
productive.
(2) If, as an organisation, you are promoting your most productive people
away from the code face to become 'managers' or 'analysts' or
even 'designers', your productivity will fall, not rise. If, on the
contrary, you promote your less competent people to become 'managers'
or 'analysts' and give them more status than programmers, then your most
productive people will leave, and your productivity will plummet.
So 'managers' _must_ be junior to 'programmers' in a software
organisation, or else you might as well close the doors.
(3) Any system which tries to divorce design from implementation will fail.
Consequently, any methodology which uses a formal language to communicate
between 'designers' or 'analysts' or 'specifiers' on the one hand,
and 'developers' or 'programmers' or 'implementers' on the other, is
highly suspect. If the person doing the requirements analysis and the
architectural design is the senior surgeon on the project, then he has his
own way of making the design notes he will use and will get the editor to
document. And if the person doing the analysis and design is not the
senior surgeon, you might as well start putting your CV round the
agencies, 'cause your project is going to fail.
