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
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
) 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
are not released, because it's too hard to properly test the required changes and they may break other
of the product.
Everyone finds the bug tracking tool
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
The wrong set of bits gets shipped to the customer. This one should make
involved in developing software wince, but it does happen.
Nobody knows when to remove a feature from a product, because no one
whether the feature is actually being used.
Communication between groups happens by reading printouts left at the printer
to the coffee machine.
Sadly, the list could go on and on. Its contents are obviously
, but each entry has
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.