IEEE Software Essays on Continuous Design

I write the Pragmatic Designer column for IEEE Software and I’ve been using that to lay the foundations for my ideas on Continuous Design. Here’s a sequence of essays that talk about how teams design, how that design evolves, and how teams keep the design on track.

Intellectual control

Teams have confidence in their code because their tests pass (statistical control), and because they designed the code to make sense (Intellectual control). Today, we lean too heavily on testing to give us confidence and we lose intellectual control. Most developers haven’t noticed because Testing numbs us to our loss of intellectual control.

Teams do what they think is the modern, right thing, but The rituals of iterations and tests don’t yield low tech debt or intellectual control. To get that, they must deliberately choose to keep the design conceptually simple and visible in the code. Once lost, intellectual control is expensive to recover.

Extended and distributed cognition

To create the conditions for intellectual control, teams must foster extended cognition (where the code becomes an extension of your thoughts) and distributed cognition (where the design of the system is shared across the team).

Extended cognition requires the code to be in a healthy state. Healthy code reveals the problem and solution. A reader of healthy code can see what the team knows about the problem domain and what design they have chosen to solve the problem.

When you create the conditions for intellectual control, that allows you to Scale your team horizontally. Each developer you add contributes proportionally to their ability, not based on their project tenure.

Ur-technical debt

Being able to design continuously means grappling with technical debt buildup, the kind that Ward Cunningham origially talked about – which I call Ur-Technical debt to distinguish it from the modern, overly broad interpretation.

To understand what ur-technical debt really is, we must recognize that code can run fine (that is, compute the right answer) but be a lousy carrier of our thoughts about the problem and solution. Code is your partner in thought, or it should be if you want extended cognition to work, or you want new developers to be able to contribute to the code.

Many of these ideas were already clear by the 1990s, as was software architecture. You might wonder, Why is it getting harder to apply software architecture? The reason is that iterative processes combined with factory metaphors (like reducing cycle times and work in progress) encourage developers to focus on the flow of features from request to delivery. That is in contrast to thinking of the system’s overall design, and its health. It’s possible to do both, but only for skilled, experienced developers.

Future essays will talk about: