The Spec
The Language
The Practice
The Books

In Small Packages

There are several advantages to taking a software project and dividing it into small pieces.

  • Missing elements get exposed
  • It easier for a developer to estimate
  • Something gets done sooner
  • Things can be prioritized
  • It gives customers a way out
No matter how simple or small a software project may seem to our customers, it is usually large to a developer. It isn't very intuitive, but breaking down a programming job into small pieces and only doing small parts may give the job a better chance of being completed successfully. Those who ask for software may not realize that the job of breaking down a programming job into small parts may mean that they will get to use the product much sooner.

It's easy to overlook something important when a user is describing their idea to programmers. It may not be obvious that something isn't being communicated. When a software customer breaks down the software into individual features, or even parts of features, it helps them to think it through more carefully. This practice may expose parts of the system that they forgot to mention. The practice also helps them to clarify their dreams into a more practical vision making it more likely that the thing they are wanting will be communicated to the programmers and be completed.

Developers don't seem to estimate a large job very accurately. In fact, most estimates are significantly incorrect. Rather than ignoring this fact and asking for a single estimate for a programming job, customers should be encouraged to break their product down into its features so that they can be estimated separately. This estimate gives software customers an understanding of the relative expense of the various parts of the product they are designing. This gives them a whole new benefit. It allows them to modify their product based on its cost in order to get the best possible product for the least possible cost. This is very difficult to do if the product is estimated as a single large whole. Having smaller parts estimated allows them to watch and see if the estimates are close or not and they can then adjust the estimates for the other parts based on what they learn from the first parts that are developed.

When a software product is broken into small pieces, it can be delivered in pieces as well. This means that a customer can get part of the product very early in the project. They can choose to start using the product while it is still under development. This offsets the cost of the product while it is being developed which can actually make the cost of the whole product less. The potential to earn money from the product while it is still in development is probably the single biggest thing that makes our customers happy when they go to the effort to break their product into pieces.

Because a product is broken up into individually shippable pieces, it can be prioritized so that the pieces with the highest value are delivered first. This ability to prioritize helps the customer to fine tune their instructions to the developer. The customer can actually change their priorities part of the way through the project as they see how the first parts are doing.

Sometimes, the idea isn't as good as was first thought. If the product is being developed as a single huge feature, it is difficult to gracefully back out of developing the product. Having the product developed in pieces provides a natural stopping point between pieces at which the project can be discontinued. This can provide our customers a little more happiness in that they don't have to worry as much about their investment in our work.

Troy Taft is the Principal Consultant and founder of Troy Taft Consulting, a firm specializing in high value software development. He also authors a free monthly newsletter called Software Matters.

Copyright 2007 Troy Taft All rights reserved, you may print this article for your personal use.