Software Engineering- Picking a Real World Release Dates

The FuzzyBlog! : Software Engineering: Picking a Real World Release Dates The FuzzyBlog!

Marketing 101. Consulting 101. PHP Consulting. Random geeky stuff. I Blog Therefore I Am.

Software Engineering: Picking a Real World Release Dates

My Inbox Buddy partner and lead developer (Brian Giedt) and I recently had to choose the release date for the Inbox Buddy 1.0 version. We feel really good about this version. It's had a longer gestation period and more testing than I think anything we've ever done. And I honestly mean this. He and I have been running Inbox Buddy daily since at least March and perhaps longer. And we've been in public beta for more than a month now. And, ouf course, our current beta version is about to expire and stop working. So here were our options:

Release the 1.0 today. This would mean rushing the final QA and rechecking most things from 5:00 pm yesterday through this morning.
Release in 2 weeks. It doesn't make sense to release a beta for just 1 week when the beta has a timed expiration date built in so we first discussed 2 weeks.

And you know what we chose? Release in 3 weeks. Here's the question I asked Brian that determined the answer:

When does Giedt version 3 arrive?

That's right. Brian has a new baby on the way. I view Brian as "Giedt version 1" and his lovely daughter Megan as "Giedt version 2" so the new baby can only be "Giedt version 3". According to Brian the baby is due in approximately 10 days. That's not work days of course but calendar days. Now this is the first baby for his wife Jackie so you have to figure that it will be late by at least a few days. This means that if we chose 2 weeks then Brian would be dealing with the inevitable release issues (something always crops up) when the new baby has just arrived. And 1 week is too damn close in case the baby is early / on time. And that's not good. Hence 3 weeks. And this lengthy series of events brings us to today's lesson.

Software Engineering in the Real World

I've worked in big software companies, teeny tiny small software companies and worked with software companies all over the globe. And one thing remains constant: we all screw up release dates with the regularity of snow at the North Pole. I have to think that a big part of it is that managers fail to take into account one simple thing:

I'm a person first. A worker second.

Now don't get me wrong, I'm not saying anyone's not dedicated or a hard worker. All I'm saying is that the real world correctly takes precedence. If you have any kind of development schedule longer than 1 month or with more than 1 developer, you're going to hit one or more of these:

Someone moves
Someone gets sick
Someone has a baby
Someone gets married
There is a major holiday
Someone has an anniversary / birthday
Someone's significant other breaks up with them
Someone has to go to a wedding that is a long way away

People get sick, developers have babies, sh*t happens. Whenever I plan a release schedule, I look at what I call the "Don't Shoot these 4 Guys" syndrome. For any software release, no matter what the team size, it always seems to come down to between 1 and 4 key people. And they aren't all developers. Examples:

It could be the lead developer who's just plain brilliant and knows ever nook and cranny of the code
It could be the QA guy who's like the energizer bunny – he keeps testing and testing and testing
It could be a product manager who's always around is just the heart and soul of the release
It could be a junior developer who's trying really hard and just keeps at it

The point is that any release is dependent not on any developer and not on every developer but on the key developers – the people that you cannot shoot. If any of these people have the issues from above the release date will slip if you don't take them into account. It really is just that simple. We'd love to think that our engineering isn't affected by these kinds of things but that's just unrealistic. So here's I handle it when the proposed release date nears:

Figure out who the key people are if I don't already know.
Sidebar : If you don't know this already then you have another problem. Do not pass Go, Do not collect $200 and hand in your managers license.
Juxtapose the proposed release date against a calendar looking for holidays anywhere within 1 month of the proposed date. Since slipping is so damn common you have to always look into the future.
Take each of the key people out for coffee or lunch gently probing their personal life along the dimensions above.
Add any dates gleaned from step 3 to the calendar. Looking at the calendar events gives you a set of possible release dates.
Make sure that the possible dates are viable with respect to the amount of engineering work going on. If you have to still implement a major feature and your only install date is a week away before a full month of dates that don't look good, that's bad.
Hold a release meeting with all development staff, QA folk and related parties going over the calendar subject to any privacy issues from #3.
Try and pick a release date that isn't too severely impacted by #3, #4 and #5.

In step 7 I try and pick a release date that isn't killed by the events in people's lives. Now you have to bear in mind that this is subject to management issues, customer promises and the like. Many times you'll have to plan a release date that is exactly when your lead developer has a baby. In that case you need to capture as much knowledge as possible, make sure you know how to do the build (AND HAVE TESTED IT), give them a laptop, a cell phone and a pager and hope for the best. It's obviously not perfect but sometimes it's the best you can do.

Realistic Shipping Dates. People are people first and workers second. What concepts !

This Page was last update: 4/6/2003; 3:13:56 AM

Theme Design by Bryan Bell