Right now there is a big buzz in testers-world. If you do some searching on the web and you can find several examples of it. Testers are all awaiting interim builds at a higher rate but are not provided with any. Not for Windows 7, Office 14 and Dev14's (Visual Studio) CTP expired somewhere early this year. Ok, ok for Windows 7 there is one build where testers can work on.

There appears to be some anger around as there are more assumed pirated interim builds around than builds provided through official channels.

Compared to previous development cycles this was a big change in release strategy and I recognized this earlier and blogged about it in one of my previous blog items almost a year ago now. You can (re-)read it here: “Closed curtain development at Microsoft”

So what’s it all about?

Chris tries to explain it at GeekSmack. In his little essay he shows the reader that he was bothered with the same question and decided to simply –ask– Steven about it not expecting to receive an answer from Microsoft's big Executive. But he claimed to have received an email in return that explained to him why a software house like Microsoft is better off not providing too many interim builds to external groups of testers.

So go out and read the article Chris wrote http://www.geeksmack.net/microsoft/134-windows-7--no-interim-builds-why.html and return here to read what I think about it.

Ok … Did you all read the story? Let’s discuss it a bit more.

The article shows that providing interim releases will take away large portions of potential development time that otherwise could be used to build new features, repair bugs found internally or design new interfaces.

Each interim release is eating weeks due to prepping the software before handing it over to the tech testers.

Is this a valid reason to you? Do I think he is right and is the reasoning behind this valid enough to stick with the plan?

After my first reading I thought it was pretty valid, why waste too much time providing bits to the tester especially if it takes a lot of time to deliver a proper build. When I was thinking about it some things entered my mind.

1.
Why do they prepare the interim builds before handing it over to a group of people who already –know– the build is broken, crash prone and likely to smoke your processor? The answer to that, as was explained by Steven is that it simply is bad advertising and and opportunity to anyone who wants to bad-mouth and show that MS and its software is evil.

2.
It shows that preparing the interim builds takes a couple of weeks to ‘stabilize’ the build. Fixing bugs and avoid anomalies to provide the tester a pleasant experience when testing. This prepping obviously wasn’t a complete waste of time as several bugs are identified in this timeframe and fixed at the same time.

My personal view to the first item is that I simply –would want– my interim build to be unprepared, no special treatment … nothing. If it breaks it breaks and that’s it. I’m a geek and working with builds that break is my life. Part of the game is finding the scenario that will show how to bring software on its knees.

That doesn’t prove that the software is bad, the developer isn’t a donkey but in fact it shows that a developer is –human– and you were able to find the issue –before– going RTM. So you saved time and money for people working on the RTM product who otherwise would have been struggling with an unexplained error in the software.

In one of the previous development cycles of one of the other products I once found a bug just –after– the product was RTM. I hated that, but the worst part was that I, and the rest of the world, had to wait for months before the fix made it into the product although the team fixed it the same week that I found it. That is how it works. If I just released some software and you found a bug while you had a chance to find it weeks earlier you can't expect me to push out another RTM within a week.

There is a document somewhere on the web that shows you that fixing a bug when the product is released is way more expensive than fixing it before releasing it. So as a developer I’d say fix the bug and live with bad-mouthing. If anyone wants to say bad things they’ll find a stick to hit you anyway.

Losing time preparing the interim builds as shown in the second statement is, in my eyes, another misunderstanding. Besides what I already pointed out above – not wanting build to be prepared at all – there are significant flaws found in the preparing process so that is a big win, not lost at all, kill the bugs early!

Besides that, preparing also forces the teams to think early about documentation and instructions. And from time to time the developer –will know– that what he built will is released to at least a group of external testers so he probably will check and double check the software he wrote and test it to the boundaries. Would you like to get embarrassed for faulty code that could be found and was in the end from your hand?

For now the explanation makes me I understand where Steven is going but as a “Developer, Developer, Developer” I think otherwise and it’s not what I’d prefer when I was at the steering wheel – but I’m not :-)

So what do –you– think of all of this? Do you think it’s ok to keep it behind the closed curtains and only open to premiere? Or do you think it would be better to share the software –with the bugs– early and have them fixed it in an early stage or even point to a potential design error due to the things that –you– do in –your– scenarios?