Slashdot Mirror
Why Vista Had To Be Rebuilt From Scratch
iliketrash writes "The Wall Street Journal has a long front-page article describing how Jim Allchin approached Bill Gates in July, 2004, with the news that then-Longhorn, now-Vista, was 'so complex that its writers would never be able to make it run properly.' Also, the article says, 'Throughout its history, Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program. Now, Mr. Allchin argued, the jig was up. Microsoft needed to start over.' And start over they did. The article is astonishing for its frank comments from the principles, including Allchin and Gates, as well as for its description of Microsoft's cowboy spaghetti code culture."
Because much as /. knocks them this is the sort of thing they can manage, astonishing turn arounds.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I think the poster meant "principals," since it's well known that there are no "principles" in Redmond.
To quote
Microsoft's greatest enemies now are still two for-profit companies - Google and Apple. I'll rest easier when FOSS replaces them (as was promised in 1999). Instead it's just a new master instead of the old one.Quidquid latine dictum sit, altum videtur
"Microsoft's cowboy spaghetti code culture"
If its any thing like "Guns n Roses - Spaghetti Incident" then this should effectively be the last we hear of Microsoft.
It's interesting to hear how their software development survived in such an anarchistic environment - everyone producing their own code, with ad-hoc integration. It's a good example of how software development methodology can work though, even though the specifics of the specification design weren't discussed in the article - if everyone codes to a documented interface, software development can work on such a grand scale.
I personally would like to hear more about the software development procedures and methodologies used in other large projects - how successful different types of development are.
I work for an automotive parts manufacturer, and to see the lack of consistency within the organisation's software development is disturbing. Safety-critical parts are being produced, and the level of testing between said parts varies quite considerably. Additionally, the level of oversight and adherence to software development procedures is rather bad to say the least. I just hope it's not characteristic of the industry as a whole.
Man, that's a shame. I'd love to have seen film. Shame on Allchin if he didn't demand an archive copy that be retained, at least, even if it's only released in 20 years' time.
And Linux is what exactly?
A highly structured and organized operating system developed under the instruction of a central authority, no doubt?
Don't be such a hypocrite.
Why is it "astonishing" that the article does a decent job of providing hard-hitting information without spin? That's what we are supposed to expect of journalists. The Wall Street Journal is supposed to be (and often is) an example of real journalism. That makes it distinct from computer magazines that rely on advertising revenue from the computer industry, and from discussion forums whose course is steered by peeves and submission sequencing.
Microsoft's holy grail is a system that cranks out a new, generally bug-free version of basic Windows every few years, with frequent updates in between to add enhancements or match a competitor's offering.
I really wish they explain me the difference between "generally bug-free" and "bug-free". Is the difference around 65,000 (as Win2000 has ~65,000 known bugs when launched)?
It's interesting to juxtapose PR spin from Microsoft. At any given point in time in Microsoft's history, their stance and PR is that they are "state of the art", the most advanced, etc. Yet also at any given point in time they're badmouthing their own product, their own methodologies, from their recent past. Of course their chest thumping for their current "state" prevails, but I'm guessing down the road we're going to hear how messed up they are today, but not until they've made billions off of today's products.
One of the best books I ever read on the Microsoft code culture was "Breaking Windows: How Bill Gates Fumbled The Future Of Microsoft" by David Bank. From the book, Jim Allchin is the Windows guy who quashed Brad Silverberg and the (relatively) innovative Internet team - although ironically he was an early advocate for getting TCP/IP support in Windows. He believed that all innovation in Microsoft should take place under the Win 2k banner and that the company should just keep making Windows bigger and bigger and bigger. Hmm, maybe it got too big.3 203151/qid=1127565487/sr=8-1/ref=pd_bbs_1/102-0616 241-1101748
http://www.amazon.com/exec/obidos/tg/detail/-/074
Tristan Yates
Not only does it explain a lot, it's been glaringly obvious for more than a decade. Everything Microsoft has done since before the days of Windows 3 has smacked of design-by-committee and a painful lack of consistency. Everything in Windows has always had the smell of being designed and implemented by dozens of groups that had little or no communication with each other. I'm surprised they managed to release code at all, however buggy and insecure, with the development model they were using.
It will be interesting to see if Vista demonstrates an improved level of quality due to this new process.
You are in a maze of twisty little passages, all alike.
When I took C programming in College, one of the points our professors made was if you like your program, rewrite it...
;)
the first time you write something, it's always hackney'd - and it gets that way till you figure out what you want to do and how to do it - afterwards, it then becomes so much clearer to see ways to clean up the code and fix issues...
so one of the first rules he had was once we were almost done, restart our stuff - it ended up being a lot cleaner/modular the 2nd time around...
of course, that won't help MS, but good for the rest of ya to know
RB
----------
ah honey, we're all resplendent - Bill Mallonee
You know, when I read the article, I was thinking: This sounds almost exactly like how Linux is developed, except that all the authors aren't employed by the same company. Who would have thought that the Open Source development model would be the same as that at Microsoft?
GreyPoopon
--
Why is it I can write insightful comments but can't come up with a clever signature?
So the amazing new innovation that's turned round the entire project is... automated testing? Wow, welcome to the brave new world of the mid 90s! Next up, Microsoft discovers the joy of source control... (incidentally, I need to find some solid info to justify not using SourceSafe - any pointers/links?)
Microsoft is not a NEAR monopoly. It is a convicted monopoly. And since that irrefutable and well published fact escaped notice of the Wall Street Journal, I can't help but smell a little bias.
If someone says he and his monkey have nothing to hide, they almost certainly do.
Just look at this quote:
They are comparing an operating system, which has to be backward compatible with a dozen or so earlier versions of Windows and DOS and support an oodle of devices and subsystems, with a bunch of mostly unrelated web-applications and gimmicks from Google.
All I'm getting from the article is that the "let's rewrite from scratch" crowd got the upper hand within Microsoft. But that doesn't necessarily mean that they are right or that the end result will be better than continuous improvements. At the beginning, it is easy to maintain a nice, clean and simple system. But a complex set of requirements can't always be broken down into simple Legolike blocks, as the article suggests.
Right, but have you ever noticed how many successful Free / Open Source software projects use modular architecture? Take (from my own area) Nessus, or Snort. Both consist of a core engine and frameworks that accept plug-ins and modules. Actually they both also have a lower level that allows ordinary non-programmer users to contribute signatures (rules) to the project.) This applies also to Apache, Mozilla, the Linux kernel, and plenty more.
Battling Google, Microsoft Changes How It Builds Software
Delay in New Windows Version Drove Giant to Develop Simpler, Flexible Product
Engineers Get Trip to 'Bug Jail'
By ROBERT A. GUTH
Staff Reporter of THE WALL STREET JOURNAL
REDMOND, Wash. -- Jim Allchin, a senior Microsoft Corp. executive, walked into Bill Gates's office here one day in July last year to deliver a bombshell about the next generation of Microsoft Windows.
"It's not going to work," Mr. Allchin says he told the Microsoft chairman. The new version, code-named Longhorn, was so complex its writers would never be able to make it run properly.
The news got even worse: Longhorn was irredeemable because Microsoft engineers were building it just as they had always built software. Throughout its history, Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program. Now, Mr. Allchin argued, the jig was up. Microsoft needed to start over.
Mr. Gates resisted at first, pushing for Mr. Allchin's group to take more time until everything worked. Over the next few months, Mr. Allchin and his deputies would also face protests from programmers who complained he was trying to impose bureaucracy and rob Microsoft of its creativity.
"There was some angst by everybody," says Mr. Gates of the period. "It's obviously my role to ask people, 'Hey, let's not throw things out we shouldn't throw out. Let's keep things in that we can keep in.'"
Ultimately, Mr. Allchin's warning proved cathartic and led to what he and others call a transformation in Microsoft's most important product. A key reason: the growing threat from rivals such as Apple Computer Inc. and makers of the free Linux operating system. In recent years these companies have been dashing out some software innovations faster than Microsoft. Google has grown particularly effective at introducing new programs such as email and instant messaging over the Internet, watching how they perform and regularly replacing them with improved versions.
Microsoft's Windows can't entirely replicate that approach, since the software is by its nature a massive program overseeing all of a computer's functions. But Microsoft is now racing to move in that direction: developing a solid core for Windows onto which new features can be added one by one over time.
As always, Microsoft's great fear is that it will lose its near-monopoly on computer operating systems and basic office software. In the short term, there is little danger of that. But the more Google and other software makers encroach on Microsoft's turf, the greater the chance that someday computer users will wake up and find Microsoft Windows superfluous.
"What happened when the American car companies failed to update their manufacturing lines? There was a more efficient way to bring cars to market for a lower price and they lost their market," says Microsoft Vice President Chris Jones. "We're in a little bit of a different industry but it's the same thing."
Microsoft's holy grail is a system that cranks out a new, generally bug-free version of basic Windows every few years, with frequent updates in between to add enhancements or match a competitor's offering.
The Longhorn crisis helps explain the sweeping restructuring that Microsoft Chief Executive Steve Ballmer announced this week to organize the company into three major business units. A key goal is to force Microsoft to be more nimble in producing and delivering software.
Mr. Allchin's reforms address a problem dating to Microsoft's beginnings. Old-school computer science called for methodical coding practices to ensure that the large computers used by banks, governments and scientists wouldn't break. But as personal computers took off in the 1980s, companies like Microsoft didn't have time for that. PC users wanted cool and useful features quickly. They tolerated -- or didn't notice -- the bugs riddling the softwar
Don't be such a hypocrite.
The difference being, Windows is touted as a professional OS built by professional coders, upheld to a high standard, etc, etc, etc. Simply put: People expect more when they have to pay for it. Microsoft has constantly criticized projects such as Linux, because the code isn't built by a central authority. Now we learn that Windows is made pretty much like Linux. I think criticizing Microsoft for this is definitely justifiable.
Microsoft's new approach: Ultra-Extreme Programming.
Now they have taken the pair coding concept well beyond the next level. They put over 5000 developers in one auditorium, and they now write Vista together as a group. The shared display is up on the movie screen, and every coder has a wireless keyboard and mouse.
They're going to use thousands of minds working as one to produce a single, cohesive body of code. With so much manpower on the problem, development moves at a lightning pace: once a function has been typed in, it gets refactored dozens times within a matter of seconds.
Of course, you are right: Microsoft is indeed one of the most competently managed companies around. And that is exactly their problem.
Why is that a problem? Because their management, sales, and marketing are so good that their technology doesn't have to be. They can ship software with security holes, bugs, poor usability, and bad design, but the non-technical part of the company will somehow manage to still sell it and make a bundle on it.
I'm sure the root cause of cowboy coding is in Microsoft's quest for being able to put check marks in feature boxes so PHBs can pick MS software as having the most "features." Back in the 80s there used to be a number of standalone outlining applications and high-quality outliners embedded in competing word processors. Then Word got an "outliner." That this "outliner" never worked and still doesn't work to this day is irrelevant. It enabled MS to put a check mark in the outliner feature box and eliminate user's arguments that they need a non-MS product because they need an outliner.
Checkbox marketing -- about the only way to market when non-users make purchase decisions -- drives software companies to bolt-on features without regard to consistency of or destructive interactions between features.
Two wrongs don't make a right, but three lefts do.
After the Windows group was able to install a workable version of the system on their PCs four days before Christmas, Mr. Srivastava says the group celebrated by not working over the holidays.
They also like to celebrate by not having their fingers broken.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
If you're going to continue to post this troll, PLEASE replace >1% with 1%! I've seen this so many times, and it's always got that same typo.
Throughout its history, Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program.
Sounds like SOP for any massive program/OS. If you've ever been part of a truly massive product's development, you'd know what this is like. There are dozens, if not hundreds, of small groups that each specialize in a particular piece of functionality. Executives and architects determine the work items for a particular release. Responsibilities filter down the chain of command. Teams develop their work items for the release and everything is thrown together into the pot as it's done. Builds break frequently, and problems are addressed as they're encountered. Eventually testers can get their hands on decent builds, and testing/bug fixing commences during the whole process. Some ways down the road, a release finally occurs.
Really, I don't know what the executive in the article thinks should be happening. There really isn't any other way to develop programs on the scale of Windows without the aforementioned "organized chaos". It's not a text editor, it takes numerous small teams working in a coordinated manner to produce such massive piles of code. Obviously, the more teams there are, the harder perfect coordination is to achieve. Hence, things go wrong fairly frequently. This is to be expected, IMO.
The same code is still there, and the same "start menu" philosophy. This wasn't a philosophical and technology change, it was an administrative one.
I'm glad they have good Quality Control now... maybe they'll apply for the ISO 9000 designation? Regardless, I don't think this points to a new thinking or revitilization in the company as the title and article seem to suggest.
It's not a new code base, just a new process.
There is a rage in me to defy the order of the stars, despite their pretty patterns.
That's terrible advice. Real-world code tends to be messy because you have to put in a lot of workarounds and bug fixes. When you rewrite something, you lose years of cumulative bugfixes. Suddenly obscure configurations are crashing, and you have no clue why, because the old code bears no resemblance to the new code, and the beardly expert on that platform has retired, so nobody is there to tell you that although the specs say foo should be a float, it actually expects an int.
It's one of those practices that works well in college courses, but simply falls apart when applied to a project larger than a few thousand lines of code. Tell me, did this professor have actual real world experience, or was he in academia for his whole career? I'm betting on the latter.
instead of rewriting, you should refactor, preferably with the aid of lots of regression tests. That enables you to restructure the application slowly, without changing behaviour in unexpected ways.
Things you should never do: rewrite.
You sound like somebody who hasn't used Linux in a long time. In fact, it's amazing how far Linux has come in the last few years.
You've obviously never heard of Synaptic. I suggest you take a look at some of the screenshots. Most distributions now come with Synaptic. To install software, you just load up Synaptic, select the programmes you want to install from a list and click a big "Install" button. What could be simpler?
You seem to have a hard time grasping this but this is actually simpler and better than Windows. Windows has no dependancy tracking. I can't count the number of times I tried to install game X and the installer has told me that before I install, I need to first manually install the latest version of Internet Explorer / Windows Media Player / DirectX.
With Linux, all my programmes are on something equivalent to Windows Update. Not just the OS but also Office Suites, Games, Media Players... you name it. I can install them easily using a graphical interface and they get upgraded automatically when new versions come out.
As for driver support, Linux beats Windows out of the box, hands down. Drivers for most devices come already included with your distribution. They get loaded at boot time if that piece of hardware is detected. On my desktop, my DVB card, Sound Card, Graphics Card and Display were all detected correctly first time. Windows might have a driver for the Sound Card but a DVB Card?
Installation is so easy too. My distro of choice, Ubuntu, all you have to do is select your keyboard layout and where you want to install to and it does the rest. No intervention necessary. If you can't do that, there's something terribly wrong with you.
>>>programs from rivals were like Lego blocks -- they had a single function and were designed to be connected onto a larger whole.
Sounds like the assumed philosophy behind the Linux kernel and most OSS projects. But Microsoft has claimed for years that a good OS couldn't be built that way so say a blue IE lego block could easily be replaced by a red FIrefox lego block. Which was probably one reason for Bill G's initial opposition.
>>>Microsoft's cowboy spaghetti code culture.
Yet isn't this the impression Microsoft tries to give to the collaborative method used for most OSS projects.
There's just one more lesson Microsoft needs to learn from Longhorn/Vista: Don't start promising features and showing Powerpoint presentations to the press until you understand the scale of the project.
I love Google, because they rarely promise something and don't deliver. Actually, they rarely promise something. It just shows up one day and it's elegant, clean, and fast.
There is, as I'm sure you already know, a difference between a C program you wrote in class and an OS. The reason your C program gets better when you rewrite it is because you now have a clear view of what it should look and work like. When it comes to a behemoth like Windows, no one understands the system fully. So even if we have all these people who understand parts of the system rewriting their parts, plenty of design errors can still persist in the way the system is modularized and put together.
So what should they do then? I have no idea.
It sounds like Windows is thrown together with practically no organization what so ever. Yet all the computer nerds that only code free time can make a highly stable, flexible, and organized OS.
-Tony
tonyville dot org
So, by using some implicit logic here, we all should accept Linux because even though it has its faults, it's free?
I didn't say that, and don't even think my logic says that. My logic is, if Company X produces product Ya, whereas I can get product Yb for free, I'm going to need product Ya to be damn good for me to get that instead. Is Yb perfect? No. Should it be used in place of something that's better? hell no. But should it be used in place of something that's just as good? Why wouldn't you want to?
Microsoft has attacked Linux's development method, saying how much better theirs was. People bought into it. Now we learn that they've been lying all this time, and that their development method is just "as bad" as Linux's. When you lie to people in order to get them to buy your "state of the art" product, people are going to expect it to be good. When they learn you've lied, they're going to be pissed, and it's fair for them to criticize Microsoft for this.
That's what I said. I don't know where this "implied logic" that Mac should be selling like pancakes comes from.
Not quite true... In the mid 90's they did release a version of their own internal tool known as ChangeControl under the name Microsoft Delta... it flopped, big time. Needing something better, they purchased One Tree Software in 1994 and rebranded their One Tree SourceSafe to the more Microsoft style name of Visual SourceSafe.
Help Brendan pay off his student loans
"Right, but have you ever noticed how many successful Free / Open Source software projects use modular architecture? Take (from my own area) Nessus, or Snort. Both consist of a core engine and frameworks that accept plug-ins and modules. Actually they both also have a lower level that allows ordinary non-programmer users to contribute signatures (rules) to the project.) This applies also to Apache, Mozilla, the Linux kernel, and plenty more."
That's out of necessity. Due to the distributed nature of it's development. It just happens to be a good methadology, but if all the OSS coders were in the same room? We'd be having similiar problems to MS. It takes discipline to resist, and I don't see anything in OSS developers that's not also present in other coders. Which shouldn't be a surprise because a lot of OSS programmers work professionally in their day jobs, and have been educated in the same institutions. They read the same books, and research papers.
This comment is pretty short-sighted. While I agree that Apple made a terrific choice with OS X, it is certainly not the only choice and maybe not even the best choice. UNIX-style operating systems have a lot of merit, but again, they're not the ONLY Right Way to write an OS. The NT kernel actually has a lot of good design in it and a lot of smart people worked on the early versions of it. In particular the message passing facilities in NT are much nicer than on many Unix systems.
Windows can easily be a viable platform without totally scrapping the fundamental design. I think its cool to see that Microsoft is willing to take the risk of starting over and trying to get a good platform to build on.
I've wondered for a long time why it was so hard for Microsoft to make good software. We all know that there are massive amounts of incredibly smart people there (most of the smartest people I knew in school work there). I think this article speaks to a lot of the reason and I think its neat to see that things _MIGHT_ be turning around.
Things you should never do: rewrite.
Naah. Software is math and the first proof of a theorem is generally ugly. So, it can pay to start over. I am not going to say in all cases it's better to do one or the other, but sometimes rewriting is the best option. An example from my own life: I wrote a MUD with some neat AI stuff (quests that actually impact the world in large numbers) in it and now I am working with a small startup to make an MMO and started over rewriting because the way I did it was bad the first time, but it was the best I knew how to do because that was all I understood about the problem. Now I have a more modular system and I understand how quickly certain things need to happen, and what needs to interact with what, which means I can split things up among databases and such . One thing to remember is that if you have a system that does X and you just want it to do X with a little bit more, then you don't rewrite. Even if you repeatedly have to do a little bit more. OTOH, if you have a system that does X and then you realize you need to do X and Y and Z...then maybe you need to rewrite depending on what you need the system to do.
Best. Comment. Ever. Enjoy!
90% of the comments I've read so far are either entirely or partially "omfg... microsoft suks!". However, read the entrie article, and you are faced with an interesting siutation.
Software always has to strike a balance point... between features, quality, cost and timing. All software does (sans Duke Nukem Forever). Microsoft has been very good at getting product out there with the feature sets people want (Microsoft is also very good at manipulating folks into getting folks to want what they are able to deliver). Now, they are at a cross-road. Continue their current coding model, and get the next couple versions out there (relatively) inexpensively and quickly, or bite the bullet, and try a new way that will make them competitive for serval versions.
Seems like an easy choice. But here you have thousands of developers who style is being crimped. Software engineers generally want to write code, not have constraints placed on them. Add to the fact that Google is gobbling up the best and brightest, and suddenly you wonder: If Microsoft forges forward, do they lose even more of their best engineers. They may have a better model for code depelopment, but will they have the best coders to move forward with?
Which leads to the final question: Does Microsoft really need the "best and brightest" anymore? If so, do they need as many (percentage terms) as they used to? Their products are mostly in the mature stage. Can a few intellectuals keep the ship moving forward. Despite what groupthink on Slashdot may indicate, 90% of coding is not revolutionary, or even evolutionary.
Just some things to think about and watch for over the next few years.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
There is sometimes a difference between what a word really means and what a court defines a word as meaning in a specific context. In MS's case, a court convicted the company of having a monopoly within the context of anti-trust law. The Wall Street Journal is using the word as it is actually defined by real people, which means to own ALL of a market. The newspaper is properly labeling reality, not showing evidence of bias one way or another. The fact that I detest MS and Windows doesn't keep me from seeing that the WSJ is just doing its job properly in saying "near monopoly." The moment you don't have ANY choice other than Windows in the market, it will be a monopoly. For now, though, the fact that I'm typing this on a Mac and can go buy as many non-Windows computers as I want says MS does NOT have a monopoly. Period.
It's not so much that rewriting is but but that there are bad times to rewrite. Really old and stable code isn't a good target. Really new code with completely new function and an architecture which has been found not to be a good match for the real world objective it's addressing would be a much better target.
That might work for small college projects but the real world is a different place.
;)
Often the rewrite never gets completed as there is too much crap added to it.
If you truly want to make something that works you need to plan for an evolution of your software. That is, write the first version with a modular design that can be modified or rewritten in phases. Doing one big rewrite on a non-trivial software system is damn near impossible. It's better to evolve the software over time, always keeping a working system and slowing moving parts in the desired (presumably better) direction.
I could write more on this but it's too early in the morning and I'm not even sure if what I wrote makes sense.
The ratio of people to cake is too big
As for SourceSafe, I've been told that it sucks. Badly. The source control in Visual Studio Team System is meant to be an awful lot better - they're trying to compete with things like Rational ClearCase. That said, it's both pricey and a 1.0 release. It might be worth looking at, though, if you have management insisting on a Microsoft solution.
1. They can see "all" of the code if needed. They can see how it works together if they need to. I'm sure code inside of Microsoft is doled out to parts on a "need to know" basis. Or not doled out much at all.
I would be surprised if people who actually are employed by MS itself don't have access to all the code. They may not have check-in rights, but they should get viewing rights, because there is no credible (legal, management, or technical) reason to prohibit them from doing so.
2. There are a bunch of users running the code all the time as its being developed and feeding back info.
Do you believe there are more testers for the linux kernel than for the windows kernel? I sincerely doubt it. Most FOSS users use only the stable release of most software (they may run development releases for a select few programs), because running development versions of anything tends to leave you with a non-usable system.
(3. They use the code themselves and have a ethic working to make the best code they can for themselves, knowing it wont be used as a tool to extort money from people.)
Yes, and the windows developers don't use windows themselves. Ofcourse not. Why ever would they do that?
I would challenge you to find anything open source developers can do process-wise that is not feasible in private enterprise. I have yet to find something.
Don't I remember Microsoft setting out to completely rewrite Windows from the ground up in 1992, with a more professional development approach? Wasn't it called something like Windows/NT ("New Technology"). What makes them think that they'll do any better this time, with the same same designers and programmers that produced what they have now? Those who forget history ... etc etc
How could they possibly re-write it from scratch in as little as a year. Impossible. If I were a betting man all chips would be in.
Every release of Windows you will hear Microsoft clamor the most secure and stable version ever!
"The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world."
Your Average Joe
It sounds like with Windoze, any of their developers could just check in their code with little or no oversight.
On Linux, all code gets inspected by others before it is accepted.
So, what you're saying is that linux development works better because it is top down cathedral style, where microsoft's model fails because it is a chaotic bazaar style?
That's generally good advice. Even if you did design it well, the second pass at writing it will (1) reinforce whatever you've learnt whilst creating the application, (2) allow you to optimise the first attempt (and allow you to not think about optimisations for the first attempt) and (3) mean your code won't embarrass you later on in life (handy for those job interviews where they want code examples).
...
:)
I need to do that with some of my code - it is just a matter of getting the time. There's the rub - if it takes you 1x the time to write the first version, allow 0.5x that time to rewrite it (less if you've done a lot of research and/or learning for the first version). So tell your boss that your code will take 1.5x your original estimate if he wants it done really well. Also allow time for web surfing and that hangover
However don't go overboard. Good up-front design and experience will mean that for many programming tasks you don't need to rewrite it all - maybe only a module or two. If you've got the overall design all wrong however, then god help you!
The article is very vague. It sounds like they're writing automated tests and rejecting any code that doesn't pass the tests. But I can't imagine that they didn't have a regression test suite before, so I wonder what changed?
Mac OS X is not that modular. GNU Hurd is far more, and even GNU/Linux.
Mac OS X’s kernel’ not modular at all. It has conflated the Mach microkernel, which has already been abandoned by the Hurd for its bad performance, with the monolithic BSD kernel. The result is something just as monolithic as BSD, but much larger, more complex and slow. Linux is not as fast or simple as BSD, but still much faster than Mac OS X — and both are just as modular.
In contrast, the Hurd on the Mach is a little bit slower but much more modular, and the new L4 version has the potential to be much faster and still much more modular, because it is a true microkernel with multiple servers.
The Mac OS X GUI’s not modular at all X is.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Linux has adult supervision
Translation :
All the developers live in their parent's basements, and walk the code upstairs to show their mom.
Glonoinha the MebiByte Slayer
The reason we tend to have more modular code in the Open Source world is that typically small teams of volunteers or small teams of coporate-sponsored part-timers work on the code.
The Open Source development process, in practice, is very different from what Microsoft does. People 'contribute' code to Open Source projects; Microsoft programmers have 'deliverables.'
If there ever was to be a mascot for Vista it should be a pig with M$'s trademark 4 colored butterfly wings. Sort of interesting if you look at the penguin it has "wings" but cannot fly.
The typical /. response: Damn Microsoft for trying to make a better OS!
Seriously, I don't care. I use both Windows and Linux. Whatever will get the job done using the least amount of effort possible.
the first time you write something, it's always hackney'd - and it gets that way till you figure out what you want to do and how to do it - afterwards, it then becomes so much clearer to see ways to clean up the code and fix issues...
Ok, I'm not a C programmer myself, but I do know one thing: if you have to find out what you're going to write after you start writing it, there's something extremely wrong in your process. I mean, whatever happened to actually designing the application ? Thinking about what you want to do makes much better code, and heck, it even saves you time; but yes, it's tempting, it's very tempting to rewrite code... why? Because programmers like clean code...
When you're writing an application over the process of say, what, 6 months, and at the 6th month you look back at the code you wrote in the 1st month, you think "Oh my god, what did I do there? Look at all the mess! This can't possibly be the best way to solve it!"... but if you designed your application well, and the function does what it does, there's no need to rewrite your application - you can possibly optimize the function, but please, don't throw away code that works - it's plain silly!
Anyway, to sum it up, the lesson I'm trying to preach: design before you code, don't throw away...
- Leon Mergen
http://www.solatis.com
Everyone works AT microsoft. Everyone comes in at 9 to 5. Its a lot easier to manage "a bunch of little programs" when all the developers are on the same campus. Its a lot harder when the developers are all across the globe, with different schedules, all stitching together their communication with /no central management authority/ to make sure everyone can communicate effectively. People who are reading this without thinking will say "Whats Linus, if not a central management authority?" OK, find a piece of code you dont understand in the linux kernel, written by someone who speaks a language you dont understand. Go ask Linus to facilitate getting that guy to explain his code to you. See how far you get. Nowhere. Now try it at microsoft, asking your manager.
One would think that because of this, Linux would be a mess, but we've seen the opposite is true: For projects to continue to evolve rather than quickly die off, they require _rigid_ structure and sane, intuitive modularity to support the OSS development model. Projects that turn into spaghetti code too fast just fizzle out and never make it into my slackware distro. While at microsoft, they have this whole management system that makes it easier to support spaghetti code. OSS has a much more brutal "natural selection" process that is constantly favoring modular, readable, easy-to-learn code bases.
Plus, spaghetti code is not fun, so hobbiest programmers arent going to waste their time with it.
Thats why so much OSS software is structured so well.
Why stick up for big business?
Depends on your situation. I was on a team that rewrote about 30,000 lines of code (more than a few) because the system had slowly, incrementally grown into a very brittle state and we had to add a bunch of new features. We rewrote it so we could continue to grow the system in the same incremental fashion. Was the best thing we could do - it's 4 years later and the system continues to grow in odd ways, but we never had to go back in and do more than minor fixes to that core. It worked because we knew more about how we wanted the system to work and about the problem space. It worked because we knew where all those bugs and ugly hacks and work-arounds were and we designed around them. Granted this is not 10M lines of code or whatever Windows has, but then again we were only 3 people part time.....if the entirety of the system is too complex for any single small team to understand and re-architect, then it needs to be split up and made more modular.
Sometimes the truth is arrived at by adding all the little lies together and deducting them from all that is known.
And if you believe this, you'll believe anything.
Same as with Half-life 2. I've seen interviews with members of the valve squad who actually said HL2 was completely redone from scratch, when maybee 60% of the code still has its origins in Quake 1.
My guess for vista is the same, they simply had to 'go back to bascis' because all their new stuff was badly organised. This is not the same as starting from scratch.
it is unbelievable how sad this article is. These MS 'engineers' only now started using automated integration testing, possibly automated unit testing. They only now started writing to predetermined interfaces and producing modular code. Gates, who calls himself 'chief engineer' never cared to start doing any of it before his house of cards, he calls his software production process, collapsed.
I can't get over this, I thought this must have been obvious, especially in a firm that releases products as big and complex as OSs. I only worked in this field for 9.5 years and in that time I delivered a bunch of projects doing exactly that: well defined interfaces, components, automated unit testing and automated integration testing and at MS there was noone before the shit hit the fan to start doing it that way over what? 25 years?
New process they have? New process my ass.
You can't handle the truth.
Put my two cents in as to how the article's storyline doesn't quite track. If Mr. Allchin, despite massive institutional inertia, gave the pig winglets and put it back on a track to actually being releasable then we're missing the motive for why he'll leave on Vista D-Day and why the company wouldn't fight to keep him. In some sense, the article is about the story Microsoft wishes to tell, which is we were writing bad code, but we've fixed that now (and look at the bruises: no pain, no gain, right?), which is what the parent posts suspects.
Now I suspect that the interviews took place before the Microsofta est omnis divisa in partes tres announcement, and there was no desire from Microsoft to have Mr. Allchin candidly describe his reasons for retirement (and maybe Mr. Allchin has a book up his sleeve), so off to press with this peek into the hallowed halls of Redmond.
One quibble I would have with article is in its suggestion that Mr. Gates, as Chief Software Architect has two paradoxical duties to reconcile: coming up with innovations and putting down unrealistic projects. A lot of the candid reporting I've seen is that there's a third element that he practices with zeal, which is to grind into a fine powder any idea he believes shakes a stick at the cash cows.
One implication of the story is that in Summer 2004 Bill Gates didn't know that one of the cash cows was flatlining. There's a thought to ponder.
Apparently you all missed the part that says "Mr. Allchin had announced to hundreds of Windows engineers that they would "reset" Longhorn using a clean base of code that had been developed for a version of Windows on corporate server computers." Yes, they threw it out. They didnt rewrite it all, it clearly says they restarted on a clean code from windows server. Most of you want MS to continue to screw up. Youre afraid that theyre adapting and improving. You hate the idea of MS entirely. Hippies.
Have you not used Windows XP? It works great. I rarely get blue screens (and they're not Windows fault, because my laptop is overheating). I game on it. I code C++ on it using VStudio .NET.
Your post smacks of zealotry, along with most of Slashdot. It annoys the hell out of me, all this Microsoft bashing.
Wheel in the sky keeps on turnin'.
We may recall how Gates said security was job #1 a while ago. Obviously they are paying more attention to that now, but a large part is to deflect blame for their daily exploits. And in this case the article says how all the nice new features of Vista have fallen by the wayside, it's years late, but the spin is, as always, "the next version will be better than anything ever made". The classic FUD, and in the WSJ; so the CEOs can tell their geeks not to worry about migrating to Linux, or OSX, because Alchin says Vista will be all that and more.
The point not at all investigated is the deliberate encouragement of spaghetti code over the last years, to hook IE, WMP, and coming DRM inextricably into the OS, the very opposite of the clean modular code advocated. Interesting to see which principle will give way.
I hope George Broussard over at 3D Realms isn't reading this, now its going to be 3030 A.D. when we finally get Duke Nukem Forever!
There are some more technical details on the big map of windows and the quality gates in this blog post:
0 8/23/455193.aspx
http://blogs.msdn.com/larryosterman/archive/2005/
I would challenge you to find anything open source developers can do process-wise that is not feasible in private enterprise. I have yet to find something.
Here's one - never having to hear "Ship it!". People working on OSS projects on their own time aren't generally being told, "you have to ship before Dec. 31st so we can get the revenue on this quarter's books", with no regard to whether that date is reasonable. Lots and lots of companies do it, and almost invariably the preference is to hit the ship date rather than spend the extra time to get it right. It really bothers me and everyone else I work with when we have to ship something we know is broken simply because the powers-that-be won't agree to a reasonable date that allows us to get it right the first time.
I'm rather surprised that Microsoft got their priorities straight this time, but you'll notice from the article that management wasn't exactly a friend to the process.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
There's a carrot and stick approach. The carrot is that Microsoft touts all the cool new features that will make life so much easier. Features you won't be able to live without.
Then there's the stick. Part of it is to have Office use features of the new OS, so you won't be able to perform some spiffy operation without it.
Another part of the stick is to badmouth the prior version, but explain that all the issues being badmouthed are fixed and gone in the new OS.
So you get stories where Microsoft "finally admits" to various things, (like that DOS really does underly Win9x, despite assurances that it was gone)... You've read them.
There's certainly truth to what Microsoft claims, and it's nice to see real issues being addressed. For example, WinXP's move away from the Win9x base to the more solid WinNT base was a huge win for most users (although gamers complained about a lack of drivers).
But don't be fooled - fundamentally, you're just looking at PR spin designed to created demand for an new OS.
Over time, one of three things happens to every large software project. The most common, of course, is that it becomes obsolete and irrelevant and is replaced by other projects. The least common of the three, traditionally, is that the code is continually refactored, a bit at a time, as a regular feature of the development cycle. Pegasus mail is a good example of this approach: every major release, David Harris refactors some major subsystem or another. Perl was also maintained this way, but *still* eventually reached the point of needing the third possibility: a complete rewrite more-or-less from scratch. (Some things can be re-used when this happens, e.g., documentation, especially API documentation, in the case of an OS; for Perl even the documentation needed to be redone for 6.0.)
The Win9x codebase already reached the point, around the turn of the century, where refactoring wasn't going to help it, and Microsoft chose, rather than rewriting it, to obsolete it in favor of the NT codebase -- probably the right choice. But then the NT codebase has also reached the same point, and rather than obsolete it they chose to rewrite it. Also probably the right choice.
This explains the delays, incidentally.
The thing to take away from this is that, public beta notwithstanding, the first release of Vista could be a bit dicey until it's been in the wild for a while, some of the unintended differences discovered (there are *always* unintended differences when something is re-implemented from scratch), the first couple of service packs issued, and ISVs given the chance to update their software. IT departments might want to delay Vista rollout a few months after its release, to give these things a chance to play out. I know after the long wait people will be eager to get their hands on the new version, but you might want to run it on a testing or sandbox system at first.
Cut that out, or I will ship you to Norilsk in a box.
That should be easy, SourceSafe just can't handle large numbers of developers or files.
Microsoft doesn't even use SourceSafe. I'm pretty sure the VS guys did a study and found the vast majority of SourceSafe users were people like admins or secretaries who were backing up docs and spreadsheets on their department server.
When I started at Microsoft, they use SLM (source library manager) which convenient was pronounced SLIME. This thing was horrible: it used file locking, wrote little temp files to "lock" directories, used your volume label as part of your checkout, etc.
For Win2000, they threw that away and bought Perforce's code, and modified it a little bit. It was branded "Source Depot", and was about 100 times better.
But back to your question, SourceSafe just doesn't scale. Try using it with 200 developers and a couple thousand files. It'll die.
It seems pretty clear from the article that its describing Microsoft implementing unit testing on a large scale, but trying to explain it in laymens terms. So they didn't have to "rewrite" everything, they just wrote unit tests for everything they could, and dropped other parts (WinFS) until they could get those properly tested. The part about "code jails" and all of that read right out of an extreme programming book. I'm suprised no one else picked up on this.
I wonder, why microsoft can't do what apple did to mac OS. That is, why can't microsoft take FreeBSD code base and build added features into it to create a robust OS ? They could also include hooks in it so that MSOffice and other software suites will run only in their OS like apple is doing to Mac OS.
This could make their job a lot easier and could get them more patrons for their OS.
But microsoft has always been good at making even simple things seem very complex.
Linux Help
for all things on Linux
Looking under the hood, the Linux development model is more organised than one might expect. Consider the parts that make up a Linux system.
Libraries and applications are typically managed by smaller teams, and even if people contribute, those contributions are reviewed. Accepting that, we only have to look at the big structure. Some observations about libraries:
The whole is a mixture of bottom-up and top-down hierachical control. To understand the dynamics, consider an individual project. At an early stage, the developers looks around to identify what is already done, and tries to identify reasonably stable, common, and well managed libraries which they can use. This is a very feasible thing to do due to open source licenses. They will then start from there, and do occational changes in dependencies throughout the lifetime of the projests due to new needs and changes in availability and quality of dependent parts. Sometimes, libraries are split out of projects by abstracting out identifiable tasks.
An important observation is that by maintainers of a popular project casts a vote when choosing dependent projects. The more important the project is, the higher weighted is the vote for the dependent parts to survive. When most projects thus migrites to a better library, the rest will have to choose to follow suit or to risk loosing ground due to a more difficult installation process. The distributors are the ultimate judges, though their power is limited by what software is available.
In other words, there is a semi-democratic system that organises a hierachical structure of componets, with no single central authority.
Microsoft got The Wall Street Journal to publish that free advertisement? That's incredible.
Look at MS's big challenge now.. They are a monopoly, they are not going to increase their market share any more, because they already own the market. Their challenge is getting people to stick with their stuff, despite the demonstrated long standing problems in security.
So, they throw in some tidbits critical to MS's past practices, because everyone is painfully aware of the problems they have had with security, viruses, etc. And they introduce our savior, Jim Allchin, who in a miraculously short amount of time, fixed all the development issues and got the company on track producing bug-free software.
Now, IT managers can breathe easy, assured that the next release of Windows will solve all that pains them, and will be well worth the high price MS demands.
This article is a great demonstration of why MS is on top. They have the clout to place a piece of propaganda in a national publication that will be read by a good percentage of corporate execs. That's innovation, MS style.
The key to how an individual perceives Windows XP is based on expectations. Those with low expectations generally think Windows XP is good. Those with high expectations realise it is not. The way to develop realistic expectations is to have an in-depth knowledge of the *potential* of software vs the current reality of software. Kids today who grew up on Windows 98 have low expectations and so they think XP is actually *good*.
For the record, even though I only develop in a particular branch of Longhorn, I do have access to the whole source tree.
The holy grail of software development (OK, one of the holy grails) for a long time has been code reusability. Specifically, how do we build software in a way that allows code to be reused in multiple applications, so we can save lots of development time. But, so far as I can see, we are nowhere near solving this problem, at least, not "officially"
Windows contains lots and lots of interacting components with lots and lots of APIs. This leads (for instance) to the well known problem that an upgrade to one thing breaks another. Why? Well, those APIs are complicated. Given even the best will in the world the specifications are incomplete, so a certain amount of "experimental programming" goes on when using them. The result is that usage of the APIs is very sensitive to changes in the API. Say you write an application A that uses a "reusable" component B. You read the API documentation, you code B, you test it, and it works. But it is quite possible that, say, you inadvertently use the API in a way that it should never be used in (you drive it beyond its "design parameters" in StarTrek speak). Later the component is upgraded, and it no longer survives your assault on it, and your application breaks. Just to repeat, even if everyone does their best, acts honourably, etc., etc., this sort of problem will arrise.
Now compare the Linux/OpenSource world. I've got two big advantages. First, if I'm in any doubt about the API then I can look at the code to see exactly what it does - and I can make a judgement about how far I can push it. Secondly, If I am not sure of a component I want to use (perhaps I'm not convinced it will be maintained, or maybe I know that I am pushing it too near the edge) then I can incorporate the code into my project, so that I'm insulated from changes to it (I'm not really talking here about forking, more like freezing). Of course, I'd be advised to feed back fixes and improvements to the originators, but I do have final control.
So, I'd like to suggest the Linux and OpenSource are providing a level code reusability that cannot exist in the closed source world. Sure, everybody depends on (say) GLIBC, and lots of people depend on, for example, QT or GTK+, but those are specifically provided as libraries and the authors are very aware they they are being used as such.
Regards
Mike
"I wonder if, once the kernel, KDE, and GNOME guys have to lug around twenty years' worth of backward compatibility, they'll be exactly like Windows... bloated, buggy, and insecure."
They do. man 2 pipe. That's not new. man 2 fork. That's not new. Read up on POSIX. That's not new. Read up the C stdlib. That's not new.
Nothing that has been implemented in a Linux distribution is very young. Most of it is so old, that Windows was just a copy of a program called QDOS bought by a young man named Bill Gates before an interview with a company that thought it could make money selling small computers in addition to its mainframe line.
Comments like this illustrate the idiocy of people who have no reason to comment on stuff. Microsoft, which is dominated be the business rule of not breaking compatibility for the sake of its money-paying customers, are not unlinke all Unixes that caused the POSIX standard to come about. The difference is that Microsoft is 1 company with 1 closed-vision of money, while the Unix and C interfaces were widely used, and became standardized through standard engineering practices.
I bet you're the same kind of person who thinks a desktop PC is poorly designed because it has RS-232 next to its USB ports. Good, well engineered software and hardware can change over time without ditching backwards compatibility. Linux is a great example of this.
You're either very ignorant, a troll, or an astroturfer. Either way, you did manage to get modded up, which reflects poorly on all the mods that touched your comment.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
They've been saying forever "Windows will never be secure without a complete rewrite." Could this be their chance?
If anything, Mozilla is the reason they're finally getting around to 'upgrading' IE to possibly make it a decent browser compared to Firefox.
"I filter at +6, and have yet to miss out on an important comment." (#822545)
Here's one - never having to hear "Ship it!". People working on OSS projects on their own time aren't generally being told, "you have to ship before Dec. 31st so we can get the revenue on this quarter's books", with no regard to whether that date is reasonable.
Actually, the large open source projects I've seen DO have pressure to ship fast. Although it may not be due the the quarter's books, there is a lot of pressure on projects to get things done and announce GA. When Apache 2.0 was originally released I believe many developers didn't think it was ready for prime-time, and they still shipped. As a result it took a long time for people to upgrade. Additionally, many important open source projects ARE backed (and essentially developed) by corporations who DO have books to worry about.
Actually, we can see all the code if we want to. It's really not that big of a deal.
This is actually a clever bit of PR on Microsoft's part. Since they have no fear of losing the installed base of WinXP, they can start bashing it to convince people that it is a piece of crap (not a hard task) and clear the way for proclaiming Vista to be the cure to all the problems in WinXP. This is just part of the effort to promote the widespread migration from WinXP to Vista, especially when the new features may not be enough to sell someone on going through the trouble of installing a completely new OS. Microsoft must also convince customers that it is dangerous and bad to stay with WinXP.
Microsoft has BEEN using automated integration and unit tests, for at least fifteen years. (I spent a year owning some of the unit tests for USER, back in NT 3.1 days.) Windows has one of the best systems for allowing modular code out there-- yeah, we know about DLL hell, but it's there because lots of programs *do* use the same shared libraries, and with the versioning stuff in Win2k and later it's mostly dealt with. Predetermined interfaces... gawd. COM was developed precisely to allow that, and it's been working its way steadily deeper into the OS over time.
Microsoft's existing dev practices would allow them to produce something the size of Apache, or PHP, or OpenOffice, with no trouble; they needed to do something better because the project they're taking on is so much larger.
Here is the executive summary of the comments posted to this story so far, written in the first person:
I've never worked on anything even approaching the complexity of the Windows OS, but I know exactly how to do it, and I can do it better than Microsoft. Windows has obviously failed, and all the alternatives are obviously better. Despite the fact that Linux is only a kernel, not a complete OS, and faces nothing near the problems a project the size of Windows faces, I'm going to make the invalid comparison between the projects anyway in an attempt to whore up a few mod points. Oh yeah, and everyone Microsoft hires is shit - only OSS coders have any skill.
I think that covers it.
Slashdot - where whining about luck is the new way to make the world you want.