Deadlines

“You can ship all your features, or you can ship on time, but you can’t do both”

    – God

A Story

Pachyderm Projects (I’ll call them “namespaces” for blog purposes): “all the functions in PPS identify repos with a string: the repo name. Well, with projects, we need two strings: the repo and the project. This is a major refactoring, affecting all of our functions and classes, as well as our database schema.

• This is not an issue that, practically, you will ever uncover during planning. Nobody has all of your code’s internal function signatures memorized, so there’s no way for the issue to be raised in a planning meeting. You have to be well into the implementation phase of a project before it will come up
• Why is this so hard? Because there are so innumerably many decisions that have gone into your project, that you can’t know them all or predict how they’ll interact due to bounded recall and bounded rationality
• Software planning is chaotic. Arbitrarily small amounts of additional planning time may have arbitrarily large effects on the expected completion date.
  • This means that there’s always a risk your software project, as written, will not just slip, but completely explode on you, and there’s nothing you can do about it.
  • The solution is to be flexible about your plan

How I do it:

• Make a plan to get the feature built in X time. Tell stakeholders that it will be done in 2*X time.
• The 2x factor is not there to improve your odds of finishing on time. Again, there’s nothing you can do to ensure that. It’s simply there to give you time to think, as I’ll explain
• I don’t have much advice on the “make a plan” part (no “break it down to tasks that are less than a week” or anything like that. Finger-in-the air is fine, but be very mindful of uncertainty)

Then, here’s how a project (should) go:

• Say you have a project with a three-month plan, and then a month in, you realize something is very wrong and the project will actually take a year
• Now you are eating into your buffer time. What you do is: get everyone together, and you change your plan.
  • This is an active process! That’s why the 2x buffer wasn’t just sandbagging. You’re using the extra time for planning.
  • You can cut features, change the order you do things in, incur technical debt, whatever. AT the end, you want a plan that leaves you bunch more buffer
• Eventually, you cut enough stuff and add enough shortcuts that it’s back to being a three-month plan. You’re a month in, so you’ll finish at 4 months, still ahead of what you told stakeholders
• Say all this happens again. You cut or change more stuff, make a third three-month plan
• This one actually works, and now you’re “done” (modulo the stuff you cut) at five months
• You’re now in a great position because not only do you still have a month of time, but you also understand the problem and its risks much better. The list of stuff you cut is mostly exhaustive; it might still blow up on you, but your odds are lot better than they were at the beginning.
• Use your remaining buffer to implement the most valuable stuff on the list. Whatever doesn’t get done gets cut, but that’s fine.

I had one TL who would do one round of re-planning preemptively, with the following trick: when starting a project, he’d ask you to write out a plan and estimate. Then, you’d give him a number T. He’d always ask, regardless of T: “okay, what would it take to get this done in T/2. You’d cut a bunch of stuff, and that would be your project plan.

Lesson

• You must actively manage a project during construction to hit a deadline.
• There’s nothing you can do upfront—planning, sandbagging, whatever—to accomplish this. It’s all about what you do while the clock is ticking and the ball is in play.
• AFAICT, mid-project re-planning is basically the whole central idea of Agile.