No substitute for understanding

A beginner to software development might model it like this:

money to features

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.

money to quality and features

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:

money and agile to features

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.

complex agile

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.

4 thoughts on “No substitute for understanding

  1. Rick Cecil says:

    Great post and interesting diagram.

    Couple of thoughts:

    1) I think you’re missing something from the last diagram: Prioritization of features between relevant features and Money. There might be 100 relevant features, but only 10 (or even 1) that get prioritized for that development cycle.

    2) I’m not sure it’s up to the developer to know when to take advantage of different resources. Seems like it should be a conversation between the leads on the project–ideally, there would be 3 leads (Tech, User, and Biz) with one taking point depending on the nature of the features getting built and the point in the process. Between the three of them, they should be able to discuss the value of assigning different resources to the different features being developed. Ultimately, you’re right, it has to be a judgement call based on the people and skill set available.

  2. Antti Tarvainen says:

    Thanks for the comment, Rick.

    1) You are right about the priorization of the features. It is an absolutely essential part of software development and would make the diagram more complete. I started drawing a more complete diagram, but it quickly became too complex to be readable. So, I’ll leave the diagrams as they are.

    2) I think developers should strive to understand software project issues regardless of their position in the project. The developers are closest to the code and can see things the people higher in the hierarchy cannot. They have the responsibility to talk about possible issues in the project.

    E.g. “The quality of code in Foo module is not high enough, and will cause us trouble if we don’t do anything about it.”

    In very small cases (e.g. refactoring of a single function) the developer can estimate the value by himself and may not need to bother others about his decision. The larger the issue the more important the communication between the stakeholders.

    As you note, in large issues the leads probably make the decisions. However, even the large conversations may need to be started by the developers, and therefore it is important that the developers cultivate their understanding of the resources.

  3. Simo says:

    I wonder if the comments closed on purpose in the later posts.

    [Thanks for noticing. I turned the comments back on. – Antti T.]

  4. […] No substitute for understanding : […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s