Everything you have ever known is stored somewhere in your brain, so you can never eliminate mental models, you can only add to them. That’s why this book is based on the Principle of Addition:

The best way to reduce ineffective behavior is by adding more effective behavior

That’s ultimately the way organizations move from one pattern to another. As they add more effective models, they find them used more and more, and this simply leaves less opportunity for the ineffective ones to be used. Organizations get addicted to certain practices that are harmful in the long run, but relieve their pain in the short run. The more the organizations do them, the worse they feel, and the more they seek the relief of their addictive practices.

If you find an organziationaddicted to some short-sighted intervention, you have to look for what rewards (explicit or implicity) are given for short-run success in this behavior. Then remove those if you can and supplement them with rewards that are tied to long-run success.

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

“Why does software cost so much?” is an assertion masquerading as a question. The assertion that software is too expensive is part of a cost-containment ploy. The cynical notion that a good schedule is one that no-one has a prayer of achieving is another part of that ploy. The constant refrain that software developers are just not productive enough has only one purpose: to make software developers work harder. It is a goad, a goad that appears to work because software developers are sincere and professional and a little dopey.

The problem is our industry is over-goaded. The work of software development is largely incomprehensible. When you’re under pressure, your first response is to cut out extraneous activities. As the pressure increases, the only real option is to pay for speed by reducing quality. This comes, of course, at the very moment that companies are paying lip service to quality as never before.

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

Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the project

As we try to solve bigger and bigger problems, the Size/Complexity Dynamic drives us from a previously successful pattern to a new, untried pattern. Were it not for our insatiable ambition, we could rest comfortably with our present pattern until they carried us away in our rocking chairs. Many organizations have done just that, usually because their customers have no further ambitions for better software.

When there is ambition for more value in software, it quickly pushes against the barrier of the Size/Complexity Dynamic unless we can alter the capacity of our brain. Organizations sometimes do this by hiring smarter people, but there’s a definite limit to that tactic.

We can’t alter the capacity of our brain, but we can alter how much of that capacity we use, as well as what we use it for. That’s why software engineering was invented.

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

In a nice twist of synchronicity, I was reading some old issues of JOOP this morning, and came across an interesting article from October 2000, by Nevin Pratt, entitled The Software Wall. In it he describes his two constants of software:

The First Constant of Software: Software is constantly becoming more complex.

The Second Constant of Software: A programmer’s ability to manage the complexity remains constant.

Pratt then explains that: these two constants, so long as they remain true, predict the existence of a developmental barrier or wall, beyond which we cannot progress. The reason that we cannot progress beyond “the wall” is because as complexity increases, productivity decreases. Productivity thus approaches zero as the complexity increases, until eventually productivity hits zero.

We can’t just add more people (cf. Mythical Man Month), so we need to constantly attempt to move the wall. Pratt shows how we’ve managed that by the move from machine language to assembly language, and then to 3GLs, and then to SQL, and then to OO (and stakes his claim that dynamically typed OO languages are the next in this series, thus the URL of the reprint of the article!)

However, Pratt claims that these are attacking the first constant – the complexity of the software, which I think gets it backwards. Each of these is really just another layer of abstraction – the software doesn’t become any less complex – the detail just gets hidden, meaning that the programmer doesn’t need to encounter as much of the complexity, thus minimising the impact of the second constant.

However, it’s an interesting partitioning of the problem, and I like the approach of asking, for any given suggestion, will this make the software less complex, or enable the programmer to handle more complexity?

Tools do not determine how they will be used. Therefore, it’s not the tool that counts, it’s your reaction to the tool. Programming tools can be used to program without understanding, or they can be used to free the programmer’s mind and hands for tasks that can’t be made routine. Pattern 2 managers buy tools to force programmers to work in standard ways. Pattern 3 managers manage tools to empower programmers to work in effective ways.

The same distinction can be made in managing. Management tools (such as methodologies) can be used to manage without understanding, or they can be used to free the mind and hands for tasks that can’t be made routine.

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

Feedback loops in action sometimes seem to have a mind of their own. That’s because managers are blind to the key role that people – especially management people – play in each feedback. All of the loops that contain management contain decisions by people: Whenever there’s a human decision point in the systems, it’s not the even that determines the next event, but someone’s reaction to that event.

For some readers this maxim will be the hardest to swallow of all the ideas in this book. They would like to believe that porjects obey some set of mechanical laws, like Newton’s Laws of Motion, and that the manager’s job is to learn these laws, set up the project properly, and then let nature take its course to success. This is an especially comforting idea to those managers who are afraid of their own workers, because it means that they can hide in their offices and manipulate plans, rather than deal with real human beings. As long as they deny the role of human action in project management, they’ll never be sucessful project managers.

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

