Brooke's Law doesn't include scaling effects. They're geometric. [There is another effect I can't yet name that kicks in for very large projects so they can never complete. This isn't just an asympote, but a maximum - total output reduces the bigger you make the project team without relaxing the time constraint.]
Here's the heuristic scaling law:
To double output, triple the resources.
[No evidence or research to support this.]
If you have 10 units of work to do and your staff of 6 can do it in 3 months, to produce 20 units of work in 3 months, you need 3 teams of 6 [modulo their effectiveness and project initiation time]. For 40 units, 9 teams, 80 units - 27 teams etc.
Alternatively, what the team can do in 24 months, might be possible in 3 months with 27 times more resource - or around 8 times the total cost, if it ever completes. [I don't have any ideas on the increase in unreliability of the estimates or the 'Project Risk' increase.]
Sometimes "Fast Tracking" may be necessary... But hugely expensive - and where are you going to find around 25 times as many people???
The Standish Group have been performing Primary Research (surverys) of I.T. in the USA since 1994. They've accumulated a large amount of data and 50,000 project case studies.
Their "Recipe for Success" (for I.T. projects) is simple - six people for six months.
It seems to confirm this hypothesis.
"Cheap, Fast, Good - pick any two".
From an article in "Software Magazine", Here's the list of Standish's Top Ten:
Recipe for Success: CHAOS Ten
Confidence Level Success Factors
Executive support 18
User involvement 16
Experienced project manager 14
Clear business objectives 12
Minimized scope 10
Standard software infrastructure 8
Firm basic requirements 6
Formal methodology 6
Reliable estimates 5
Other criteria 5
Thursday, March 1, 2007
Mythical Man Month II
The Mythical Man Month Revisited
Fred Brookes wrote a definitive book, "The Mythical Man Month" on the management of large projects. He reported the development of the Operating System for the (then) revolutionary "IBM/360" around 1960.
His main conclusion is usually stated as: "Adding more programmers to a late project only makes it later."
Take together the last set of posts on programming/I.T. productivity factors:
Teams, Staff 'Morale/Attitude', Star Performers, Nett Negative Producers and Ineffective Management.
All the factors multiply together - the range of productivity, even for the same staff, is tremendous.
How can sensible "Man Month" estimates be made in these conditions?
Brooke's Law can be explained by a computer analogy:
It's a 'cache coherency' problem. The memory of the existing staff is being copied to the new staff - both groups cannot produce anything until the transfer is complete.
Projects and Admin/Operations tasks can't be forecast using a "mean average person" - individual forecasts have to be made for the productivity of the specific person, team, project, environment... And if you are "Going Boldly Forth where No Programmer has been before" - isn't that the definition of "research"?? It's a creative endeavour - you are done when you're done, not before. Applying pressure, especially in the form of deadlines, is counter productive. Only the bravest of staff will 'push-back' and refuse to release incomplete, incorrect and buggy code or services. And once a 'milestone', like any Victory in war, is declared complete, there is no going back. The body of work, no matter how poor, can only be tinkered with, never fixed.
Or restated: By applying arbitrary deadlines, you guarantee faulty code. Then you are stuck with the mess as the foundation for the rest of your work. You will slowly drown in the morass of your own mistakes - and all easily preventable.
The real Myth, is that there is an average person who's output can be projected.
The best person to forecast completion of a unit of work is: the one who's going to do it!
And the 'horizon' is only clear for about 2 weeks ahead. So detailed work plans can only be constructed for the immediate future. Yes, there will be a design, but it will evolve and it will be a set of road signs.
The old rubric applies: Double your best estimate, then double it again.
And don't take on tasks you don't know how to do... You'll only create a huge mess, and everyone, including you, will be very sorry.
Teams - the Killer App?
Jerry Weinberg, the doyen of the Quality Software movement, in his landmark four-volume set "Quality Software Management" comments on models of Software Metrics - that five factors, each of which could vary productivity two-fold, were left out because they were too hard to measure.
Team Performance is one of these five [from memory].
In "Pop Management" books, there's a lot of "soft" assertions and anecdotal evidence on the value and creation of "High Performing Teams" - but where's the solid research that shows Teams Really Do Work? And what their multiplier factor is. [Jerry is much better than that. He's been an academic and reports some very nicely constructed experiments.]
"Dynamics of Software Development" by Jim McCarthy, the real-life lessons from Microsoft's C++ team, focused on team factors. McCarthys mantra is: "The Software is the Team, the Team is the Software". If there is a problem in the team, it will show up in the software. Faults in the Software are caused by failures in the team process. Team dynamics impact performance immediately and greatly.
Bob Lewis succinctly defines the difference between 'teams' and 'groups' - a 'team' needs everyone to complete the task. There are no "Sales Teams" - individuals make sales.
What I'd like to say is: "Here's the definitive reference that shows Teams improve software & I.T. productivity by a factor of 2-5".
When I find the research, you'll be the first to know.
Wednesday, February 28, 2007
Getting More for Less out of your staff
What to make more profit, lower costs and increase financial viability of your company?
David H Maister in "Practice What You Preach: What Managers Must Do to Create a High Achievement Culture" gives you the formula. And his model really is a mathematical formula!
And it's simple - staff will perform better, stay longer and even work for less if they like working for you.
Message: Treat your people well, and you will benefit many-fold.
For some people, this will be a "non sequitur" - a "yeah, so what?". For those who believe all workers have to be whipped to produce anything, and will skive off given half a chance, nothing will convince them - not even going broke.
For those wanting to be convinced, Maister does a lovely bit a research using a multi-national marketing company with a full range of business types - small to large, premium products to low-cost mass-market.
Masiter comes up with a good mathematical model relating a number of factors to a composite figure he calls "Profitability" - not just one years' profit, but longer term financial viability. He also has a nice way of presenting the factors in hierarchical form.
Think this through with "brain-workers" (or Knowledge workers) - you can't order them to "produce some brilliance". You can't see inside their heads nor really know just how good the 'stuff' they produce is. Software is an intangible - it's hard to measure and harder to quality assess. You can't beat good ideas out of them...
This is the definitive environment for "passive aggressive" behaviour and for subtle undermining and sabotage.
Screw your staff over, and you'll reap the consequences for a very long time. And you won't even know who did what, when.
At the very least, the more "meek and mild" staff will just withdraw and do an absolute minimum.
You did remember to hire bright people, didn't you? They will expend their creative efforts in looking very busy and producing as little as they can get away with.
Unless you are an expert in the field, and current at that, you won't be able to pick it.
Message to managers:
Treat your I.T. staff well. Get them off-side and you will suffer.
The great thing is that they are very easy to keep happy - give them the stuff they ask for or be clear about what you can afford and why, listen to their requests for changes and especially for reasonable deadlines and occasionally show them you appreciate their efforts. In return you will get high output and when you need it, they will go to extraordinary lengths for you. You have to earn their trust and loyalty - not bully, intimidate or demand it.
There's a secret here you've heard a thousand times from the mouths of Pop Stars: "I'd do this for free".
Yep - good and great programmers/I.T. practitioners love what they do.
And there is a proof the best will do great work for free: Open Source Software.
Technically there is a reason - there are very high intrinsic rewards in programming/I.T.
We can guess it comes from the feelings of "Flow" [Mihaly Csikszentmihalyi ], the human reaction to 'achievement' (a nice high) and the rewards of Problem Solving.
[There has to be some good psychology names for these processes]
The 100-fold advantage
There is a Silver Bullet for programming productivity - pick good people. It probably works for all other areas of I.T. as well.
There is a definitive study, rigorous research, by a Professor of Behavioural Psychology.
It's published in the book "How to be a Star Performer" by Robert E. Kelley.
BTW, Kelley talks of only 10- and 20-fold performance differences amongst "brain-powered" staff at the Bell Labs unit that programmed the "5ESS" telephone switch.
"In the wild", this varies more. Best I've heard of is Rob Kolstad who in a half-day rewrote a key program that had taken a year or more effort - and it ran 100,000 times faster. I've sped-up a critical process by 2- 5,000 times, again with a small tool, quickly implemented. Sadly, no studies, no references.
"100-fold" is a guesstimate, an accumulation of experience and observation, not solid, proven research.
But then again, how do you measure 'productivity' for programmers and other I.T. professionals. Lines-of-code a day doesn't work - you just drown in bugs...
Kelleys' take-away is that 'Stars' are made, not born.
"Initiative" is the central key element - everything else builds on that.
With more highly productive staff, you should be able to get more done - if your organisational processes allow and encourage it, and your managers can get out of the way of the technical staff.
From the on-line page, the Contents of the book:
I. The Productivity Secrets of the Star Performers
1. What Leads to Star Performers
2. Stars are Born, Not Made
3. Creating the Star Performer Model
II. The Nine Work Strategies of the Star Performers
1. Initiative: Blazing Trails in the Organization's White Spaces
2. Knowing Who Knows: Plugging In to the Knowledge Network
3. Managing Your Whole Life at Work: Self-Management
4. Getting the Big Picture: Learning How to Build Perspective
5. Followership: Checking Your Ego at the Door to Lead in Assists
6. Small-L Leadership in a Big-L World
7. Teamwork: Getting Real About Teams
8. Organizational Savvy: Street Smarts in the Corporate Power Zone
9. Show-and-Tell: Persuading the Right Audience with the Right Message
10. Become a Star Performer: Making the Program Work for You
I.T. Management 101
What do they teach in "Management 101" in the School of Hard Knocks?
"Tech-heads are knuckle-heads, Management Knows Best".
Simple, stupid and ineffective... What are the things you want in your technicians? Breadth and Depth.
You want Bright, Capable people that are motivated, knowledgeable and productive. You also want innovative, cost-efficient solutions...
Adopting a "Command and Control" mentality in a cognitive based task is not just wrong, but pessimal - you can't do it worse. Managers who've been 'Technical' are often worst - they believe they know all the answers and are still technically relevant.
In 2007 I know of a major Australian outsourcer using 300Kb Word documents as its Change Control mechanism.
That could've been a cute idea in 1995. It's a mornings' job for a young gun to produce a PHP-MySQL solution running on the Intranet. The 'Managers' can't see a problem...
No references - don't know where to start or how to define the question...
The secret that shall never speak it's name
Nett Negative Producers
That's it. This is one of the biggest dirty secrets of the I.T. business.
It's not just that there is a huge difference in both the capability and productivity of I.T. practitioners, there are a large number that are negative producers - if they were gone, more would get done.
I'd give you references and real research - but it doesn't exist, because this is problem that doesn't exist...
Want to give your I.T. productivity a big boost - discover and remove these people.
They could be managers, could be technicians - but they will always seem and look busy.