No substitute for understanding

A beginner to software development might model it like this:

This shows two activities in software development: you pay software developers to produce features and then sell those features to customers. It’s about the best you can do without having experience in the field. There is a methodology based on this model. It’s called Code and Fix.

Martin Fowler recently wrote about design stamina. Among other things he said:

Indeed I’ve come across the impression a couple of times that design effort is tolerated to keep the programmers happy even though it reduces speed.

Here’s how I conceptualize it. A software development novice — a manager perhaps — hears about “code quality” and that “design” is used to produce it. Design costs money and code quality helps developers write features faster.

The problem is, he doesn’t know of how much design is worth compared with just writing features without design. Undervaluing design leads to bad code quality and keeping to code-and-fix. Overvaluing it leads to analysis paralysis (in big design up front) or just low velocity (in agile methodologies).

Fowler presents a pseudo-graph of two hypothetical projects, one with design and one without:

 

Design builds stamina that helps keep the productivity high. Although design costs more early on, once a payoff line is reached, it beats the code-and-fix development. Most experienced software developers would agree on the idea behind this model. The interesting question is the location of the payoff line. Fowler says:

Even with people who accept the design stamina hypothesis there is substantial, and important, differences over where the payoff line sits. I take the view that it’s much lower than most people think: usually weeks not months. But again this can only be a judgment call.

Our software development novice cannot make the judgement about the value of design, because his conceptual model is not rich enough. The general phenomenon here is that there are many sides to learning:

• Recognizing new resources. (Code Quality)
• Learning how resources help create other resources. (Money ==Design==> Code Quality)
• Finding the right resource exchange rates. (The location of the payoff line.)
• Improving the efficiency of resource creation. (Designing better and faster.)

Learning only one side is superficial adoption of the knowledge. It is never enough.

Sarah A. Sheard’s excellent Life Cycle of a Silver Bullet inspires another example of superficial adoption. Say that a CEO decides to hop into the agile bandwagon, and mandates the following methods to be used in every project:

This will not work. The methods are just the surface. The core of agile is the identification of the key resources and their worth. The agile values, if you will.

Adopting agile methods fits the number 4 in the list above. They are good practices (some would say they are the best practices) to create different resources: TDD helps write better tests and better code, continuous integration helps visibility, and so on. They are useless if the developers don’t understand the meaning of those resources. The developers would not know when and how much to do each activity: when to add tests, when to refactor, when to add new features.

Having a more complete picture helps, but is still not enough. There’s the task of finding the worth of each resource. But, that can only be a judgment call.

Learning games

Last week I found the world of online board games at Brettspielwelt. I have mostly played a game called Thurn und Taxis, which is about making postal routes in the renaissance Germany. Players collect cards that represent cities, and then play those cards to build their routes on the board. The game is easy to learn, fast-paced and fun.

The learning of strategy in most light-weight board games revolves around determining the right value for each resource. In Thurn und Taxis, for instance, not all cards are of the same value. Some cities are in key points on the board, and acquiring those cards early is of high importance. It takes a few games to realize which of the cities are most important, and more games still to find more fine-grained distinctions between their values.

But the learning curve bends early and then falls flat. The resources are very concrete and obvious from the start, so it comes down to just learning the values of those resources. Once you’ve learned the values of different cards, the value of blocking opponent versus building your own routes, and the value of ending the game quickly, there is not much left. After that, the game is still a fun way to kill time, but it doesn’t bring the deep joy of learning.

Contrast this to a strategically more complex game, such as go. The rules of go are simple, and learning the game is easy. There are many strategic concepts that a player learns during his first few months. Much of the learning is finding the right balance between those concepts: When is influence more important than territory? When is shape more important than sente?

The difference to Thurn und Taxis is that these concepts are abstract. The Stuttgart card is a very concrete resource, and most of learning Thurn und Taxis is finding the right value for that card and its kin. It is obvious from the start that to play well, you have to know how much the Stuttgart card is worth. In contrast, looking at the rules of go, you would not guess that shape is a a useful strategic concept, or even that there is such a thing.

So there is only one class of learning in Thurn und Taxis, and that is learning the values of resources. There are two kinds of things you learn in go: the abstract concepts and their values.

(Okay, I am simplifying. In fact, there are useful abstract concepts in Thurn und Taxis, even one resembling the concept of shape in go. But there are not many of them, and their importance is less than the luck factor in a single game.)

The deepness of go is its width of abstract concepts. I have played go for years and cannot claim to understand concepts such as sabaki or tewari very well. There are probably concepts that are central to the professional players, but that I haven’t even heard of. That’s the reason go is so enjoyable: there is something new to learn at every level.

So what has this to do with software? That’s what I will talk about in the next post.