1. A project manager (Humpty) becomes aware that he is sitting on a verynarrow ledge of some sort.
2. Humpty tells his manager about his anxieties.
3. Humpty’s manager says: “Don’t worry, that’s not going to happen. But, if it does happen, I’ll bail you out with lots of resources. The only thing is, you must not go around talking about this situation, or people will be alarmed (including my manager)
4. Humpty goes back and keeps his mouth shut. He is able to keep quiet by convincing himself that nothing is really going to happen.
5. Sometimes, things do get better by themselves. More often, thing go nonlinear and then Humpty has egg all over his face. Humpty’s manager may initially support him with lots of resources, but he finally needs a scapegoat because things can’t be put back together again …

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

The big mistake commited most often by software managers is choosing a linear model when nonlinear forces are at work. By all accounts managers everywhere seem to make this modelling mistake. One of the most common examples of such linear modelling is the assumption that the same patterns that produced quality small systems will also produce quality large systems.

Software life would certainly be comfortable if this linear model were true. Unfortunately, the difficulty of producing quality systems is exponentially related to system size and complexity, so as software gets bigger and more complex, old patterns quickly become inadequate. In many cases, the old patterns actually exacerbate the problems they are attempting to solve.

I’ve given this model a name: the scaling fallacy:

Large systems are like small systems, just bigger.

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

Of course, people need to look at this from the reverse as well – the sorts of patterns (and procedures) needed for large projects, aren’t necessarily going to be worth the overhead on smaller ones. (I was hoping to quote something useful on this point from the start of Software Craftmanship, but I can’t find my copy of it at the minute…)

“Their first response to control the pain is usually denial – controlling the information so they don’t notice. When denial fails, they may blame others, because people generally prefer familiarity to comfort or efficiency. When blaming fails, they may try to remain where they are by trading off one set of demands against another. If trade-offs fail, however, they may reluctantly decide that they must accept a new pattern to retain control”

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

The principle device for closing a culture to information is the circular argument.

Some years ago, I helped a client make the transition from Pattern 2 to Pattern 3. The transition was necessary because they were producing telephone equipment that had to have down time of no more than one hour in forty years! They were so successful in achieving their goal that their development anager published an account of the process.

The very first time I showed the article to another manager he asserted, “That would never work here.”.

“Why not?” I asked. “It should be straightforward. After all, their problems were much harder than yours. You don’t even have on-line systems, let alone systems that have to respond in real time.”

“Even so, their problems couldn’t have been as hard as ours because we could never get that kind of performance on our problems”

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

I experienced this in action first hand a few months ago. We’d arranged for Damian Conway, one of the best Perl trainers in the world, to come to Belfast to do some training courses. We’d never put on training before, so we talked to a few of the local training companies, to see if they’d be interested in doing something with us. They all said the same thing: “There’s really not that much interest in Perl training in Belfast. We only really get about 5 or 6 people on our Perl courses, so we don’t think it would be worth it.”

Of course, these companies couldn’t see that the reason they didn’t get people coming on their Perl courses wasn’t that there was no interest, but that their courses weren’t very good. Whilst we were at BlackStar, we’d tried to find training courses for our developers to go on, and asked all the local training courses what Perl courses they had. We wouldn’t send our staff on any of them. (We talked of creating our own, in-house, training courses, but of course that never happened…)

So, despite everyone’s seeming lack of interest, we went ahead and arranged the courses ourselves, and had around 50 attendees over two days. We even lent Damian to Momentum, the Northern Ireland ICT Federation, for a morning to do a Breakfast Briefing on “10 Myths About OO” – one of their best attended breakfasts all year. (Of course Momentum then decided that they just wouldn’t bother paying Damian for this, but that’s NI for you.) The whole thing was so successful that Damian is coming back to Belfast in another few weeks to do even more courses.

How many more companies must fall into this “We did X (badly), and no-one wanted it, therefore no-one wants X” trap?

Whilst I’m not a big fan of all these Levels of Software Development, I liked this snyopsis of how to move between them:

• Pattern 0 to 1: Humility, produced by exposure to what others are doing.
• Pattern 1 to 2: Ability, produced by technical trainging and experience.
• Pattern 2 to 3: Stability, produced by quality software management.
• Pattern 3 to 4: Agility, produced by tools and techniques.
• Pattern 4 to 5: Adaptability, produced by human development.

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