‘QSM1’ Category Archives


The Size/Complexity Dynamic

by Tony in * commentary, QSM1

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?


Programming with Understanding

by Tony in QSM1

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


Events and Reactions

by Tony in QSM1

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


The Humpty Dumpty Syndrome

by Tony in QSM1

  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 Scaling Fallacy

by Tony in QSM1

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…)


The Cycle of Grief

by Tony in QSM1

“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


Circular Reasoning

by Tony in * commentary, QSM1

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?


Changing Your Development Pattern

by Tony in QSM1

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


Increasing programmer productivity

by Tony in * commentary, QSM1

Studies of individuals have consistently shown variations of 20:1 or more in schedule, cost, and error performance among professional programmers, so it makes sense that this is the level of variation we see in Pattern 1.

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

I’ve been thinking about this concept a lot again recently. This sort of figure crops up again and again in all sorts of places. It’s a reasonably well known concept, and reasonably self-evident to anyone who’s worked around enough programmers. So why is virtually no-one interested in the concept?

Yes, you get people writing about “software productivity”, but these tend to fall into two main camps. The first, who usually have something to sell, write about the newest, greatest Silver Bullet that will increase everyone‘s productivity by an order of magnitude.

The second, the more thoughtful consultant types, work hard with companies to smooth all their processes, and slowly move them up the CMM scale, or, in Weinberg’s case, his Six Degrees of Congruence.

But again, this is about raising the company’s level, as the totality of everyone. Although it’s rarely explicit, the implicit assumption is that it’s bad to rely on these “super-programmers”, and you need repeatable processes that work even if you lose your star performer(s). As Dijkstra put it:

Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its workforce

Both of these approaches miss the point, in almost exactly the same way. They don’t concentrate on why some programmers are 20 times more productive than others, or whether it’s possible to create more of these star programmers.

Perhaps it’s just that people just don’t know how to cope with this entire concept. Bob Morris, in his keynote at the Emerging Technology conference earlier this year, talked about how in the last 100 years, $1000 worth of computational power has increased by 14 orders of magnitude – an unprecedented scale that people find difficult to conceptualise. But, in most fields of human endeavour, people can’t even conceptualise one order of magnitude. The world record time for running a mile is around 3 minutes 43 seconds. Even an average runner can run a mile in less than twice that length of time. This plays out again and again: the best is maybe only twice as good as the average. The difference between professionals is much less. In Formula 1, where cars go at speeds in excess of 200 miles per hour, the significant difference in lap speeds is often measured in hundredths of a second. (At those speeds we do get our factor of 20 over the human running that mile, but with huge costs and a lot of ‘artificial’ aids that can raise most people to the same levels)

In the workplace it’s not very different. You won’t find a call centre with an two employees, one of whom handles twenty times more calls than another (at the same, or even better, level of quality). Or two secretaries, one of whom can type twenty times more letters than the other.

We’re not used to dealing with these levels of differences between people, so we don’t know to deal with it when it happens.

And, with programmers, it’s hard to actually see it happening – not at the detail level. We know that Fred gets much more done than Barney, and can do most jobs in a fraction of the time, but we can never quite see how. When we look closely, they both seem to do the same thing. There’s no obvious flaw in Barney’s approach, or obvious methodological differences that could be applied. It just seems to happen, so we write it off as just an anomaly.

Managers in “lower” organisations on most of the “quality scales” rely on the fact that they can give the work to Fred, and have it done quickly, whilst always having that nagging fear of Fred moving somewhere else. Manager in slightly more “advanced” organisations know that they can’t rely on Fred, so they work out all their schedules and budgets based on Barney instead. Neither attempts to make Barney as productive as Fred. They may wish he was, but neither think it’s possible.



The value of quality?

by Tony in QSM1

Did you know that if you were 8’6″ tall, you could get a job as a starting center with a team in the NBA and earn $3,000,000 a year? Now that you now that, why aren’t you starting on a growth program? It’s a silly question, because you don’t know how to grow several feet taller.

Did you know that be reducing the faults in your software to fewer than one in a million lines of code, you could increase your market by $3,000,000 a year? Now that you know that, why aren’t you starting on a quality program. It’s a silly question, because you don’t know how to reduce software faults to fewer than one in a million lines of code.

I frequently talk to managers who are seem obsessed with cutting the cost of software, or reducing development time, but I seldom find a manager obsessed with improving quality. When I suggest measuring the value of quality, they often respond as if I told them to measure the value of growing to 8’6″. Why bother measuring the value of something that you don’t have the slightest idea how to achieve. And why try to achieve something whose value you don’t appreciate?

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