Bootstrapping the Development Process
bootstrap: transitive verb: to promote or develop by initiative and effort with little or no assistance.
A software development project is often about starting up. New people join the project. As the code reaches maturity you release it to different teams for testing, production and the like. If there is a problem in production a developer needs to recreate the codebase as it was at the time it was released so that they can do development. Each of these steps requires that you create an appropriate workspace, build the application, and deploy and install it. Having an automated process to do this reduces the risk of miscommunication between phases and allows each phase to proceed smoothly. Consider the following scenario
Melissa joins your team and is excited about contributing to the next version of YWA (Your Web Application). The first thing she starts to do is to set up a development environment so that she can see how the application works. Her needs seem simple; she wants to:
- Get the code for the application and place it into her workspace so that she can do development without interfering with the work of other people, especially since she is new to the codebase
- Build and run the application—in this case the application is a web application, so there is a “deployment” phase—she already has a local copy of the application server installed
Melissa is aware of some of the patterns for agile Software Configuration Management, so in her mind, she assumes that she can use the Repository Pattern to help her execute a Private System Build in her Private Workspace.
She checks the code out of the version management system, runs a build script, executes a "deploy" target, and tries to run the application. Nothing works.
Ted, who sits in the next cube, explains that it "takes a while" to get the app set up, and that since he had it working, he hasn't tried to run the build and deploy script as it. Anyway, he is kind of busy fixing the many problem reports that the product has spawned, so he points Melissa to an email exchange that he had with his neighbor when he started the project. After much manual effort, Melissa can finally run the application. She prays that she will never have to install this from scratch again, since, while she thinks that she knows all of the steps, there may be a few that she forgot to write down.
Two questions come to mind:
- What is wrong with this picture?
- Why does it sound so familiar?
We can attempt to answer the first question. The answer to the second revolves around the fact that most organizations do not fully understand the costs of ignoring this problem.
The Costs of a Manual Build Process
The process that Melissa had to go through illustrates some of the problems and costs of not having an automated, simple, build process:
- It takes a lot longer than necessary for people to get started on a project. While some learning curve is always needed, that extra energy is better spent on interesting things that are not easily automated
- This process is not repeatable, meaning that there will be more surprised than expected. You'll here the phrase "Works for me" more often than not because no everyone is working with exactly the same setup. And they may not even know what their setup is
- People will be afraid to make more than minor changes. If the system is fragile, the effort to make a minor change will be high
- Developers will be afraid to start from a clean slate, because doing so adds significant overhead. This is basic human nature: the risk of bad feedback from taking “too long” to accomplish a task is greater than the (eventual) discovery of a problem caused by not following a good process