I also found an interesting recent article by Barry Boehm on “Managing Software Productivity and Reuse” [pdf], that details the results of an extensive analysis conducted with the DOD to discover savings over a business-as-normal approach.

In this study, they discovered that you could achieve an 8% improvement through “working harder”, a 17% improvement through “working smarter”, and a 47% improvement through “work avoidance”.

Better still, all three are mostly complementary, and the gains can by accumulated by avoiding whatever work is possible and working smarter and harder on the rest.

He also provides a useful graph of how productivity has risen over the last 40 years, through the use of assembler, high-level languages, databases, regression testing, prototyping, 4GLs, sub-second time sharing, small-scale reuse, OOP and large scale reuse, providing an order-of-magnitude increase in productivity, on the general scale, every 20 years.

He also argues that with “stronger technical foundations for software architectures and component composition; more change-adaptive components, connectors, and architectures; creating more effective reuse incentive structures; domain engineering and business case analysis techniques; better techniques for dealing with COTS integration; and creating appropriate mechanisms for dealing with liability issues, intellectual property rights, and software artifacts as capital assets” even greater gains can be achieved.

I’ve been trying to find more information on the “factor of 10” productivity differences, between either teams or individuals, frequently cited, but most of the primary articles don’t seem to be available on-line. A trip to the library is probably in order again early next week.

I did come across this study from 1995, however, which set out to measure the impact of reuse in OO systems. A graduate class was divided into teams, each of which was set the same programming task: to develop a system for a video rental store. Generic and domain specific libraries were made available for reuse, but they were free to choose whether or not to use these.

So far so good. Where the study seems to go bizarre, however, is in how productivity was actually measured: a team’s productivity was taken as “lines of code delivered” divided by “hours spent on analyzing, designing, implementing and repairing the system”. The authors point out that other measures than LOC “could have been used, but this one fulfilled our requirements and could be collected easily. More importantly, we are looking at the relative size of systems addressing similar requirements and, therefore, of similar functionality.”

This seems most bizarre. If the systems are all the same, why does the lines of code produced matter in the slightest? Surely all that matters is the time taken to produce the system – especially as this is meant to be testing re-use. If one team could reuse sufficient quantity of code to enable them to write the system in 10,000 lines, taking 100 hours (productivity = 100), but another team wrote an entire 250,000 LOC system from scratch taking 1250 hours (productivity = 200), is the second team really twice as productive?

But the paper seems even stranger than that. It counts the reused code within the total LOC for the team, thus distorting the productivity of a team who pull in a 10,000 line library that provides more functionality than they actually need (compare a team writing a 1,000 line subset of this in 40 hours, with another team who only need to write 10 extra lines to use this library, but who then have an extra 10,000 lines in their final total)

Using this methodology, the paper manages to show a productivity difference of 8.74 between the top and bottom teams, with a factor of 4.8 in LOC submitted. However, if you work back from their figures to calculate the actual lines of code written by the team (as opposed to being in their completed system), there only ends up being a factor of 1.77 in the LOC, and 2.6 in the time taken: still significant, but hardly as impressive:

(italicised columns extrapolated from published results).

It’s also notable that the fastest/slowest teams in question are entirely different with each approach, and the “outlying” teams which deserve special explanation in the paper fare considerably differently.

Team 6 which seems to have a low productivity in the original paper, “considering its reuse rate”, is explained in terms of the team providing a particularly sophisticated “gold-plated” GUI. By solely measuring time taken to do the task, however, this team is one of the fastest.

Gotta go find those other papers…

Project managers cannot afford the time to be entirely scientific when studying failure data. In order for them to control software processes, they must proportion their responses according to the significance of the data for the success of their projects.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 3

Since Capers Jones got us started, we in the software industry have devoted significant effort to measurements of software quality and productivity. Much of this effort has been misspent in a search for illusory precision. It does no good to measure precisely if you don’t have a personal observation model that matches that level of precision.

