How building a bridge is the same as building software

This is not the simplistic analogy you may be expecting.

Where I live in Minneapolis MN, we have a high profile bridge project going on right now, due to the tragic collapse of the previous structure. If you look at the project page on the state's website, you can see the following "features of the new bridge":

• 100-year life span
• 10 lanes of traffic, five in each direction—two lanes wider than the former bridge
• 189 feet wide—the previous bridge was 113 feet wide
• 13 foot wide right shoulders and 14 foot wide left shoulders, the previous bridge had no shoulders
• Light Rail Transport-ready which may help accommodate future transportation needs
• Design-build project complete in 437 days.
• Designed to be aesthetically pleasing and fit in with its environment

These are the most high-level (public) stakeholder values for the new bridge. From an engineer's perspective, they are the constraints under which the bridge must be delivered. In addition, we see an architect's rendition (picture) of what the new bridge will look like. This is also a constraint - an engineer cannot add things that will substantially change the appearance of the bridge.

Now, we can be sure that the design of the bridge was a collaborative effort of a team of people. Engineers, Marketing, Architects and the client. Is the design ongoing as they build the structure? Yes - they are using a growing technique known as Design-Build - they purposely start construction before the design is complete.

At first glance, design-build might sounds like a simple case of parallel work - one team is working on designing just-in-time, and another is working on the construction. In practice though, there is a collaborative environment that reportedly results in avoidance of disputes, faster project delivery, and less need for project management oversight.

The Analogy
So how is this similar to building software?

Firstly, the process of programming it is like the design of a bridge - it is the bringing together of people in different roles to creatively find ways to build the end result. Ideally, development involves a lot of Thinking, Talking, and Tweaking, just like a bridge design. In design, we often find that two heads are better than one. Pair-programming has been suggested as one way to do this in software development. Of course, we have many other collaborative techniques to communicate and discuss design.

Like a bridge design, the output of building software can be represented by piles of paper. The bridge has drawings, engineering specifications and requirements. A program has something better though - its code. (No, I'm not arguing that "the code is the design". I'm just saying that the code "is a representation of the design"). The code accurately describes the parts of the design that it touches.

This "programming code = bridge design" point is key to what I'm trying to convey - the process of programming produces a design output, not a product. The final product is the result of implementing that design (just as the bridge itself is the result of implementing its design).

Specifically, the "building" is the deployment of software in its final environment. Deployments are where the "tires meet the road" - they are the intersection of the design with reality (just like construction). Mostly, the design holds up and does not need tweaking after deployment. Sometimes though, the harsh lights of reality expose the hidden flaws in the design. (In light of that, it is best to expose an application to its first deployment as soon as possible).

Some software groups have QA (quality) departments. Historically, these departments have taken the role of performing trial deployments - they will take the software, and expose it to a simulation of the real environment. Large construction projects also have this role - an independent group audits the designs, with the hope of spotting problems that would cause a problem when the construction occurs.

Finally, we find that the best way of constructing a large bridge project is to simultaneously design and build. The analogy for software is small frequent releases. Research and experience has shown this to be a good way deliver quality software that meets the requirements.

Conclusion
If we accept that building a bridge and building software are similar (they contain the same basic steps), then we can use that information to produce some interesting insights:

• That thing we need to do before developing is "architecture" - There is a fine distinction between architecture and design. The way I like to define it is that architecture describes the parts are visible from the outside, and design describes the inside. A bridge architect is able to construct a working model and rendition of the outside of a bridge without the full engineering specs. To do this, he needs to take into account all of the stakeholder values. Similarly, we need to be able to draw the edges of a software application before we start - we need to understand how the software will interact with the outside world, and how the outside world will interact with the software.
• QA is a misnomer - the primary purpose of a separate QA department should not be to assure quality. We can get quality in better ways than that. The purpose of the QA department should be to validate the design of the software, by simulating real environments. Many QA professionals already know this, of course.
  

This blog post is inspired by a set of three essays by Jack W. Reeves.

My Kanban Technique

In software development, a kanban board is a way of putting your todo-list (backlog) on a whiteboard using one post-it per item. I have been experimenting with my own style of kanban board for some time now. Its benefits are:

• measures velocity (how quickly the development team can deliver new features)
  
• measures the impact of bugs on the development team
  
• measures the quality of planning and estimates
  
• over time, allows you to fine-tune the overhead of planning and estimating
  
• allows client to prioritize as often as they want
  
• provides detailed visibility into what developers are doing (information radiator)
• does not require fixed iterations

