I’ve been dealing lately with issues around project estimation and timelines, and I recently realized something. Developers tend to be optimists, and are willing to tackle cool new projects which are very greenfield.
Green field projects are important and can sometimes offer huge payoffs. However, their downside is that they are by their nature unscoped. The goals can be scoped, but the development involved, the learning needed, and the unknowns presented leave the true scope undefined.
These are cool! It is exciting to jump into the great unknown and figure out ways to do things which have never been done before.
However, 99% of what is built today has already been done thousands of times by other developers, and I bet that you have done it already once or twice. The long term sustainability of your company is based on your ability to not get in over your head.
So I propose that you try to find the simplest, most boring way to solve your problem. If it is turning out to be hard, ask whether there is a way to shift requirements such that it is made easy. The vast majority of the time, you can.
For the remaining 1% of projects, keep their scope as small as possible. Since you cannot estimate the depth of the project, keep the breadth limited.
However, feel free to try new tech. But with these rules:
- Only try one new technology in any given project. A new database is a new technology. A new templating language is a new technology. Et cetera.
- Set a fallback plan. If you were not allowed to use any new technology, how would you do it?
- Set a cutoff. If this takes longer than X time, you will fall back to the old tech.
- Set a stretch cutoff. If you think you are really close, you are allowed Y more time to get it there.
- If you hit these cutoffs, do not, under any circumstances, continue down this road on this project. You have to ship and move on to other things. Learn from the test and feel free to try again with the new-found knowledge.