Consulting firms that take on software projects often use a specific process that starts with gathering initial requirements from the client and moves to a standard design process.
However, a commercial product development effort typically doesn’t have a client to supply requirements. Even worse, new product development usually involves some sort of technological advance or invention that makes a leap over other products on the market. This means that, as you undertake a project, many of the pieces that need to be built may not be fully designed or completely developed. As you can imagine, all of this wreaks havoc on a development schedule.
Bootstrapping is the process of getting a software development project moving from a standing start. But how do you bootstrap a software project under these conditions? The following rules have helped me smooth out the rough spots when bootstrapping a software project.
Start your team with only one developer
You should build your project team around a "core" developer who will help structure the problem. Because I still actively develop software, I’ve often assumed that role myself, but for many organizations the core developer is a senior software architect. Personally, I want my core developer to be someone who still gets his or her “hands dirty.” Whoever fills the role, it should be someone who will understand the problem quickly and get the work started.
Add developers slowly
While it’s common for developers to write code while a product is still in the design phase, management typically believes that the best way to develop software is to throw more people at the project. During the bootstrapping process, this is about the worst thing you can do. There’s nothing worse than having too much help building software when the system isn’t fully conceived. It’s very difficult to align software developers toward a single product vision; it’s impossible to get alignment when the vision isn’t clear.
Get your first help at the fringes
In the early days of a project, it's often hard to break a problem apart because the entire problem isn't defined. On the other hand, it's impossible to do a decent job on a large project with only one person at the helm. So you should have your core developer add other developers at the “fringes” of the project. The fringes are ancillary aspects of the project—those pieces of code that are part of the system or its surrounding tools and that are well defined because of their universality. For example, I typically design software for servers and background agents. A typical fringe module for these types of systems is a logging function, a critical component of the debugging process. Another fringe module is a log analyzer, which opens the log file and collects statistical information. Each of these modules is well defined and you can assign them in the earliest days of the project without adversely affecting the undefined pieces of the system. Because the developers of these fringe modules get in early on the project, they’ll learn what you’re trying to achieve with the product and will be able to contribute more quickly to other components.
Get organized quickly
Small development shops often learn the hard way how valuable a source control tool can be. As you add more developers to the project team, it's important to use some sort of source control system to make sure that developers aren't stepping on each other’s code
Define a build schedule
It's important to set deadlines. Deadlines create discipline and provide good checkpoints on progress. In the early days of a project, it may be hard to pick out good development milestones, so I prefer a regular build-and-test cycle. Typically, my projects use a three-week cycle for development. Every three weeks a baseline is cut to mark the end of a cycle.
Get a QA team involved early
This may seem wacky, but I've seen too many projects fail because QA wasn't involved every step of the way. On my projects, QA picks up the code and tests it at the end of every three-week development cycle. In the early days, QA will probably focus more on test development than defect detection, but that's okay. In the latter days of the project, your code will be thoroughly tested by folks who understand what you've built because they were helping you every step of the way.
Understand QA and build cycles
I'll offer one more bit of advice: never allow a QA team to test a development build. I always insist that, at the end of every development cycle, the QA team collect the source code and do a build themselves. Again, this is a discipline thing. If QA must do its own build, then the development team must define and document the build procedures. This, in turn, eliminates any questions about what was tested, and it improves the quality of the final product.
As the product evolves, you can use the regular methods for building and managing a development project to see the product through to completion. But these bootstrapping concepts will get you through the early, critical, and most difficult stages of product development and give you that chance for success.