Back to the Gold Rush

Gold rush software projects are inherently risky, but the use of haphazard software development practices has unnecessarily added even more risk. Developers working on gold rush projects have been saddled for decades with the methodological equivalents of tin pans and shovels. The result is that many of their insights, ideas, and innovations are needlessly lost, just as the Ernst and Young team's work was needlessly lost due to lack of source code control.

Systematic approaches to software engineering are necessary for post-gold rush projects to succeed; they are equally useful for projects still in the gold rush stage. What would have happened if the original designers of VisiCalc, Lotus 1-2-3, MacOS, the Mosaic Web browser, and other ground-breaking products had overwritten their working files? How many innovative products have we never heard of because their developers did overwrite their working files? And how many have succumbed to more subtle errors?

During a gold rush, you can be terribly sloppy and not very skilled and still make a fortune, but the odds are against you. After a gold rush, you have to be more disciplined and more skilled just to break even. The entrepreneurial buzz a person gets from participating in a gold rush project is one of life's great thrills, but there's no conflict between entrepreneurial energy and the use of effective software development practices. By examining the practices that work well in post-gold rush environments, you can gain insights into practices that work best when you have Gold Rush Fever, increasing your chances of ultimately hitting pay dirt.