What makes development projects so difficult to estimate accurately? This is understandably a huge concern for clients. As much as we’d love to give instant, reliable estimates, it would be dishonest to our clients and to us. The very nature of development makes it difficult to predict with complete certainty. I’ve been in the field for over 16 years, and the only projects that were ever totally on the nose were less than 2 weeks long. Let’s talk about why.
Creating a new application is like exploring unknown territory. Your previous experience and practical skills exist to help you deal with the unexpected, not plot every step of your journey. Imagine asking an explorer how much time and how many resources it would take to get to a new place. They might have a quick “gut” projection, but they couldn’t say for certain. Even if you gave the explorer time to prepare, practice, or consult with other explorers on their experience traveling to places nearby, there are an infinite number of things that could happen to throw off the original estimate.
Developers are problem solvers. Their experience and education help them tackle the new and unforeseen. What we build for our clients doesn’t exist yet, otherwise they would use an existing product, so every project is uncharted territory to some degree. Studying similar applications, approaches, and code can only get you so far.
At East Coast Product we’ve decided to embrace the chaos of estimation. We break projects up into small, iterative chunks and loosely follow agile methodologies. This allows us to more confidently estimate the smaller chunks while staying lean and giving us flexibility to course correct and account for the unexpected as we work. That means we can focus on the product features and assumptions that have been confirmed, and keeps the future open to continuing to build the product in the right direction.
If you’re interested in learning more about the problem of development estimates, check out The Mythical Man-Month by Frederick P. Brooks. Many of the challenges he describes in the process of software development still ring true now, over 20 years after the book was originally published.