Breaking all rules of software release management

The project I’m currently working on is getting really close to being done, with Windows Vista having been “RTM”ed recently. We have a few more days to get last minute bugs ironed out and then it’s “off to the factories”… I can’t say much more about the project right now, but it’s a pretty significant and highly visible piece of software coming out somehwere around February 2007. I hope it does well. But I digress…

At this late a stage in a product’s delivery cycle it is common to make very few changes to the code in order not to create more bugs than one fixes. Ideally each change should be peer-reviewed and thouroughly tested before getting checked in (like with Windows Vista and the contortions people have to go through in the “shiproom” to get a bugfix approved). Too bad for me that I’m the only “peer” on the project (i.e. I’m the only developer). There’s nobody I can go to for a review.

And in the last few weeks I’ve broken the “as few changes as possible” rule a number of times. Why? Because I’m confident in the features that WPF provides. And because I do tend to run extensive tests before I check stuff in.

So what kinds of changes have I put in at the “last minute”? I’ve shuffled buttons around on the page, I’ve added code for drawing the user’s eyes to input fields containing invalid data, I’ve added data-bound and data-driven UI elements.

WPF has given me the confidence to be able to do this at the last minute. The fact that moving buttons around is a simple XAML markup change, for example, is just great for last minute UI adjustments.

But I’m not exactly proud of doing it. Oh well. So far everything seems to have worked out.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.