When more is less

In retooling our QA lab we've dropped the number of machines by half...and become more productive! Our work involves constantly re-installing windows service packes, hardware drivers, and assorted telephony software. Turns out that looking after of lots of machines was wasting time. We didn't used to have an organized way of managing the machines; we didn't know what was already on them, especially after a week of testing.

The cry always went out for more machines, which arrived "clean" and ready to go. Of course, after a testing cycle the new machine could end up just as messed up as all the others. Later, when the next release rolled around it was "we need more machines" all over again.

Reminds me of the old tale about the workbench with 25 screwdrivers and a set of storage slots for the screwdrivers, but only 24 slots. In the beginning each screwdriver was in its appropriately marked slot. Except #25 which someone borrows. Then another worker borrows #15. When the first worker returns, he puts #25 into the only open slot, #15's slot. Then he borrows #7. Now the second worker returns and puts #15 into slot #7. Pretty soon all the screwdrivers are in the wrong slots. The whole storage system fell apart because of a single insufficient slot.

Even in Windows-land, OSS is here

We installed Subversion and Trac here last week to replace Starteam for defect tracking and source control. Firefox and GMail/Yahoo/Hotmail are rampant. Asterisk answers the phone. All these open-source software tools have replaced commercial products. Even here in a traditionally Microsoft shop, OSS is starting to mainstream. And we didn't need to switch to Linux to do it. Yes, the Asterisk box runs Linux, but it's just a box on the network, like GMail is a service on the larger network called the Internet. Who cares what GMail servers run; Windows clients can use it happily.

Yes we still use Exchange, Visual Studio, and GotoMeeting.com. But in five years?

Ballmer on Vista

Scott Rosenberg has an interesting article on Ballmer's comments that Vista has come out pretty much as expected. I think there are about 30,000 programmers at the Redmond campus. It boggles the mind how that many coders can get anything done that doesn't duplicate, simulate, or break what others are doing. For many years they coped through specialization. Each programmer got something tiny, like a single Win32 API call, to work on.

Then after XP they pinned the needle the other way, and a rewrite orgy began. It produced some good things. XAML is good. They completely rewrote Window's TCP/IP stack; which is quite an act of chutzpah, and now it supports multi-core CPUs in useful ways. But overall they ended up suffering exactly the sort of problems that a Big Bang approach would bring.

In a way it's a smart move though. Most people are quite happy with XP. Any next version had to be a long-term, next-generation thing. People will love Vista in 2009.

Estimating Software Projects

Estimating how long it will take to finish a software project is one of the toughest parts of software engineering. Luckily it's easier to get better: start making estimates now and track your accuracy.

Two rules of thumb:

1. Make a guess and double it. I find this one surprisingly accurate. Probably because I tend to work on the same sorts of projects; but then don't most programmers!
   
2. Brook's book The Mythical Man Month says that every app has a core set of functionality that can be done in X weeks. To create a product will take 9X because of all the wrapper code for config/reporting/error handling, and all the user documentation that needs to be provided. People constantly underestimate this factor of 9.

We normally provide estimates that include design, coding, user docs, but not QA. My manager likes an estimate to broken down into a list of tasks that fit on a single page. Tasks that you are most unsure of should be clearly identified by using a range such as "4-10 weeks".

The whole game of making & meeting estimates is about what features are "in" and what's "out". I like to tie estimates to an explicit list of what features users will and won't get. Requirements are bound to change, and managers sometimes have a habit of forgetting that your estimate was tied to a feature set.

As usual, Joel has written on this already.