Tuesday, July 19, 2011

Importance of Well Designed Software

Refactoring: Improving the Design of Existing CodeAt the 2011 Agile Development Practices West conference, Martin Folwer addressed trade-able quality.

Martin explains that quality is something we can trade-off for other things. We often hear managers saying “We need to put less effort on quality so we can build more features for our next release.” We also do this every day. We do it when we buy a car. Sure we want the fancy car, but we go for the cheaper one and spend the extra savings on something else. This is a natural part of how we think about the things that we buy every day.

In software, there are visible and invisible quality features. For example, with a UI, you can feel the difference. But internal quality is not visible to the users. As a buyer, if I can’t see it, why do I want it? In that case, I will always pick the cheaper option.

Next Martin introduces the Design Stamina Hypothesis to illustrate why we should care about internal design of software.

Figure 1 - Stamina Hypothesis

The graph shows functionality over time.
The blue line shows bad design. We start out strong, but fade and slow down over time.
The red line shows good design. We start out strong and over time, we can keep a steady pace and even speed up.

With the clean system, a year from now it will have another 5 new features. The bad design system will probably only have 1 or 2 new features as they struggle with their bad code base.

Next Martin introduces the term technical debt which was originally coined by Ward Cunningham. Complexity that we don’t need causes extra effort to add new features. The unnecessary complexity in your code base is like the principal of a debt and the extra cost that you pay for adding new features is like the interest on the debt. This metaphor is useful when talking with non technical people. When building new software, you can choose a quick and dirty approach, increase your debt and increase your interest payment. Or you can pay down the principal and reduce interest payments.

Martin then explains the reasons we get into technical debt.

Figure 2 - Technical Debt Quadrant

1. Prudent/Deliberate: “We must ship now and deal with consequences” – This is a conscious decision. I have a deadline and I’m prepared to tradeoff some quality to meet that deadline.

2. Inadvertent/Reckless: People have no clue about software design.

3. Deliberate/Reckless: Very close to prudent/deliberate however, it is done without understanding what is going on. The decision to trade-off quality (debt) for speed only makes sense when we are below the design pay-off line (where the 2 red and green lines cross in figure 1). The key is to understand how far away the design pay-off line is. It is probably in the order of weeks and not in the order of months. It is a lot shorter than what people tend to think it is. If I am close to the point where I go over the design pay-off line, then there is no point in sacrificing design for speed because them I will end up losing both.

4. Prudent/Inadvertent – Here the financial metaphor breaks down. This case is when we’ve taken on debt without noticing it. It is because we learn new things as we code and when we look back at what we coded we say “Now we know how we should have done it”.

Clean Code: A Handbook of Agile Software CraftsmanshipThis presentation is available on youtube at http://www.youtube.com/watch?v=p5Qj75nJPEs (starts at minute 29:05)

Martin also discusses technical debt on his blog http://www.martinfowler.com/bliki/DesignStaminaHypothesis.html and http://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html