Do you care if there are 3.7296 or 2.7297 rat hairs per sausage? Will it make any difference in your or my actions if I can measure the humor quotient, or even lines of code per programmer day, to four significant digits?

Measurement without models only allows extrapolation. If the previous five projects have produced 25, 26, 27, 28, and 29 function points per month of labor, then I can extrapolate that the next will produce 30. Such extrapolation is actually based on a model too – a model that says progress is linear. But this model is too crude and simplistic to reflect real software quality dynamics. Without a model, measuring with greater precision may enable us to make more precise extrapolations (more significant digits), but it doesn’t allow us to make more accurate ones (better correspondence with reality).

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 2

One of the most important things leaders need to learn is to recognize the signals of impending deterioration. I have made a list of these signals over the years. As you read this list, remember that many people in large organizations relish apathy. They often fail to see the signs of entropy:

• a tendency toward superficiality
• a dark tension among key people
• no longer having time for celebration and ritual
• a growing feeling that rewards and goals are the same thing
• when people stop telling tribal stories or cannot understand them
• a recurring effort by some to convince others that business is, after all, quite simple
• when people begin to have different understandings of words like “responsibility” or “service” or “trust”
• when problem-makers outnumber problem-solvers
• when folks confuse heroes and celebrities
• leaders who seek to control rather than liberate
• when the pressures of day to day operations push aside our concern for vision and risk
• an orientation toward the dry rules of business school rather than a value orientation which takes into account such things as contribution, spirit, excellence, beauty and joy
• when people speak of customers as impositions on their time rather than opportunities to serve
• manuals
• a growing urge to quantify both history and one’s thoughts about the future
• the urge to establish ratios
• leaders who rely on structures instead of people
• a loss of confidence in judgement, experience, and wisdom
• a loss of grace and style and civility
• a loss of respect for the English language

— M DePree, Leadership Is An Art, quoted in Jerry Weinberg, Quality Software Management Vol 2, Chapter 1

I was starting to wonder how we had ever believed we were only weeks away from launch. It was a mass delusion. We either hadn’t seen, or had simply closed our eyes to, all the warning signs. Instead of focussing singlemindedly on just getting the website up and running, I had tried to implement an immensely complex and ambitious vision in its entirety. Our online magazine, the rollout of overseas offices, the development of new product lines to sell on our site – these were all things that could have waited until the site was in operation. But I had wanted to build utopia instantly. It had taken eleven Apollo missions to land on the moon; I had wanted to do it all in one.

— Ernst Malmsten, boo hoo

This is a scary book. Malmsten retells the story of how boo spent $135m over 18 months, to achieve total sales of less than $1.5m, and never really seems to understand just how badly they went wrong. He actually seems to believe they achieved something important, or at least interesting. At the point of Boo’s collapse, we’d built BlackStar to a turnover of $1m per month, with a total operating spend (excluding marketing) of less than $2m in the two years we’d been trading. Our product development costs (i.e the website, and all our fulfilment and customer service systems etc) had been less than $200k, whereas Boo had spent $250k solely on the feasibility study for theirs! By the time they were on the verge of collapse, even after significant cuts, Boo still needed $2m per week to survive. BlackStar, with 100 employees, and still growing fast, needed less than $100k per week.

Although Malmsten attempts to take responsibility for many of the shortcomings, it’s mostly in an “it was someone else’s fault, but I should really have sorted it out” way. Other than the quote above, he never really seems to realise that it wasn’t the execution that was flawed – it was the entire approach.

Malmsten even has the gall to finish the book with the final press release on Boo’s bankruptcy which finished: We believe very strongly that in boo.com there is a formula for a successful business and fervently hope that those who are now responsible for dealing with the company will be able to recognize this.

Hopefully the readers of the book will be able to see what Malmsten can’t.

Mr. and Mrs. Tweedle had 15-year-old twins, Dum and Dee, who were just learning to drive a car. Dee had driven the family car ten times, and she had a perfect safety record. Dum had also driven the car ten times, but he had been involved in three wrecks. Mrs. Tweedle told Mr. Tweedle that he had to have a talk with the boy, before someone was killed.

