Preparing for the Next Product Cycle (Matt Gertz)
I once had to learn how to juggle in a very brief time in order to get an “A” in my high school computer science class. I am not making this up. The idea was that juggling, being a systemic process, was somehow analogous to writing programs and… well, it sort of made sense at the time.
I’d done well that semester (my final semester) and was looking forward to getting a good grade in the class. The instructor (probably the best teacher I’d ever had) gave me a preview of my grade, and it wasn’t what I’d expected. Hmm. Without getting into details, the bottom line was that I had very compelling reason to be concerned about my grade being less than an A, and so I asked him if we could dig into what had happened. After we looked back through his gradebook, we realized that I hadn’t finished an assignment from earlier that semester – the juggling. Casting back through my mind, I realized that I’d been absent the day of the juggling, having been invited to attend a physics seminar hosted at a different high school, and I had totally forgotten about it afterwards. Could I make up the assignment? Sure – but the last day of school was the next day.
For full credit, I’d have to be able to do three full cycles using three juggling balls without dropping any of them. I, unfortunately, would have been lucky to toss just one juggling ball up and down without dropping it. All would have been lost but for a dilapidated electronic organ we’d acquired from my grandparents when they’d moved. It was one of these monstrous old things that was bigger than a grand piano and was tricked out with foot pedals, two rows of keys, a special “chord mode,” and, best of all, a couple dozen buttons which, when pressed, would execute a drum rhythm that you could play along with. The circuitry for the keys was in poor shape, but the rhythm buttons worked just fine. I switched it to “waltz,” set the speed to “slow,” and essentially used it as a metronome to practice juggling for the next four hours, gradually increasing the speed. Long story short, that systematic process worked, I got the grade, and to this day I can’t get that waltz beat out of my head.
So, what has this got to do with Visual Basic?
Well, at the moment, we’re doing a lot of juggling ourselves, with a lot of balls in the air. The end and beginning of a product cycle always seem to me to be the busiest times – by comparison, the actual coding milestones always seem to me to be a breeze. Here’s a list of things that are going on right now:
· Shipping VS2008. Yup, that’s not a typo. We still have a number of localized versions of the VS2008 product which are still on the release train. Each of these versions of Visual Studio deserve the same care and handling as the English version, and so a decent amount of our time goes towards making that happen. We’ve got a great internationalization team that drives this work, but of course we all are involved to one degree or another.
· Fixing bugs. Generally, the day after the product ships, we start collecting feedback from customers regarding bugs they’ve discovered (or suggestions they have) and get to work fixing them. Often, these fixes will go into a service pack, or into the next version of the product, or both. (See http://connect.microsoft.com/visualstudio for a statement on the disposition of such bugs.) A great deal of work is going on here right now, with our ever-awesome QA team spending a lot of cycles making sure we’re getting it right.
· MQ. “M” stands for “milestone” and “Q” stands for “quality.” Before we start the next product cycle, we need to do a complete review of our engineering processes and retool them as appropriate. We did this exercise last time after VS2005 shipped and it was incredibly successful – our new processes cut our overall in-flight defects in checked-in code by 75%, for example, and allowed us to make some huge performance gains as well.
This time around, our big goal for MQ is to push “dogfooding” earlier in the cycle. “Dogfooding” is a term that simply means that we use the product we’re developing while we’re developing it. This enables us to easily expand testing responsibilities to everyone in the division under a wider variety of conditions than can be covered in a test lab, which in turn helps us catch issues early. In earlier days, we would use the previous version of the product to develop the new version until about the second beta or so, then we’d switch to the new version and deal with the resulting issues stemming from that adoption at that time. Over the years we’ve been pushing that switch earlier and earlier, and our goal this time is to be able to install and fully use the product during the coding milestones. This includes the spectrum from compiler functionality to production tools.
To achieve this goal, we need to make sure that the product will run “side by side” with the previous version (so as to not damage an installed version of VS2008, for example), we need to make sure that it installs easily, we need to verify that our automated testing is ready to switch to the new version, we have to set up the appropriate code storage and bug tracking for the new version so that the code can actually be checked in and acted on, and we have to retune our check-in requirements for new code to make sure we catch as many bugs as we can before they get into the main build. There are a lot of other “initiatives” going on as well which will make our engineering more efficient. It’s challenging to do this work so early, and it takes a lot of time and resources, but the ultimate value stemming from success is very great to both us and you.
· V Next! At the same time all of this is going on, we’re hard at work planning what the next version of the product will look like. We’ve got a lot of suggestions from you and, given those plus a lot of cool ideas of our own, we’re actively working on a roadmap for the next version of Visual Studio. It’s always a very exciting time – I really enjoy seeing the prototypes and proposals. The best part comes when you look back when it’s all done and say “Wow, we really did what we set out to do!” That’s the feeling I’ve got now about the VS2008 product (“Wow, LINQ is so cool!”), and that’s the feeling I want to have when we release the next product. Over the next few months information will start showig up about the features in our next release, and I’m sure you’re going to be excited about what we’ve got in store.
It’s a lot of work going on all at the same time for us – for my part, sometimes I feel like I’m trying to carry on three different conversations at once on three different topics, hoping I manage to keep all of my work in the air without dropping any of it. Alas, playing a waltz tempo on an electric organ isn’t likely to help me this time, but unlike the juggling situation I mentioned at the beginning of this post, I do have the advantage of working with a great team of people.
Next month, I hope to demonstrate do some more coding for this blog – it occurs to me that I haven’t done anything with LINQ yet in my posts, and I need to correct that. In the meantime, I’ve made my old code easily available on our new Code Gallery site – you can find it at http://code.msdn.microsoft.com/templeofvb. It includes an installable version of the VB Euchre game as well – check it out!
‘Til next time,
–Matt–*
Light
Dark
0 comments