Pilot projects

Sunday, October 03, 2004 01:52 PM

An old friend of mine called me a few days ago, and asked me an interesting question. We worked for the same company a few years ago (he's still there), and I've designed the architecture for their system. He asked me what technologies I'd use if I had to design the system today, and while this might be an interesting technical issue, it's not what interests me the most about this question.

When we first started the project, we had a lot of architectural issues to resolve. I've decided to use a certain set of methodologies, technologies, and development tools - many of which we haven't used before on a production system. In essence, I've decided to make our project a pilot project.

That remarkable book, Peopleware, defines a pilot project as "one in which you set the fat book of standards aside and try some new and unproven technique." The book discusses some of the pros and cons of pilot projects, but focuses mainly on their effects on development teams. In recent years, I have been working mostly as an independent consultant, and while not all the concepts illustrated in the Peopleware discussion of pilot projects apply to one-person shops, I have found pilots to be extremely beneficial even to a single developer.

For all you salaried programmers out there, looking at freelance consultants swoop in, make a lot of money and vanish out of sight, let me tell you - it's not as glamorous as it sounds. Not even close. While I do have more freedom in my work, most of my time is spent on things that are of little or no interest to me at all. Looking for work, marketing my skills, negotiating - everything a business need to do before getting to the actual work - take a lot of time and effort. Worse still, even when I get to the technical stuff, most of it is just plain boring. The way I deal with it is by making almost every new project a pilot.

When I get a new project, I choose one or two aspects of the project I'd like to experiment with, and go with it. It could be a methodology, such as extreme programming or test-driven development; it could be a new technology, such as ASP.NET; or it could be a new tool or programming language. Trying out new techniques helps me in several levels:

• A pilot project is a great way of learning new techniques. I have very little time to play around with new technologies, and integrating the learning process with work saves a lot of time.
• I like to learn new things: if the project isn't interesting in itself, the learning process makes it interesting.
• I keep myself competitive by familiarizing myself with new techniques.
• I'm more productive in my work when I can make it interesting.
• Self-employment requires a lot of self-discipline. Making work more interesting relieves some of that burden.

When embarking on a pilot project, however, it's important to avoid experimenting with more than one or two aspects of the process. more than that is a huge risk, and while it may be fun, it would be difficult to actually finish the project at all, let alone on time or on budget. This isn't to say you should take risks - on the contrary, the whole concept of the pilot project is based on taking risks.

There are many risks in running pilot projects. The main risk, of course, is that the new technique you're trying will fail, taking down the entire project with it. It is for this reason that you should limit the scope of the experiment. Another risk is the fact that you'll almost always be less efficient applying a new technique than with something you already know. This can affect the project's schedule and budget, and you'll have to take that into account when pricing or estimating schedules.

The affect on time and budget causes another risk, since it reduces your competitiveness. If you just need the work, a pilot project may not be the right way to go. Putting food on the table outweighs any less tangible benefits you may gain from running a pilot. A similar risk is the elusive "opportunity cost" - what you might have been doing if you haven't spent that extra time on experiments.

In the long run, however, I strongly believe pilot projects are extremely beneficial, and sometimes even crucial. Like many other aspects of the development process - such as source control, configuration management, and requirements management - they can help single developers as well as teams. Not every pilot is a success, but I always learn something. And it makes work fun.