Deadline Defense

There’s always a deadline.

Every product or project has a deadline, the date after which, if you’ve not delivered the thing, you’re dead.¹ Let’s do a little math.

So. We have a deadline. If the software isn’t working on that day, we’re in trouble. Someone will be disappointed. The consequences may be dire, they may be almost invisible. But, we will have “failed”. That would be bad.

We have to be done on the day.

Therefore, the software has to be working on that day. Integrated, tested, running, documented, ready to be put into the hands of users. It has to work. It has to be free of defects—at least free of significant defects.

We can consider each aspect of “done” independently and yet separately. Does it have to be documented? Then it has to be documented on the last day. Does it have to be integrated (you know it)? Then it has to be integrated on the last day. And so on.

Every aspect of done, working, ready—every aspect has to be done on that day.

What about the day before?

What about the day before the deadline? If it all has to be integrated, tested, running, documented, and so on by tomorrow, how integrated, testing, running and documented had it better be by the day before? Frankly, unless we want to work all night, it had better be 99.999% done. Maybe there’s a period somewhere in the document that should be a semicolon or something, but let’s face it, if there’s anything wrong on the day before, we haven’t much chance of finding it and fixing it to be ready on the day.

So if the deadline is Day 100, we really need to be ready on Day 99. We just can’t do much between Day 99 and Day 100, and it might snow or something so we wouldn’t even be able to work at all.

There seems to be a pattern in his thinking here.

You see where this is going. We can’t do much between Day 98 and 99, so we’d better be ready on Day 98. Oh, sure we might do some tiny change in two days, but realistically we can’t do much.

Is this fool going to say we have to be ready to ship on Day 1?

We can’t possibly be ready to ship on Day 1, can we?

Well, on Day 1 we have no code, so our code is fully tested and fully integrated. We could cut a blank CD and hand it to someone, and that CD could even contain all the necessary documentation for our software that doesn’t do anything.

So other than maybe not having a CD to hand, we’re ready to ship on Day 1.

OK, that’s just one of your Jedi mind tricks. What about Day 2?

This is going quite well so far! But what about Day 2? Can we be ready to ship on day 2? Sure, why not? Can’t we write a tiny little feature that’s part of our big picture, test it, integrate it, and document it? If not, maybe it’s not tiny enough. Otherwise, a few lines of code, a few lines of test, a few lines of build, a few lines of documentation … and ship it!

Oh come on, we can’t do all that has to be done in just one day!

Probably it seems like Day 2 is the problem. We were good on Day 1, with nothing implemented and therefore completely up to date on testing, integration, and documentation. But Day 2? We might not quite be able to coordinate deciding what to do, doing it, testing it, building it, and writing it up all in a single day.

But what if we could?

Mind you, I believe that it’s probably always possible to release a new integrated tested product every day, but I freely grant that it’s not just easy and especially not on Day 2. But let’s put our concerns about Day 2 aside for a moment and think about what would happen if we could do this every day:

• Plan a tiny feature or two;
• Design it;
• Build it;
• Test it;
• Integrate it;
• Document it.

If we could—and maybe it’s a big if—then we could hit any deadline with our product ready to go. And if we were to work on important things first and less important things later, we would hit the deadline with the best possible result given the time and money we had.

The best possible result? That’s not bad at all!

Really! Think about it! If we would just release a system that’s a little bit better, and always complete, every day, we could hit the deadline with the best possible outcome! Really!

But what if we can’t?

There’s only one way this simple plan can fail: if we don’t do it. There are only a couple of ways we could not do it. We could not try, or we could be unable to do it. Now that we see what a clever plan this is, surely we’ll try. So what could make us unable to do it?

Well, a myriad of things can make us unable to provide a running tested system on Day 2, or any subsequent day. Note, however, that if we ever once do get a running tested system, we’ll never be without one again: if the one we try to build tomorrow doesn’t work, we still have today’s. It won’t show a lot of progress over today, but we’ll have it. We’ll still be able to ship the best possible version.

All the hard parts left to the reader …

I’m not going to try to list and fix all the things that might hold us back in this little article, but because I’ve seen it done so many times, I’m quite sure that we can always get a small fully tested, integrated, documented release early on for any product that starts from scratch. (Legacy code can be more difficult, but if you can build it … you’re on your way!)

Anyway we can debate the issues elsewhere. My point here is a simple one. Maybe you can’t do it on Day 2. I think you can do it by Day 5 or Day 10. Maybe in rare cases, it’ll take until Day 15 or even 20.

“Just do it.”
– some Greek goddess
– or maybe a little green guy

My point here is do it. Pay attention to nothing else in the first stages of your effort but to building a complete, integrated, tested, documented tiny version. The more tiny the better, because it’s easier when it’s tiny. Don’t shoot for a version with ten features. Do a version with one feature. Then do another and another and another. Pay attention to what’s in the way and improve it. Pay attention to what the product needs next and focus on it. Repeat until deadline.

To me, this idea is the essence of Agile Software Development. Oh, yes, I support the Heart of Agile’s Collaborate, Deliver, Reflect, Improve², and I’m all for Modern Agile’s Make People Awesome, Deliver Value Continuously, Make Safety a Prerequisite, Experiment and Learn Rapidly³. Those are great ideas from great people.

Me, I’m not a great person, I’m a bear of very simple brain. Those ideas of my betters are critical to success with “Agile”, in my opinion.

However, if you aren’t showing real running software all the time, your communications with management are weakened, your communications with your users are weakened, your feedback from the world, from the computer, from the code is weakened … and you cannot prosper.

For me, running tested software is central. All those other ideas support it, but the software’s what we’ve got to do. So find a way to do it and if you find yourself losing heart, ask me or my betters.

Good luck!