The above benefits are substantial, especially considering that the technique adds almost no overhead. It requires a short daily stand-up meeting of developers, in front of a whiteboard. It requires you to breakdown features into small, manageable chunks. If you already do Scrum, that adds zero daily overhead, and may well allow you to subtract some.

The technique works well for generalist-style teams of developers. (A team of 5 specialists working individually on separate parts of the application will not get the full benefits of the technique).

Moving on. Materials you will need:

• large whiteboard with colored erasable markers
  
• post-its (size 3x3 inches are ideal)
  
• sharpie or other bold pen to write on the post-its
  
• small colored stickers (at least 3 colors)

The technique is very simple, but it has multiple dimensions. I will explain it in terms of those dimensions. First dimension deals with the flow of post-its on the whiteboard.

Each post-it will represent a system feature. For planning purposes, you should aim to size the post-its to around 2 development days, i.e. it should take a single developer no more than 2-3 days to develop the feature. That said, the technique allows larger post-its (with increased risk). Simply use a different colored post-it for features that are too large (we use pink for large, and yellow for normal). You can also mark an existing post-it with a red-X to indicate it is too large.

The whiteboard will be divided into several sections. Post-its flow from left to right and never back.

The first area is the "broader backlog". For each planned customer-identified feature, place a post-it in this area. Large (pink) post-its are acceptable in this area.

Next is the "release planning area". Its purpose is to group together the features that will be in the next release of the software. In order to transition to this area, large pink post-its must be discarded and replaced with smaller post-its, as much as possible. This implies some sort of planning and estimating meeting. The technique allows for variances in post-it sizes, so do not stress estimating too much. Just break it down as much as feasible. Later on you will have a measurement of estimate quality, and can use that to motivate spending more or less time estimating and planning.

For Scrum users: There is no need for the 2-day items to be customer-focused. At this point, if your client agrees, then you can break-down into technical tasks.

For each release, count and record (on the whiteboard) the initial number of post-its. We will call this the "size of the release". Later, once we have measured velocity, we will be able to simply divide the size by the weekly velocity to reach the estimated weeks until release.

Next area of the whiteboard is the "current backlog". This is a prioritized area where higher priority items are towards the top, and lower priority items towards the bottom. The area is limited in that there is only space for 7 items. (7 is a good starting number - you can tweak the number later). The area represents a "turnaround guarantee" to the client. We will say that the client can put anything (sized appropriately) at the top of this area, at any time, and we will have it done within X days. The X days is calculated based on the team's velocity. For example, if the teams velocity is 1 post-it per day, then we will completely empty the current backlog (max 7 items) in 7 days. Based on this, we can guarantee (not 100%, but close) a turnaround time of 7 days.

When I said "the client can put anything" in the current backlog, I really mean *anything*. The item can be a bug, a new unforeseen feature, or whatever. It does not matter. They write it on a post-it, and put it in the current backlog.

Developers pull items from the current backlog, usually from the top (high priority) down. If possible, they should avoid pulling more than one item at a time.

Next whiteboard area is the "developer assignment area". Each developer has a small box with their initials. When they pull an item from the backlog, they place it in their box.

Next area is the "impediment area". When a developer cannot proceed on an item (waiting on purchase of 3rd party component for example) then they move it out of their box into the impediment area. Next to the impediment, they write the reason. While impeded, the developer stops working on the item. They can pull another item from the backlog. Impeded items are escalated as needed. Once they become unimpeded, they are moved directly back to the developer that was working on them.

When done with an item, the developer can move it to a "done" area. This is drawn like a weekly calendar, and the developer simply places the done item on the day on which it was completed. Done items stack up beneath each day (and provide a surprising sense of accomplishment).

If you have additional steps between the developer saying they are done and acceptance of "doneness", you can add those as areas in the whiteboard. The following is important though:

• If an item needs to go backwards (from tester to developer for example), then the post-it should not move backward - rather create a new post-it and leave the existing one where it is. (This is important to our effort to quantify the effect of poor quality).
  
• Someone must be responsible for removing items from every area. For example, if no-one is actually doing work on assuring quality then do not invent a quality area.
  

And that is how the post-its flow. Pretty simple, but by itself, it does not give you much.

The next dimension is the colored stickers. Each post-it is decorated with stickers, in the following way:

