Category: Uncategorized

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?

Posted on by — 2 Comments

Delivery mode

This is the third of three posts dealing with aspects of management that I consider significant in choosing management techniques and metrics for software development and support:

  1. Iron Triangle management
  2. Process models
  3. Delivery mode (this post)

Despite the many complexities of software work, we are always working in one of two modes:

  • Discrete project
  • Continuous support

By discrete project mode I mean a mode of operation in which an organization creates a special initiative that exists for a defined period of time whenever it needs to achieve a set of related objectives, such as creating a new software application or upgrading the routers on the corporate network.

In contrast, with the continuous support mode of operation, the organization maintains a stable team to support each technical asset (such as the corporate network, a business rules engine, a COTS CRM package, or an ETL product) or suite of applications (such as the suite of applications that support consumer lending in a financial institution) throughout its lifetime. The size of the team may grow or shrink depending on the level of work needed to support the asset or applications at any given time, but the organization does not start a new project for every set of objectives pertaining to the asset or applications.
Continue reading Delivery mode

Posted on by — 8 Comments

Process models

This is the second of three posts dealing with aspects of management that I consider significant in choosing management techniques and metrics for software development and support:

  1. Iron Triangle management
  2. Process model (this post)
  3. Delivery mode

In my experience, no two organizations, and no two teams within the same organization, use exactly the same process model for software delivery; nor do they keep the same process intact forever. Everyone tailors their process to their own needs and to the realities of their own situation. In addition, most organizations use more than one process, depending on the nature of each particular initiative or work stream.

That is as it should be. Yet, despite the many variations, there are common patterns that can help us understand how we might plan and track the progress of software development initiatives and support activities in ways that help us make management decisions, as opposed to merely following a published guideline for planning and tracking.
Continue reading Process models

Posted on by — 5 Comments

Iron Triangle management

This is the first of three posts dealing with aspects of management that I consider important:

  1. Iron Triangle management
  2. Process model
  3. Delivery mode

The reason I think these aspects are important is that they affect the way we handle various management issues, particularly our choice of metrics. Metrics that apply to one option in one of these areas may be meaningless or misleading when applied to a different option.

As George Box famously wrote, all models are wrong but some models are useful. The model I present here is based on my own experience and observation. It is wrong by definition by virtue of the fact it is a model; but hopefully it is useful, as well.

The order in which the aspects are listed reflects their relative effect on our choices, in my opinion. The strongest effect comes from our approach to managing the Iron Triangle. That is the subject of this post.
Continue reading Iron Triangle management

Posted on by — 3 Comments

The problem with success (and failure)

This morning I noticed a copy of the good old Cone of Uncertainty on the wall of a cubicle at a client’s office. It reminded me of Laurent Bossavit’s ebook-in-progress, The Leprechauns of Software Engineering, in which he challenges several of the myths or assumptions that have become traditional lore in the software industry, including that one.

Laurent writes,

What is odd, to any experienced software engineer, is that the Cone diagram is symmetrical, meaning that it is equally possible for an early estimate to be an over-estimate or an underestimate. This does not really square with widespread experience of software projects, which are much more often late than they are early.

Er…wait a second. Isn’t that very assertion an example of “anecdotal evidence?” Is it another Leprechaun? Who says projects are more often late than early?

Silly Dave! Everyone knows who said that. It was the Standish Group, in their famous Chaos Report of 1994. Slightly more than 70% of IT projects fail. That’s why every office building in the industrialized world is on fire, and white-collar refugees are streaming from the cities, leaving their belongings behind except for whatever personal electronic devices they can carry.

Only…they aren’t.
Continue reading The problem with success (and failure)