Friday 4 February 2011

Notes on a Scandal

Notes I made many years ago when a client had a scandalously bad experience with an outsourced IT vendor:


In the anniversary edition of his book, The Mythical Man-Month, under a section entitled "People Are Everything (Well, Almost Everything)", professor Fred Brooks says:

"the quality of the people on a project, and their organization and management, are much more important factors in success than are the tools they use or the technical approaches they take."

"To make things even more interesting, some human beings are much more productive than others. Results vary in the exact quantities but study after study has shown that good developers can be between 10 and 20 times more productive than poor developers" [1].

In "Software Craftsmanship The New Imperative" (Addison Wesley), Pete McBreen made the following points:

1. Stop Choosing Developers Based on the Lowest Bidder. Quoting "Deming's Profound Changes", he says "End the practise of awarding business on the basis of price tag alone; instead minimize total cost in the long run."

2. Hold Developers Accountable for Their Work.

3. Start exploiting the Difference in Productivity Between Developers. "When one startup with a team of 25 developers heard that two large, established companies were starting a joint venture to enter the same space, they were worried. Then they heard that the joint venture was using a 'team' of 600 developers. They were safe. With a team of 600 they would waste a month just deciding how to format the requirements documents" - Josh MacKenzie, ThoughtWorks.

4. Hire Small Teams of Good Developers. "Rather than hiring a horde of 30 or more average programmers, customers should hire 2 or 3 master craftsman. Pay these craftsmen as much as you would have paid the horde of average programmers." Afterall, is having 30 mediocre lawyers defending you better than one brilliant barrister?

This leads to the point "Good Developers Are More Valuable Than Their Managers ... Hierarchical organizations do not work for software development. The command and control model of scientific management is outmoded for knowledge workers. It is not relevant when the employees - not the managers - provide the knowledge, skill and ability to create software applications."

"Given a choice between paying $1 million per year for a team of 20 average developers or paying $1 million per year for a team of three outstanding developers, I'd choose the small team every time. The added bonus is that the hidden overhead costst are much smaller with the smaller team - another benefit of using outstanding developers." 
In "Software Craftsmanship The New Imperative" (Addison Wesley), Pete McBreen

"A long-term relationship with the developers is crucial, because the best person to maintain an application is the person who developed it... In contrast, the lowly maintenance programmer ... [will] take a long time because
the maintenance programmer has to learn enough about the application to understand the implications of any changes made. If they fail to do this, in all probability, new defects will be introduced."
In "Software Craftsmanship The New Imperative" (Addison Wesley), Pete McBreen

"Customers want great software. Software craftsmen want to produce great software... This fundamental alignment makes for a better relationship between customers and software craftsmen. Yes, the customer will pay more per developer. The payoff is that a smaller team of skilled craftsmen can handle the projects with realistic schedules and deliver high-quality, robust applications that will last for year."
In "Software Craftsmanship The New Imperative" (Addison Wesley), Pete McBreen

"Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software"
"Facts and Fallacies of Software Engineering" (Addison Wesley), Robert L Glass

"60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement. Enhancing old software is, therefore, a big deal"
"Facts and Fallacies of Software Engineering" (Addison Wesley), Robert L Glass

"Understanding the existing product ... consumes roughly 30 percent of the total maintenance times and is the dominant maintenance activity."
"Facts and Fallacies of Software Engineering" (Addison Wesley), Robert L Glass

[1] http://community.borland.com/article/0,1410,31862,00.html

No comments:

Post a Comment