Mr. Tweedle opened the conversation by reviewing the three accidents, then asked Dum, “What do you have to say for yourself?”

“Well, three accidents out of ten trips isn’t such a bad percentage.”

“I might agree with you,” said Mr. Tweedle, “but your sister, Dee, has also made ten trips without so much as a stone chip on the windshield.”

“That’s true,” said Dum, “but I get much better gas mileage than she does. And I don’t get mud on the tires.”

“Oh,” said Mr. Tweedle. “I hadn’t thought of those things. Well, just try to drive more carefully from now on, and keep up the good work on mileage and cleanliness. I’m going to have to talk to your sister about her driving habits.”

---

As John von Neumann said, “There’s no sense being precise about something when you don’t even know what you’re talking about.”

A company that wrecks three out of ten major software projects is not ready for second-order measurement. Even worse, if such a company attempts to install a measurement program based primarily on second-order measurement, they will do more harm than good.

If you work in an organization that churns out software products on time, within budget, that please your customers and continue to please them over their useful life-and you do this at least 99% of the time-then you won’t need to read First-Order Measurement.

But if your organization doesn’t meet these criteria, then I hope to show you how to create “a positive environment for measurement,” to avoid the costly mistakes that have led to failure of so many measurement programs, and how to measure things simply and efficiently-things that will help your organization consistently produce the quality software you want.

— Jerry Weinberg, Quality Software Management Vol 2, Preface

I’m always amazed by how many simultaneous tasks software developers are given. I run into people all the time who are assigned to one project but also working part-time on one or two others, and on call to do a bit of maintenance on the last program they completed, or sales support of the need arises.

The human CPU is very inefficient at multi-tasking. We seem to switch gears well, but it’s all an illusion. Of course, we don’t let our inefficiency show. We don’t betray the fact that task one, just interrupted, is still churning on in some corner of the brain, making it impossible to pay attention to the guy who is throwing tasks two and three at us. We smile and nod, not to look stupid. He goes away and we try to remember what task one was, but it’s lost. And tasks two and three, well, they’re floating tantalizingly in recent memory when the phone rings and task four comes spilling into the ear.

Frustration and context switching are bad for team dynamics. Teams are an obsessive business. This means you and your teammates have to be allowed to be obsessively involved in one commonly owned subject area.

The sine qua non of team building is that each and every member has to be full-time on one and only one task, the task that defines the team. A group of split-responsibility, fragmented, and frustrated co-workers may be called a team, but they will never go nova.

Tom DeMarco, “Why Does Software Cost So Much”, Essay 6

Why would anyone want to manage software? It can’t be the money. If you’re interested in money, you’d probably do better investing your time in becoming a top developer, rather than taking a chance on becoming a mediocre manager. It can’t be the admiration of your peers, because they’ll probably despise you for “selling out” to management. Over the years, I’ve found very few programmers who went into management for money or prestige. Instead, I’ve met thousands of them who went into management for the same reason so many abused children become therapists. It’s called the “wounded healer” syndrome: You take up healing because of the experience you have with your own wounds.

Programmers go into management because they have a cause: They think they can make the software industry better than it is.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 18

Managers often say that it’s not their fault that they’re so busy, and they are often right. Outside factors may indeed be too disturbing to be regulated, but that usually because managers at a higher level are not doing an effective job of regulating the outside factors. When upper levels of management pass the pressure down, this is equivalent to holding a blowtorch on a thermostat in an attempt to warm the room. This kind of higher-level ineptness does tend to make it impossible for a lower-level controller to be effective.

Managers who lack self-confidence, of course, will always say that they are busy. It isn’t befitting them to admit to slack-time. You can test the quality of management by interviewing employees and finding out how long they had to wait to see their manager for an unscheduled contact.

If managers do not have a reserve of time, they cannot be managing effectively. In a well-run project, nowhere near a crisis, the managers may put in a full day, but thy have lots of time to damp out crises before they get off the ground.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 17