• blue - bugs. When an item has been assumed to be done (placed in the "done" area), but a bug is discovered, then a new post-it is added to the current backlog with a blue sticker (don't move the "done" post-it back).
• green - missed requirements, or post-its that are "broken out" from larger features during development. Green items can sometimes represent just-in-time work-breakdowns. For example, a developer can take an existing post-it in his area, break off another post-it (with a green sticker) and place it in the current backlog.
  
• red (optional) - for each day that a developer works on a post-it, it is decorated with a red post-it. Too many red post-its is often an indication of a problem that needs to be escalated.
  

The final dimension is the measurements. There are 3 measurements, taken weekly (first thing on Monday works for me). The measurements are all performed by counting post-its in the "done" area. Once counted, the post-its are removed from the white-board. They are:

• Velocity. Count each post-it, except for those with blue or green stickers. Higher is better.
  
• Estimate Quality. Count each post-it with a green sticker. Higher is worse.
  
• Product Quality. Count each post-it with a blue sticker. Higher is worse.

And that's it, in a nutshell.

Velocity is measured relative to the release planning area, which is the only way that is meaningful to a client. Use velocity directly to plan releases and choose a max size for the current backlog area.

Estimate quality is a measure of the risk of using your velocity for planning purposes. Each point was an unknown at release planning time. We did build the risk into the velocity, but a high enough value is...risky. If that is a concern, then you need to spend more effort planning and estimating.

Product Quality is a measure of how bugs are affecting your ability to implement new features. A high value means that you should put more effort into improving quality before saying something is done. This is almost always a good investment.

Goal Driven Development

One of the foundations of all Agile techniques is that of frequent iterations developing working software. I think maybe this is a developer-centric view of a deeper concept.

When we talk about iterations, what we are really trying to do is to work with a client to break down their "big goals" into smaller ones. We ask them to call these mini-goals "stories" or "backlog items". Perhaps "goal" is a better word. Why...?

For one thing, it is less feature-attached. A backlog item or story usually translates to a feature. Maybe thats not the intention,but that is how it works out.

I'm digressing though. The main thought is that one or more iterations fulfill some client goal. This goal often corresponds with a release. That is a very concrete view of reality. Anything smaller is not meaningful to a client.

We ask them to shuffle backlog items around in order to decide which features make it into a release. What we should be asking them to do is to decide on the minimal set of functionality that meets their goal. Anything after that is meeting some other goal.

On another tangent...

When we ask developers to think in terms of backlog items and stories, we are making it too easy for them. They need to be made aware that the code they write has to work towards the client's goals. If a "feature" can be avoided or changed by meeting the goal in another way, then the developer needs to realize that.

For example? .... The client proposes a feature. Under certain circumstances, when the user clicks the Save button, we should pop up a dialog asking them if they are sure they want to do this. They must click "Yes" to continue.

Seems like a pretty normal feature. It will make a fine backlog item. But what is the goal of the client? In this example (based on real-life), the answer was that we needed users to manually assert their intentions.

The implementation of a dialog box is a poor solution (as it almost always is). A better one was to supply a checkbox that became enabled (and required) when the right conditions occurred. Thus, the user had to pro-actively assert that they were sure this is what they wanted.

The point is this - when we tell developers to think in terms of backlog items, we are really saying "think in terms of features". Experienced developers will intuitively sidestep this and get to the real goal. Less experienced developers will do exactly what the backlog item suggests.

If we had stated the requirement as a goal instead of a feature, then the less experienced developer would have had to suggest the details of the feature. This implies design, and thought. Exactly what we want in an Agile environment.

Motivating a team

A while ago I did some research on the psychology of motivation, to discover ways that I could relate to our software development team that would support them being motivated.

I won't go into the gory details (since it is was a while ago and I have forgotten my references), but what I came out with was that in order to be happy, a person should experience the following:

• competence - they should feel like they are good at their job
• autonomy - they should feel some sense of being able to choose how they work, and what they work on
• relatedness - they should feel that they are a part of some larger whole

This balances out over a person's day-to-day living. So if I have no relatedness at work, the only way I can be truly happy is if I find a lot of relatedness elsewhere, such as participating in a sporting team.

Happy goes a long way towards supporting motivation, so in order to motivate someone, I should endeavor to make them happy.

Thinking in this way has helped me avoid repeating mistakes. One thing I had been guilty in the past was throwing unrealistic learning curves at people. But, a learning curve (while useful) temporarily reduces a person's feelings of competence. If they feel lost, then they can also feel alone (relatedness).

Even small changes can push a person over the line, to the point where they start looking for a new job. I still throw leaning curves at people, but I try to do so in a much more supportive way.

I try to filter my thinking at work by considering whether different things increase motivation (by supporting feelings of competence, autonomy and relatedness), or decrease it:

• how do the work-processes we use affect the people that are using them?
  
• as a person with much more experience and knowledge, how do I interact with people with less of those things?
• how can we introduce a new employee to work in a way that makes them more likely to stay with us