A Glimpse into Windows 7 Engineering Process
With the software world gone mad on software process it can be hard to know what level of control to apply for success.
An intereting article describing the engineering process for Windows 7 in comparison to Windows Vista has been written by the talented Larry Osterman at Microsoft. I am a new follower to Larry Ostermans Weblog, so have been reading his past entries. I have been aware of his technological presence at Microsoft for a long time, but have never had the joy to see quite what an author he was. A truely fasinating man.
Some interesting paragraphs to note:
“A feature is not permitted to be checked into the winmain branch until it is complete…In addition, when a feature team takes a dependency on another Windows 7 feature, the feature teams for the two features MUST sign a service level agreement to ensure that each team knows about the inter-dependencies.”
I really respect that, too many times have people or teams just not spoken to each other! Stops this problem dead.
“Similar to Windows Vista, the leads of all three disciplines get together and decide a set of features that go in each release. They then created “feature crews” to implement each of the features. Typically a feature crew consists of one or two developers, a program manager and one or two testers.”
The four words I have underlined at the end of the quote couldn’t say it better. Far too frequently software projects overrun because the people managing them do not realise the need for full project testing support. Managers assume a ‘testing phase’ at the end of development lasting a minor percentage of time in comparison to the development time. I am a firm believer in testing thoroughly and testing throughout the development cycle using multiple techniques. At the end of the day time saved in testing is money saved in the long run.
Larry further talks about the advantage of placing test members into the team for the whole development cycle:
“This is a massive change from Vista – in Vista, since the code was complete we’d have simply checked in the code and let the test team deal with the fallout. By integrating the test teams into the planning process at the beginning we were able to ensure that we never put the test organization into that bind. This in turn helped to ensure that the development process never spiraled out of control.”
How it should be done!!
A very interesting read taken from a post on the Windows 7 Engineering blog:
Engineering 7: A view from the bottom
His blog can be found on my blog roll or here, many many interesting articles:
Leave a Reply