Sometimes, to get the job done, you have to say “no.”
That’s exactly what Microsoft developers did with regard to the schedule for Longhorn, the next generation of the Windows operating system. The product’s feature set was recently cut back in order to bring it to market on time. This is good news for PC vendors, who were afraid that PC sales would lag badly as people waited for the next version of the OS, but it is even better news for software developers everywhere, because it sets a very good precedent.
All too often, non-technical managers will demand that a development team deliver feature set X on date Y, with no regard for whether or not such an accomplishment is feasible (this kind of boondoggle usually happens when a company falls into Pitfall #1 – a salesman or executive, eager to make a sale, told a client that they can have feature set X on Y date without consulting anyone from development first…but I digress). And the unfortunate part is that most software developers, being somewhat beta, will put their heads down and work endless hours of overtime until the feature set is implemented, albeit poorly. And to make it even crazier, most managers are so pleased that they met the date that they don’t really care about the poor quality of the software. I recall that at one job I had a number of years ago, the manager told me “just get it minimally working by the delivery date – that way, anything that doesn’t work can be paid for under User Acceptance Testing – but if it’s not delivered by that date, we have to eat those fixes rather than bill for them.” This is sounds nuts, but it is not at all unusual in the software industry.
Thankfully, we have a big fat precedent being set by Redmond right now. The Longhorn team vetoed the feature set for the release date. No manager will browbeat them into promising to deliver a bloated feature set by 2006. Nobody will threaten their jobs. Nobody will demand that they work crazy amounts of overtime to get it done. The professional software engineers have spoken, and their employer listened. Bill Gates said:
The Wins team, in terms of its progress and performance, is doing very, very good work, but it couldn’t take the additional features and make an ’06 schedule. That’s professional engineering on its part, to stand up and say, “No, if you want us to have those features, we’re an ’07 deliverable.”
Now that, my friends, is encouraging. Here we have the most prominent manager of software developers in the world telling his team “you know what? You guys are professionals – you know what you’re doing. If you say there are more features than you can deliver by ’06, fine – we’ll cut features to make the ’06 ship date.” This is going to make it tough for managers to tell their teams “no, you have to implement ALL these features by X date – and if you can’t do it, I’ll get someone else who can.”
Thankfully, I don’t have this kind of problem with my clients – when they ask for certain functionality by a certain date, I come back with what I can do by that date. More often than not, they trust me. We work together to figure out how much of what they need can be delivered by that date. Nobody threatens me. Nobody calls my abilities into question. Nobody tries to bully me (actually, a few have tried, but they cease to be clients right then and there). Perhaps this trust is extended to me only because being a consultant carries more cachet than being “just” an employee, but I’d prefer to think it’s because I have a good track record. Unfortunately, my good fortune is the exact opposite of what I see happening in the trenches of software development, where developers are browbeat into working to unrealistic deadlines all the time. Before I was in business for myself, I saw it – and lived it – all the time. For example, I was once given three weeks to cobble together an entire product from half-working modules and libraries! The reason? Some salesman sold a product that didn’t exist, and promised delivery by months end, all without consulting a single technical staffer to see if it was feasible. The project was a wreck and the client eventually fired us – but hey, at least we made our first ship date!
So if Bill himself says that this is the way to handle a conflict between a delivery date and a feature set, what possible excuse can any manager have for refusing to cut features or slip the date when a similar conflict arises on one of his projects? None that I can see.
Managers – trust your developers. You hired them because you believe they can get the job done (and if you don’t believe that, then you need to take a serious look at your company’s hiring practices). These people are professionals who know what it takes to build good software. When they tell you that a thing can or cannot be done on a certain schedule, don’t ignore them. A good software project must be coaxed, never forced; to do otherwise is to ensure low quality and an abundance of re-work.