So here we are. We've shipped Beta 1. We've shipped a couple of Customer Technical Previews (sometimes called "Community Drops"). And we've started to refocus on the next goal, which is Beta 2, and the real goal of shipping Whidbey (Visual Studio 2005/.NET Framework 2.0).
At this point it becomes a bit of a numbers game. You've got a bunch of data about your development team's productivity during different parts of the cycle. You've got more data abotu how many bugs you're likely to get from your QA team, from beta-testers, and from other teams. You've got a bunch of people taking vacations over the summer, and you've got a million other little things you've got to do along the way such as servicing, security reviews, performance tuning, annual reviews, writing blogs, etc. You take all of that data, sprinkle in some creative accounting (I said creative, not Enron), and start to get a look at where you are at.
Invariably at this point in the process you end up in the same place: you've got more work than you have time or resources. Let me be clear: our releases are driving by quality, but you have to remember there are a ton of different product units within the over all product that is Whidbey plus deliverables to other teams that are depending on you to ship so they can ship. And we all have to ship together so you can't have teams working indefinitely. Oh, yeah, then there are things like competitors in the market place and customers beating down the door saying "give it to me NOW!!!". So you need to draw a line in the sand and shoot for a date.
One quick note about software dates here. Setting dates in software is somewhere between a black art and pin-the-tail-on-the-donkey but much of it is psychology. See, one thing that you learn in this business is that work is like gas -- it will expand to fill any space you give it. If you give someone 6 months to do something, they'll take 6 months and probably throw in a bunch of other stuff too and make matters worse in the end. So you need to set dates and try like hell to hit them or you'll never get anywhere. And the dirty little secret is sometimes the folks setting the dates know damn well they're not realistic but need to drive progress in smaller chunks. See earlier in this paragraph. But if you don't walk, talk, and act like they're real dates, no one will believe them and they won't do you any good. And, yes, I'm very concerned with how we make Software Development really Software Engineering and build predictability and quality into the entire process end to end but that's a different topic altogether. Anyway, moving on.
You can control schedules by one of three mechanisms: add resources, cut scope, or sacrifice quality. Getting extra resources is basically impossible, especially in the short term. Sacrificing quality is obviously not the right thing to do. And even if you tried you'll pay for it later in satisfaction if not servicing. So what does that leave you with? Cutting features.
This is why it's the hard part. Many of these features aren't in that bad of shape. All of them have a set of people and customers that love them and will fight tooth and nail to keep them in the product. Some have a small set of issues that we don't have answers for how to fix. But the great-equalizer you ask is: "do we absolutely need this feature to ship the product?" And if that doesn't work then you say "okay, which other features would you like to nominate as less important?" This tends to go round-and-round for weeks. And eventually you have your cut list, and you keep doing it until you come up with a savings (for both dev and QA) that will actually help you get to shipping.
But it hurts. Cool features are one of our prime motivators for doing software. There's always next version...
For Windows Forms 2.0 the current major feature cut list is: ActiveDocumentHost, In-place (sometimes called 'InSitu') designer editing, and simplified printing.
A moment of silence, please.