The Old School Manifesto
Mon, 10/11/08 – 22:08 | 2 Comments

As we saw in the last essay, the 80:20 rule seemingly appears in many circumstances. When I was attending college and working as a programmer during the 80’s, there were some commonly accepted tenets that guided our software development processes and behaviors.

Read the full story »
Management

Methodology

Metrics

Quality

Requirements

Home » Design

Don’t Code Yourself into a Corner

Submitted by Bill Miller on Tuesday, 5 August 2008 2 Comments

freecell

I enjoy playing FreeCell.  It’s a form of stress release for me, sort of like smoking is to some.  Whenever I need a quick break or I’m looking to take my mind off of something, I’ll often play a game of FreeCell.  

FreeCell is a puzzle, requiring analysis and strategy to win.  They say every game is winnable, and I believe that it’s likely to be true.   Whenever I lose a game and I’m determined to win, I eventually win after repeated retries of the same game.

Recently, when playing FreeCell to take my mind off an essay I was writing, a thought occurred to me: FreeCell illustrates the value of upfront analysis and design.  On a number of essays on yuwantitwhen.com, I’ve advocated that doing proper upfront analysis and design on our software projects is the best way to secure success for our projects and to shorten schedules.  Similarly, in FreeCell I’ve won more games on the first try when I devoted more time to upfront analysis and developing a strategy.

How to Play FreeCell 

For readers unfamiliar with the game, the objective is to discard all the cards in order starting with Ace to King for all suits.  The game is setup by distributing all the cards face up along eight columns.  Play begins by moving cards to the other columns, the temporary pile, or to one of the four discard piles.  To move a card to another column, the card being moved must be the next sequential card in descending order and must have the opposite color: for example, red must follow black and visa versa, so an 8 of diamonds (red) can only be placed on a column where the top card on the column is a 9 of spades (black) or 9 of clubs (black).   Only 4 cards can move to the temporary pile; any card can move there.  Cards can be removed from the temporary pile to any of the columns or to the discard piles.

The strategy is to move cards to other columns or the temporary pile to build the 4 discard piles in order beginning with Ace.  The game is won when you have moved all the cards to the discard piles, and the game is lost when you cannot move any cards to the temporary pile, to any column, or to any of the four discard piles.

Approaches to Playing FreeCell

There are two approaches to playing the game: one, evaluate only the moves that are currently available to you by only evaluating the top cards of each column or the cards in the temporary pile. Let’s refer to this approach as shallow analysis, or two, evaluate successive moves before deciding on a move.  Let’s refer to this approach as deep analysis.  While it is possible to win with shallow analysis throughout the game, the probability of winning is low.  I’ll often start a game with the first approach then after a few moves switch to the second approach to make the game more challenging.  I can’t recall ever winning a game without doing some amount of deep analysis.   Early deep analysis improves the odds of winning on the first attempt of a game.

What FreeCell Teaches Us about Software Projects

Here’s what the game of FreeCell teaches us about upfront analysis and design.

  1. Reworking (refactoring) is expensive and it lengthens schedules.  When I play using shallow analysis, it takes many more restarts of the game before I finally win it.  To win a game with less restarts - even zero restarts - the likelihood increases significantly with quality deep analysis before moving.  Similarly in software, schedules are shorter when the solution is well analyzed and designed before writing code, resulting in less rework or reimplementation.
  2. Anticipating the future results in less rework and reimplementation.  In FreeCell, evaluating only the first level moves before moving makes it more probable that you leave yourself with no possible moves later in the game.  A player can avoid being locked in a corner with deep analysis before moving.  Similarly a software team can avoid rework and reimplementation by anticipating future requirements or preferably by creating a design that is easily extensible.
  3. Winning every game of FreeCell on the first attempt is possible with deep analysis if it is true that every playing combination is winnable.  The most difficult upfront investment is on the first move.  It is the most difficult to analyze and to get correct, but if you desire the highest probability of winning — even certainty of winning — there is no shortcut to this upfront investment.   Similarly, in software the first release is the most difficult release to analyze.  It’s a blank sheet of paper.  The possibilities are seemingly infinite.  It’s not difficult because it’s a wrong approach; it’s difficult because it’s hard.  As in FreeCell, a project team improves their likelihood of success with enough upfront analysis and design.
  4. Starting a game with deep analysis results in faster analysis later. As a consequence of analyzing a game well, it becomes easier to make successive moves as the game evolves.  Similarly in software when an application is well designed, successive releases of that application become easier and faster.

Summary

Modern approaches to software development advocate an evolving approach to software construction with shallow analysis as its principle.  They trade deep analysis in favor of faster delivery for today’s requirements.  While that approach may succeed in creating a quick first release (only if shallow analysis does not lock you in a corner in the first iteration), it is sure to require rework and reimplementation on future releases.

As in the game of FreeCell, upfront analysis and design improves the likelihood of delivering a successful software release.   Deep upfront analysis and design avoids rework and reimplementation, and consequently, it shortens project schedules.   If you are looking to improve the project team’s chance of success, shorten schedules, and control the budget, deep upfront analysis and design as demonstrated in the FreeCell analogy is a method for securing those objectives.

How much upfront analysis is enough you may ask?  It depends.  How important is it to hit your release date?  How important is it to deliver on budget?  How important is it to secure future releases?   To the degree that these objectives are important to your organization, you invest in enough upfront analysis and design to give yourself confidence commensurate with the importance of hitting your date, meeting your budget, and securing future releases. 

This investment is not measured in time; it’s measured in the quality of analysis and design.   If the investment is too expensive, consider the alternative:  you are more likely to be late, over budget, and hamper future deliveries if you don’t invest.  Of course, not every project requires high certainty of hitting the date and the budget, and some products never have more than the first release.  For those projects, other approaches may be better.  But, know the tradeoff before you embark on your journey.

Email This Post Email This Post Print This Post Print This Post
Vote This Post DownVote This Post Up (No Ratings Yet)
Loading ... Loading ...

Related Articles:

  • Commit To Excellence
  • Upfront Analysis Saves Time
  • Good Design is Important
  • Simple by Design

  • 2 Comments »

    • Tzvika said:

      Reading your FreeCell analogy made me think of another analogy, between the game of Chess and software projects. It’s the same principle - the more steps ahead you are able to calculate in a given position, the better the odds of success.

    • Bill Miller (author) said:

      Hi Tzvika,

      I like the idea of Chess as another analogy. When I first thought of the FreeCell analogy, I began to think of others, and Chess was one of them. I chose to stick with the FreeCell analogy because of the certainty of winning.

      However, your comment made me rethink using chess as analogy. There are a few good points it brings out:

      One is that the play evolves depending on the moves your opponent makes, yet if you want to win, you still need to analyze every move well. It refutes the idea that deep analysis is ineffective in a world of changing requirements. In chess, out thinking your opponent is part of the analysis, even though you cannot predict what move he’ll make next.

      Also, Chess and even FreeCell, analysis requires less time with more experience and skill. The idea that analysis and design can be paralyzingly lengthy in software is a reflection on the quality of the people rather than a reflection of an inherent attribute of analysis and design; talented people with good experience develop great designs quickly just as in chess and freecell where your play speed improves with experience and skill.

    Leave a comment!

    Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

    Be nice. Keep it clean. Stay on topic. No spam.

    You can use these tags:
    <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

    This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.