Author: neopragma

An IT professional since 1977, I’ve served in a variety of technical and managerial roles. I’ve worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp. A lifelong learner, I’ve always been interested in exploring better ways to deliver business value through information technology. I’m currently working as an independent consultant, trainer, and coach with an interest in bringing together the best of tried-and-true methods and the best of leading-edge methods to help businesses realize the maximum return on their IT investments and efforts.
Posted on by

Size doesn’t matter

It’s a commonplace that large organizations tend to be stodgy and bureaucratic, and smaller ones tend to be innovative and flexible. When we see a large organization that seems to be innovative and flexible, we are amazed. The press springs into action to report on the existence of this Highly Unusual Thing. It’s an oddity, a curiosity, an anomaly, a freak of nature. The organization is cited as a case study in business books and academic papers. Executives in other companies try to mimic what they think they see the exemplary company doing.

Having participated in various change initiatives in organizations of all sizes (from around 20 people to around 240,000), it strikes me that size alone does not lead to stodginess. I think there’s something more fundamental: Identity. That is, the sense of identity on the part of the individual members of the organization. Do people feel like members of the same organization, all aiming for the same goals, or do they feel like members of a local tribe: Team, work group, department, division, etc.? As an organization grows, what factors might contribute to one sense of identity versus the other?

Continue reading Size doesn’t matter

Posted on by — 7 Comments

The machine society and how to cure it

A rigorous scientific experiment

On the morning of April 21, 2012, I submitted a Google search for the term, productivity. The search engine returned “about 244,000,000 results.” For the term, efficiency, it returned “about 362,000,000 results.”

A search for the term happiness returned “about 56,000,000 results.” A search for the term self-actualization returned “about 1,340,000 results.”

The first two terms yielded a total of 606,000,000 results. The second two terms yielded a total of 57,340,000 results. About 91% of the results pertained to productivity and efficiency, while about 9% pertained to happiness and self-actualization.

Which values are more important in modern society? Clearly, productivity and efficiency are more important than happiness or self-actualization. Have I based this conclusion on my highly scientific and rigorous Googling experiment? No. I already knew the answer before I Googled the terms. My conclusion is based on 58 years of life experience as a card-carrying member of modern society. The Google results were not informative, they were merely unsurprising.

It isn’t necessary to conduct a scientific experiment or an academic study to know that we are preoccupied with productivity and efficiency. Management training, process improvement methods, organizational models, and the like all focus predominantly on those two values.

The question, then, is “So what?”
Continue reading The machine society and how to cure it

Posted on by — 2 Comments

The Guinness model of release planning

This model isn’t based on release planning at Guinness. It’s based on drinking Guinness.

It’s the end of a work day. You and your mates are going out for a drink. Initially, you’re thinking you’d like to have three pints of Guinness. How do you place your order?

If you’re a traditionally-minded software development project manager, you’ll order all three pints at once, in the same glass. When the bartender tells you three pints of Guinness won’t fit in a one-pint glass, you’ll pound your fist on the bar and shout until he finds a way to make them fit. After all, the reason he doesn’t want to pour three pints into the glass is that he’s either lazy or incompetent, or both. Once you let him know who’s boss in no uncertain terms, he’ll get those three pints into the glass, one way or another.

Continue reading The Guinness model of release planning

Posted on by — 3 Comments

Tool mania

Sometimes people get fixated on a particular tool to the extent that they relate every topic of discussion to that tool. You’ve probably seen the pattern before.

I was reminded of it recently during a group discussion of metrics we want to use to track progress in a client’s process improvement initiative. One person kept bringing up Mingle, a tool her group uses to create story cards and track progress on software development projects. Her contribution to every subject of discussion was all about how Mingle supports or could support this or that metric.

At times, I felt as if I had taken my car to a garage and, when I asked the mechanic what the problem was and what sort of repair he recommended, all he would talk about was his favorite wrench.
Continue reading Tool mania

Posted on by — 1 Comment

The domino effect of technical debt

Most people who do coaching work in the IT space focus on one of three areas: (a) technical practices, (b) process improvement, and (c) organizational dynamics or “human factors.” It’s not unusual for a person to have skills in both process improvement and organizational dynamics. It is rare for the same person to work at both the level of technical practices and the level of process improvement, and even more rare for that person to be engaged for both purposes at the same time.

