| (3/3) "For example, we went with a client-server design, though at first things like context-switching rates and cache misses were too high," Lucovsky recalls. "Things were slow. But we didn't let ourselves get concerned with the size of memory. Not everything can be at the top of the list. We consciously put performance lower on the list than extensibility and didn't pay close attention to memory footprint until (version) 3.5." We talk about how the operating system evolved with each release, from memory optimizations and Power PC support in versions 3.5 and 3.51 to kernel-mode GDI and User, plus a new user interface in version 4.0. "The basic, internal architecture has not changed, except for Plug and Play," Cutler says. "We wanted a good design from the beginning so that, ideally, people could put anything on top of the system once it was there. We focused on the underpinnings. We wanted to minimize the need to add to the base or to tear up the base, because doing those sorts of things creates a lot of bugs. If moving forward you don't have to touch the basic code except to make small tweaks, then you know you got it right." Some things must wait At the same time, Cutler admits, "Nothing is ever architecturally correct." Needs evolve, and it takes time to build an operating system. Although support for distributed computing and clustering were part of the original vision, features such as the Active Directory haven't come to fruition until Windows 2000. "If we tried to give customers everything with the first release, we would never have finished it," Lucovsky says. Cutler elaborates on this philosophy. "If what we desire is to have a mature operating system, then we need to achieve revolution through evolution, through incremental improvements. Within five iterations of an operating system like Windows NT, you see a big difference." Both Cutler and Lucovsky see taking advantage of every opportunity to increase quality as the top priority for Windows. Reliable is cool "I'd much rather see the most reliable and usable operating system than the most whizzy-bang operating system," Cutler says. "To increase reliability we have to make choices. For every 10 bugs we fix, we may introduce three more. But do you want to ship with 10 bugs, or do you want to ship with three?" "Do you want one more new feature," Lucovsky concurs, "or do you want to fix more bugs? "When the Internet was first catching on, it was OK if your browser crashed once in a while. But these days, if you go to an e-commerce site and you hit the Buy' button, things had better work. When you're dealing with a leading-edge piece of technology, you can play fast and loose with it. But as the technology matures, playing fast and loose isn't acceptable anymore. This is characteristic of the maturing process for a product like Windows. People will put up with more from the bleeding edge." "What I think is cool," Cutler interjects, "is that the system doesn't crash, and it doesn't lose my work, and it has functionality. I could care less that the visuals are flashy if my 32-gig hard drive goes away." Communicating quality "And if you're a consumer," Lucovsky responds, "you want even better reliability." He concludes: "Quality is the most important vision that everyone working on this product needs to share. It isn't always easy to communicate how we're going to do this, particularly as the team gets bigger." The growth in the number of people working on the project over the last 10 years has other downsides, Lucovsky notes. "When you have a bigger group, quality problems become especially detrimental to productivity. Say it takes 10 developers and testers to fix one bug. Whoever put that bug in there just caused 10 people to lose time. We're working to make sure our development tools keep up with the growth in our system and our team. We're streamlining the process in ways that will make a dramatic difference in the way we build the code." "If we want to stay competitive," agrees Cutler, "we have to invest money in tools and mechanics as well as features. We need to put guidelines on paper so that people stay good at planning. Simple things like writing a good spec are basic to software engineering." Museum quality It all comes back to the spec. As I leave Cutler's office, I wrap the NT/OS2 spec in my jacket and head back to my building. I have three computers with lots of whiz-bangy, new fangled things running on them, but for a few hours it's the spec that holds my fascination. As a Microsoft geek, I feel like I'm holding a piece of history. And it turns out I am. This fall, the spec I borrowed for a time will join the Information Technology collection at the Smithsonian Institution's National Museum of American History in Washington, D.C. It's another good reason to write a spec. |