I’ve worked on six greenfield projects as a programmer1. Do you know how many of those projects succeeded? Three.
That’s my shipping percentage for greenfield projects: 50%. When I think about the projects that failed, they had one or more of the following themes:
Not shipping early enough: It’s really easy to add fluff to a project. For one project we made a wrapper for the E*Trade API along with the architecture to securely handle OAuth tokens. It was quite an elaborate architecture for something that ultimately didn’t ship.
How to address it: Ship the most minimalistic thing you can. Lean startup talks about this as a Minimum Viable Product. Even more basic than this is to start with an experiment.
What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.
If we had set up a button and a landing page for the product (Without actually building the product), we would have known how many people actually wanted it. It would have taken us about a week to have our idea validated. Instead, we squandered four months building something that we ended up not shipping.
Biting off more than we could chew: Years ago, Joel Spolsky wrote about Things you should never do, Part I (there never was a Part II). In it, he talked about the action that singlehandedly torpedoed Netscape:
Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.
It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they?
Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch.
It’s one of those blog posts that you read, laugh at, and say, “We’re not that stupid. We won’t make that mistake.” and then you proceed to make that mistake. We did. The project was essentially a rewrite of the application that made all of the money. It was an attempt to unify different parts of the application and to be able to cross-sell and up-sell other products.
It was shut down one week before its beta launch; 5 months after the project began development work.
One of the major issues from a rewrite is getting executive level buy-in (and keeping it). A rewrite is a way of making programmers feel better about crappy code. Just rewrite it! The problem is that if you’re rewriting something, you’re not (by definition) making it better for the people who pay for it. At most you’re making it better for future features, and at worst you’re just making different mistakes.
Technical debt is real, and it has a disastrous effect on programmers’ psyche; but a rewrite isn’t a sustainable way of addressing technical debt.
How to address it: Ask the people who pay the bills frequently about their expectations, but frame it in such a way that they can’t weasel out of an answer. If you ask a business executive, “How long do we have?” They’ll say, “as long as it takes to finish.” They don’t really mean that. It’s not their fault — they have great intentions, but they don’t really mean that. They really mean, “As soon as conceivably possible.” One way to see what the threshold is is to ask, “If it takes us three months, how would that sound to you?” Watch their body language for the answer. If that number seems high to them, they’ll flinch, or stumble, or otherwise show that they think three months is too long. You may also get a response to that effect. If they seem fine with that, extend the length until you get past their comfort level. This also works really well on individual features.
Team dynamics: It’s weird how certain combinations of people just don’t work well together. Bob and Steve work well together. Steve and Emily work well together, and Bob and Emily work well together. Put them all in a group, and suddenly you have a dysfunctional team on your hands. In a company where developers often move to different projects, every so often those combinations crop up. It’s not a reflection on anyone in particular, but it’s bad when it happens. Sometimes a team just doesn’t gel, and from personal experience that can doom a project.
How to address it: Talk about it early, as soon as it becomes apparent. Team retrospectives (with beer) are a great way to loosen lips and to hear what people think. Don’t schedule it as a retrospective, schedule it as a time for the team to ‘talk about how we think we’re doing’. The first ten minutes will be positive, the next twenty will be a little deeper; but by the 35 minute mark you should start to hear how people really feel.
Any project I’ve worked on that has succeeded has either had these problems and worked through them quickly, or not had them at all. These are not insurmountable issues, but unchecked, they will torpedo projects.
“Watson, when I say you are instructive, I mean I learn from your mistakes.” — Sherlock Holmes to Dr. Watson
[1]: I’ve worked on a lot of different projects, but only 6 greenfield projects. Every other project had already shipped, and we were either developing new features, or we were just maintaining the project. I feel lucky in that I was able to work on 6 greenfield projects in a three year span.