Preventing big projects from becoming big headaches

Josh Tyler
Management, The Art and The Science
2 min readOct 7, 2014

Has this happened to you?

Your team starts out on an interesting project. You know it’s a pretty big one, but not that big. You should be able to get it done a few weeks or so, and it’s going to be awesome.

Things go smoothly at first. You’ve got high-level goals, scope estimates, and everyone pretty much knows what they need to be doing.

Fast-forward to your target ship date. Lots of new features have been added, mostly in the last week, bugs are piling up much faster than the team can handle them, and now the question isn’t whether or not you’re going to ship late, but rather by how much.

How did this happen?

That’s actually an easy question to answer: Life is complicated. Things happen. They always do.

A better, and more difficult, question is: How can you prevent this from happening next time?

  1. Break things down. Not just conceptually, but operationally. Make sure that all project tasks have been decomposed into sub-tasks that are no bigger than a day or two.
  2. Ship constantly. Even if you’re checking off sub-tasks as you go, you’re still setting yourself up for a big headache at the end, unless you actually complete the release to production for each task. 100 tasks, each completed successfully but not deployed, add up to a huge, monolithic changeset, a mega-merge, and a very daunting code review. Ship all these pieces as you go. If you do, you’ll never be more than a day or two’s worth of work from production, which is valuable if you unexpectedly need to accelerate your schedule or make other changes.
  3. Use feature toggles. Toggles, also known as gatekeepers, allow you to ship your code before the whole project is ready. In order to pull off #2 (ship constantly), you may need a tool to selectively activate new code as it hits production. Shipping portions of your code at a time usually means you don’t want that code used until the rest is ready. There are plenty of options out there. For example, I’ve used Waffle for Django projects.
  4. Keep everyone working on only this project. Over time, it becomes more likely that other projects, issues, and demands on peoples’ time will creep in. Try to make sure this is the only thing people are working on, until it’s done.

Finally, these things take vigilance. It’s easy to lapse back into what’s comfortable, easy, or convenient. Watch closely to see if things are breaking down, and if so, why.

Or to put it another way: Ship early and often.

--

--

Josh Tyler
Management, The Art and The Science

EVP Engineering and Design @CourseHero, changing the way people learn. Author, Building Great Software Engineering Teams. Views expressed here are my own.