I’ve observed a sort of disconnection between process improvement initiatives at the organizational level and improvements in technical practices at the team level. I don’t know if the reason for this is, in part, the separation, first in formal education in universities and technical schools, and later in coaching, consulting, and training services, between technical practices on the one hand and process improvement and organizational dynamics on the other. Whatever the cause or causes, the situation appears to be that improvements in technical practices and improvements in process are treated as separate and disconnected issues.

I think the two are connected. Technical debt is more than merely an annoyance for maintenance programmers who have to deal with a challenging code base. A mass of tightly-coupled code can make it very difficult, time-consuming, and expensive to implement general improvements.
Continue reading The domino effect of technical debt

Posted on by — 1 Comment

The right kind of lazy

I consider test-driven development (TDD) to be a basic software development technique. I’ve used it in a wide range of circumstances for different types of applications in different domains based on different languages and tools. I coach people in using the technique, I run workshops at conferences on it, and I offer a two-day training class on it.

My only regret is that I didn’t learn about TDD earlier in my career. All those years doing things the hard way…time lost forever. Oh, well.

I use TDD and I like it, but I never try to “convince” anyone that they should use it, or even that it works well. I never suggest that TDD is a “goal” for an individual or for a team. TDD might help you achieve some other goal, but it isn’t a goal in itself. It’s just a technique.

And, let’s face it, nearly all the code in production today, worldwide, was developed without TDD. Nearly all the code under development right now is being developed without TDD. Clearly, programmers can get along without it.
Continue reading The right kind of lazy

Posted on by

Small is still beautiful

There was an interesting email discussion today at a client where I am engaged in a process improvement initiative. The current-state process resembles a hybrid linear plus time-box model, according to the taxonomy of process models I suggested in an earlier post. They do the iterations only for the programming work, and the rest of it is linear. Their goals for improvement are to improve throughout, reduce lead time, increase predictability, and reduce defects.

A portion of the discussion dealt with the size and scope of work items. It occurred to me some of that material might be of general interest, as it reinforces the idea that small is beautiful. Here is a sanitized excerpt from the discussion. Hopefully it will provide at least one real-world example of the value of keeping things small.
Continue reading Small is still beautiful

Posted on by — 4 Comments

Sphincter Power, or: How to get a clear definition of done

One day, the organs decided to hold a meeting to determine who should be boss.

The brain said, “I have the capacity for abstract thought, and I also control the autonomic processes of the body. Clearly, I should be boss.”

The heart said, “I pump the blood, taking oxygen to all the parts of the body. Brain, without oxygen you die before anyone else. Clearly, I should be boss.”

The stomach said, “Without me, none of you could function. I process food and convert it into the energy you all require. Heart, without energy you stop pumping. Brain, you consume energy even when the body sleeps. Clearly, I should be boss.”

The sphincter said nothing, and remained closed. After a couple of days, the brain had a headache, the blood was toxic, and the stomach was bloated. The brain, heart, and stomach unanimously declared the sphincter boss.
Continue reading Sphincter Power, or: How to get a clear definition of done

Posted on by — 4 Comments

Words don’t mean what they don’t mean

<rant>

Words don’t have firm, unambiguous, unchanging meanings. This is a source of some frustration for me. The same word can have multiple meanings. Sometimes there are context-dependent meanings. Sometimes there are shades of meaning conveyed by tone of voice. People can have multiple interpretations of the same basic meaning of any given word. Clear communication is more challenging than it might appear to be.

In the field of software development, we have an unfortunate habit of re-using old words to represent new concepts. Maybe it’s because we value re-use (whatever that means). The English word, agile already had a meaning before software developers came along and started using it for something else. A ballerina is agile. A faun is agile. That’s easy to understand. Now, software development can be agile, too (whatever that means).
Continue reading Words don’t mean what they don’t mean

Posted on by — 2 Comments

What is software development?

I’ve heard it said that there are basically two ways to understand a thing: (a) by direct experience, or (b) through metaphor. People who need or want to understand software development, but who don’t develop software themselves, often rely on metaphor. They are like the six blind men who try to describe an elephant. (That was a simile, not a metaphor.)

Software development is a unique sort of activity, with its own distinctive characteristics. Yet, as a way to try and understand the nature of software development, people have used various metaphors to describe it. Software development is a wall, or a rope, or a spear, depending on which part of the elephant a non-developer happens to touch.

Metaphors are something like conceptual models. Little ones. As George Box wrote, all models are wrong, but some models are useful. The popular metaphors about software development are wrong. They are wrong because they do not capture the exact nature of software development completely. The metaphors are also useful. They are useful because each one of them does capture some interesting aspect of software development in terms that people can relate to.
Continue reading What is software development?