Past-due software projects, can something be done about them? (Part II)
In the first part of this post I described the three most common "different type of scheduling games software engineers play":
- Game 1. Everything’s on schedule, but suddenly we need to do some additional work (add a new feature, own an additional area of responsibility, comply with some additional coding standards etc.)
- Game 2. Everything’s good in our team, but because of some dependencies or unforeseen events the project will take longer than expected.
- Game 3. We tried to do our best while estimating, but made a number of mistakes and now it’s going to take longer than we initially thought.
Here are the ways I try to deal with these different situations. Don’t treat it as some kind of universal strategic guidance. One of my university professors used to say that the term "universal" means that it works equally bad in all different situations ;-)
Game 1
IMHO this is the best situation you can be in. Your team is on track, everything looks fine, and with the pretty high probability you’ll meet the dates you promised to meet. From the negotiations point of view you’re in very good strategic position and you’re doing better than average peer of yours. Usually there are few possible outcomes:
- Your superiors have a common sense and they understand that for example taking time to review the entire code base and look for new type of security vulnerabilities (integer overflows for example) will take some time and doing the review on Saturday at 03:00 AM won’t probably be the most efficient/productive use of everyone’s time.
- Your superiors have a common sense, but something just needs to be done by specific date. For example: your product launch date is announced; major customers won’t want your product without specific new feature; person who owned MMC plug-in left the company and somebody needs take care of his/her bugs by some certain date etc. This shouldn’t be confused with the "it needs to be done because slipping will look bad in my record and I’m willing to sacrifice the well-being of the entire team to meet some date" situation.
On the other side being on track can also be a bad thing. Nowadays (if not always) the software projects meeting deadlines and staying on track are rather suspicious than normal. Let’s look at the hypothetical story about two teams:
There are two development teams: A and B. Both are working in parallel on some COM-based software. Developers in team A decide that smart pointers are good thing and they’ll be using them consistently across the project (for the sake of the example let’s not start arguing about smart pointers ;-)) Developers in team B decide that Real Programmers know exactly when to call IUnknown::AddRef and IUnknown::Release and smart pointers are for losers who don’t know how COM works and what they’re doing. Two months after starting the project both teams are feature complete, but when it comes to the bugs then team A has a way less bugs than team B. Team B is constantly struggling with reference counting issues. As a result of this team B spends next two weeks working on nights and weekends, team leads order food for the team every day at 06:00 PM, e-mails about successfully fixing something are sent out at 02:47 AM etc. What kind of perception is generated to the outsider about team B? Mostly the good kind of perception. Team B is committed to shipping the product, they put in heroic efforts, they do whatever it takes to meet the deadlines, and they’re “old school“, yeah. As my manager once told me after I was too cynical during one meeting and later wondered why people complained about this: "perception is a reality" ;-) If you’re insider then you may know that team A has succeeded because they made IMHO better engineering decision and while team B has been fixing bugs, they’ve been doing something else which helps to generate the revenue for the company.
Game 2
Dependencies are generally a very bad thing. Joel on Software contains a nice general article about this. In our product we have been battling with dependencies for years now. The most complicated dependencies based on my personal experience are:
- You are relying on 3-rd party component. That’s it, the code is out of your control, the design is out of your control, and you don’t know what’s going on inside the component. Getting something fixed isn’t just: "run cdb; look at the source code; figure out the problem; fix it;" Dependencies bad, external dependencies very bad. Probably everyone who ever has used any components for doing either SSL/TLS related stuff, generating database reports, having a fancy calendar control etc. knows what I mean.
- General libraries, base classes, frameworks etc. Everyone is using ATL, CLR, CRT, .NET Framework etc. But what happens if something in these libraries is blocking shipping your product and there’s no feasible workaround? The good thing about being at Microsoft is that pretty much everything we use is built by some other team ;-) You have a problem with CLR - the answer is just an e-mail away.
- Bugs in OS. Nothing is ever perfect. The same thing as under previous bullet-point applies here. With dependencies and problems like this there’s not much you can do. Yes, the feature can be cut and some hectic workaround can be implemented, but it still will take a time and increase the risk of breaking something else.
In my pre-Microsoft life somebody once suggested replacing one 3-rd party component with another because the project dates were quite critical. The suggestion was made about two days before the final date ;-) Everyone with common sense will understand that why a month before shipping you can’t start replacing the building blocks of your product.
Game 3
This is a situation where the only thing to do is to say "guilty as charged". I tend to divide this particular situation into two different categories:
- You have somebody junior reporting to you who made an estimation mistake. Usually all the estimates are rigorously reviewed and reviewed once again and then reviewed again. IMHO in case of junior people it’s 50% the manager’s fault also - insufficient tutoring, reviewing, not assigning a proper mentor etc.
- You have somebody senior who makes constantly estimation mistakes. Well, in this case you have a problem in your hands.
One can ask that why I’m spending so much time talking about this? Mainly because of the similarities to chaos theory. Everyone has heard the term "butterfly effect". Let me give you an hypothetical example: "Let's assume that I ask somebody how much the task A will take; person replies that task A will be done by Monday morning; I ask for the confirmation, person confirms once more; I go and tell to my manager that we’ll complete something by Monday morning; my manager passes the good news to somebody in upper management who has conference call with external partners in three hours from now; news are passed to partners that they’ll get some results by Monday morning; task A takes longer than expected because of the incorrect estimates and we actually complete it by Tuesday EOD; on Thursday two vice presidents (ours and partners) talk and one happens to mention the fact that they can’t deliver B on time because A was late and therefore B will be late." You can imagine the rest ;-)