Section 1.3. Dirty Secrets of Software Projects

1.3. Dirty Secrets of Software Projects

Software projects can fail for many reasons, and one of them is a bad development environment. Here is an informal list of some frustrations and embarrassing mistakes commonly made in producing software. None of these have anything to do with failures caused by things like missing specifications, specifications changing over time (the dreaded "feature creep"), poor estimates of how long a project will take, or even whether the problem being solved is a really difficult one. Each of these problems is due to the tools or processes of the environment in which the software was produced:

• We can't rebuild the same product that we shipped to the customer, so we'll ship her the latest version, just to be safe.

• Building from scratch (also known as a clean build ) each time is often the only way to get the product to build reliably. This takes so long that the developer goes off and does something else. Consequently, every developer thinks that his build tool is too slow.

• Testers, technical writers, and managers can't build the latest version of the product. Even if it has already been built for them by someone else, it's unclear where to find the latest version.

• Fixes for known bugs are not released, because it's too hard to properly test the required changes and they may break other parts of the product.

• Everyone finds the bug tracking tool awkward to use.

• The environment used by developers and the one in which the product is used by customers are different in some important ways, so the developers never actually see problems the same way that a customer does.

• Getting a product ready to release takes so long that any late-arriving changes don't get tested or documented.

• The wrong set of bits gets shipped to the customer. This one should make anyone involved in developing software wince, but it does happen.

• Nobody knows when to remove a feature from a product, because no one knows whether the feature is actually being used.

• Communication between groups happens by reading printouts left at the printer nearest to the coffee machine.

Sadly, the list could go on and on. Its contents are obviously subjective , but each entry has happened in real projects. The good news is that none of these Dirty Secrets are inevitable and they can all be eliminated with careful attention to the development environment. The promise of this book is that you can stop these kinds of embarrassments from happening to your project.