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."
Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program.
This really explains a lot...
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
Linux is *not* user friendly, and until it is linux will stay with >1% marketshare.
/tmp or the installer will dump core. After the installer is done, edit /etc/X11/XF86Config and add a section called "GL" and put "driver nv" in it. Make sure you have the latest version of X and Linux kernel 2.6 or else X will segfault when you start. OK, run the Quake 3 installer and make sure you set the proper group and setuid permissions on quake3.bin. If you want sound, look here [link to another obscure web site], which is a short HOWTO on how to get sound in Quake 3. That's all there is to it!"
Take installation. Linux zealots are now saying "oh installing is so easy, just do apt-get install package or emerge package": Yes, because typing in "apt-get" or "emerge" makes so much more sense to new users than double-clicking an icon that says "setup".
Linux zealots are far too forgiving when judging the difficultly of Linux configuration issues and far too harsh when judging the difficulty of Windows configuration issues. Example comments:
User: "How do I get Quake 3 to run in Linux?"
Zealot: "Oh that's easy! If you have Redhat, you have to download quake_3_rh_8_i686_010203_glibc.bin, then do chmod +x on the file. Then you have to su to root, make sure you type export LD_ASSUME_KERNEL=2.2.5 but ONLY if you have that latest libc6 installed. If you don't, don't set that environment variable or the installer will dump core. Before you run the installer, make sure you have the GL drivers for X installed. Get them at [some obscure web address], chmod +x the binary, then run it, but make sure you have at least 10MB free in
User: "How do I get Quake 3 to run in Windows?"
Zealot: "Oh God, I had to install Quake 3 in Windoze for some lamer friend of mine! God, what a fucking mess! I put in the CD and it took about 3 minutes to copy everything, and then I had to reboot the fucking computer! Jesus Christ! What a retarded operating system!"
So, I guess the point I'm trying to make is that what seems easy and natural to Linux geeks is definitely not what regular people consider easy and natural. Hence, the preference towards Windows.
I think the poster meant "principals," since it's well known that there are no "principles" in Redmond.
>>And start over they did
Yes, but 'stitching' some other/different/more programs together.
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.
Well, that would explain the long wait, but what about the features dropping?
--
Superb hosting 4800MB Storage, 120GB bandwidth, $7,95.
Kunowalls!!! Random sexy wallpapers (NSFW!).
Hosting 20G hd, 1Tb bw! ssh $7.95
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.
It makes it hard to write something compatible (or outright clone) the product.
Also, when you want some competitior's product to run badly (which Microsoft is famous for) it is easy to find something that the competitior's product do -- but few other programs do. Then you introduce a small "bug" in the next version of Windows...
Sure, development needs extra engineers and takes longer, but if you are a monopolist -- you have to afford doing things like that.
Karma: Excellent (My Karma? I wish...:-( )
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
Microsoft has to do what apple did with MacOS X. Microsoft has to put it's operating sistem in to the trash and get a real unix like OS. Maybe they can use BSD as a start, it's stable and it's free.
My city: Barcelona.
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
Will you please stop posting this god-damn troll?
I've read this text too many times lately and any points you may have had are extremely out of date.
I personally find it sad that you have nothing better to do than continually post this tripe.
Loser.
>>As engineers began cooperating and Mr. Srivastava's team worked overtime to refine the tools, the quality of the code flowing into Longhorn began to improve.
Lo and Behold, now 1 + 1 started resulting into 2. and that was just the beginning. When they tried, even 1+1+1 started resulting into 3!! This was something even Google (with its 'internet softwares') had struggled with. That, my dear friends, was the corenerstone in the developement process of the pig^H^H^HVista.
Someone has just published all these bugs!
throw new SuccessException("Sig read successfully");
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.
Now you don't need to wonder anymore why Windows is so buggy and insecure. Even Vista is already so bloated that it doesn't even run on most PCs at any reasonable speed.
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.
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
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 not too much of a programmer, but I can concur at least on writing websites. It's really hard to get everything right the first time. Web design is just that, design. And software development has plenty of design aspects to it as well. And good design, by its very nature, tends to be iterative. An architect, or an industrial designer, they'll go through dozens, maybe even hundreds of versions of something. Lots of work, plenty of good ideas, they end up not making the final product, but the result is much better because of all that work. Of course, I'd imagine that even the most complicated of buildings is way easier to understand than the windows source code.
One time I threw a brick at a duck.
cowbody spaghetti code culture ... and what term would you use for open source software?
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.
Basically, they're after the system that Apple uses OSX development. Based on a strong "foundation" technologies like the Mach kernal, the Aqua GUI, the Carbon and Cocoa APIs, Apple has been able to crank out almost annually significant upgrades in OSX. It charges money for these upgrades, and most users willingly pay for them, because they're not just security fixes - each generation of OSX 10 has really enhanced the user experience.
Unless Microsoft wants to get in on the portable music business, Apple isn't really a credible threat. They've got a vanishingly small portion of both desktop and server markets and that doesn't show any signs of changing soon. It remains to be seen if Apple will use the opportunity afforded to them by joining the ix86 party to change that, but given their past pricing/positioning, that doesn't seem likely. Google? Yep, I'd be keeping a pretty close eye on them if I was Gates. Cheers,
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.
Is Microsoft's "cowboy spaghetti code culture" any different than the "cowboy spaghetti code culture" elsewhere? Most relevantly here, is it any different than the "cowboy spaghetti code culture" common in OSS? I see absolutely no sign of that. It's how programmers everywhere tend to operate when they know they can walk away from a mess instead of fixing it. Only the fear of being stuck with a pig, or some external kind of pressure (as at MS), causes 99% of programmers to design and code more responsibly. The other 1% do it because they know it's the right thing to do, but they remain a small minority.
Slashdot - News for Herds. Stuff that Splatters.
Interesting ... a couple of days ago, crazed press speculation on the MS restructuring had Mr Allchin marked down as a loser and on the way out. This excellent article has him as a quietly spoken hero who saved the day against the initial wishes of his boss, and who is now going at a time of his own choosing.
If Gates had had his way, according to the article, MS would even now be launching a 96,000-ton flying spaghetti code monster instead of a rewritten product that's based much more on Lego lines, part-supervised a guy who's into chicken teryaki. Funny how so many articles present Gates as "tetchy" or "frustrated". I wonder if a key to him could be something as straightforward as acute haemorrhoids. Perhaps on his incessant business trips abroad, Ballmer is instructed to search for the magic salve.
Las qué passoun
tournoun pas maï
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.
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.
If you thought that was bullshit. Please read this.
Before you blame me for an unwashed hippie zealot, please understand what my post meant. I don't want Microsoft to be replaced by Google or somebody else. I want a Free and Equal market, not Yet Another Monopoly.Quidquid latine dictum sit, altum videtur
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.
I wonder how accurate this article really is. It sounds like a very well designed FUD campaign: Everyone knows how bad Windows is, and the majority of people know nothing about Linux other than it is open source and developed by a decentralized group of volunteers around the world - each working on their own little part. Microsoft is getting ready to release a new version of Windows and needs a way to sell it. So what do they do? They blame all of the problems in Windows on a development model that sounds very much like Linux (at least the way the describe it), thus implying that a) Longhorn will be much better, and b) Linux must be just as bad as Windows and is going to collapse under the weight of disorganization - all that without even having to mention Linux specifically.
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.
>>>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.
I was going to say something about second system effect here, but it doesn't really apply to Microsoft. I can't think of any first system of theirs that meets the "relatively small, elegant, and successful" criteria... not more than one out of three, anyway.
To a Lisp hacker, XML is S-expressions in drag.
All i've seen from Vista is mostly cosmetic. When is Microsoft going to start pushing the envelope and eradicate the concept of windows. They are clumsy and hard to manage. I almost consider windows the equivalent of frames in the html world. Programs interfaces should be contained in a div type concept and presented in a webpage like format. Let the program interfaces flow with each other in order to optimize the screen space. Windows are so wasteful when it comes to optimizing screen space and it puts the burdon on the end user to organize windows. I want to see the line between the web and the desktop bleed together. Represent the desktop as DOM just as you do with html. Let the user customize everything through a javascript type language or through manipulating the DOM tree directly with the mouse. Get rid of the titlebar buttons too because they take too much time to get to.
Here's another concept: remove the start menu. It sucks to move the mouse to the corner of the screen each time to access a new program. In FVWM I have it so I can just right click anywhere have have my programs popup. How about some type of context sensetive mouse menus. These mouse menus should be circular, not linear down and the cursor should lock to the directional arrows pointing to different actions. In this case, if your quick with the mouse, doing things will feel like mouse gestures, but for those who are slow can actually see the menu listing. These menus should be smart to have a basic understanding of what your are trying to accomplish. For instance, when editing a text document there aren't too many things people do with text. Perhaps make it bold, underline, change font size. It is pretty limited and the menu's can adapt to the why people user a certain program. What we need it an intelligent interface.
The goal of all of this is to minimize the amount of time the user is wasting doing trival things and allow the user to be more productive.
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
"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.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Interesting article
but damn
hard to read
because it was written
by a moron
that doesn't know
how to write
(I've got a B.Sc. in Comp. Sci from the 1980s - take this comment with that in mind that I'm and old skool type)
The "Second System Effect" is a term coined by Fred Brooks to indicate that the second system you build is usually a horrible monstrosity of things that you wanted to put in the first system but you didn't have time.
http://en.wikipedia.org/wiki/Second-system_effect
I'll wait for your third re-write, thank you very much.
TDz.
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!
Everyone has always known Windows was a POS even though MS beat their collective chest over it. So, they were hiding the truth about it all along. I wonder if they will send a press release, "We LIED to you about the quality of Windows. We've now rewritten it from scratch. So, please forget all the bad stuff that we did in the past and dole out more of your sweet moolah for it like the idiots we know you are. My aren't we innovative!" I wonder if they are still going to include the profanity in it.
Even if these revelations are true is the fix any better or is it just more patched together pasta code? I mean it's the same culture using ostensibly the same tools and processes.
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
Great, this dickhead gets +4 for spouting off about things he knows nothing about, and the four people telling him he's wrong and why, get nothing.
Or What? That's what the article is raving so much about - the whole mess is getting more modular. Yeah, great. MSFT itself was stating that Windows was thought to be the most consistent platform in desktop computing, I wonder how they're going to stick to that principle.
Oh, and I'd like to cite one of my favourite quotes, because I consider it perfectly fitting:
"Those who fail to understand UNIX are doomed to reimplement it, poorly."
:%s/Open Source/Free Software/g
YTARY!
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.
It is. I have worked in windows for the last 5 years. This article must have been either suggested by Allchin or Srivastava to save face. What caused the perceived longhorn delay was not so much a necessary rewrite, but our managements tendency to rah-rah the shipdate. The message has been 'we will ship next year' every year since we started. At some point Gates put the pressure on an called the bluff. And to save face, this cover story was invented and we had to port all longhorn changes into a new codebase ('the rewrite'). Srivasta just caused more problems by introducing pointless code correctness tools - like lint, they create huge numbers of false positives. They didn't improve anything, but overloaded everyone with lots of pointless bugs at a time when nobody needed that.
As far as development process goes, Windows has always had the state of the art process (number of engineers involved, coding standards, staggered repositories and build labs, targeted testing etc). The perception that windows sucks stems to a great degree from the decision to let drivers run in kernel mode, and the really bad driver code hardware companies churn out. Another thing we're fixing with longhorn.
Actually, for all the mess backwards-compatability in Windows can provide, what finally turned me a way from them was when I was trying to put a new application and they changed the API to the point where I had to do a total last-minute rewrite of the desktop client.
The server side was in Java, so it didn't change, but the much-touted SOAP interface used on the client was now so different that no amount of abstraction could have prevented a major rewrite.
Don't even get me STARTED on the days of the database API-of-the-week!
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
Way to lead the charge, sheep-boy.
So, MS is going to spend something close to $1B over the next few years to get Vista out the door. In that same time, Apple/IBM/Redhat will not spend that much money all together and will still have compeditive products -- maybe even a new killer application that MS misses because all it's best developers are creating an unnecessary OS.
I was reading an article in Wall Street about Microsoft falling behind in online market, and was annoyed at the journalist's choice of word: Loosely quoted, the journalist claimed that Google was "exploiting" the internet by producing software which they could deploy quickly and easily to all of their users.
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
It doesn't matter how many developers were/are working on a project. What matters is _how_ they do it, whether or not there's a thing we normally call 'architecture', or is it just what windows is: a bowl of spaghetti, developed by thousands of developers, without common understanding of the system design.
I won't tell for all open source software, but the examples I've seen are very well designed, which makes them very easy to work on by hundreds of developers without turning into that bowl of spaghetti.
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
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!
Tinderbox? Microsoft broke down and finally implemented *Tinderbox*? I'm speechless.
"Lawyers are for sucks."
- Doug McKenzie
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?
the first time you write something, it's always hackney'd
In The Mythical Man-month it's stated that the first release of software will have to be thrown away so you should plan your timetable accordingly.
Often the second design has too many things to deal with that it ends up a complicated mess..
.. and worked very well.
I've always written code with the basic idea that I'm going to to throw it away some day, it's always prevented me from overengineering something simple. I always keep the possibility of a rewrite open but never leaves any problems left undocumented.
It has worked so far
Quidquid latine dictum sit, altum videtur
A. Automated tests that cover these situations.
Write your program. Every time a weird bug crops up, solve it and write an automated test that makes sure it stays solved in future versions.
Re-write your program. Keep the old battery of automated tests. Use these automated tests both to measure your progress and ensure you don't make the same mistakes you did last time.
Automated tests are a superb means of encoding the bugs and fixes you encountered the first time around.
Don't be naive, this is nothing but a puffy feel-good marketing/PR release designed to make you think that the $$$ you'll be forking out for Vista is for more than just WinXP with a new look and feel and a tiny handful of new features. And to make you think that you're "on their right track" if you keep buying into Microsoft solutions. And to make investors think there is some sort of reform going on at MS. And clearly the marketing is working.
We heard the same lies when XP came out. Why do people have such short memories? Yet people really do think "new look and feel" = "rewrite". There is just no way MS will be rewriting any significant portion of it "from scratch".
Microsoft write quality code? I'll believe that when it's on my desktop and I'm using it and I can TELL that it's good. NOT two years before the time from reading one carefully crafted manipulative marketing press piece.
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
I interviewed there last year, and I walked away with a feeling that M$ was overrun with very smart code-jocks stuck in the ways of the past. They were still doing things that were effective for a small and fast moving company but not effective for a large organization.
One of the few things they seemed to have gotten right was Microsoft Research.
Everything else was being pasted together half-hazardly. Whenever a new product needs to be build they just put a call out to see who wants to work on it, and if the project has priority, they have the luxury of internally hiring the best coders. Observe that knowing something about the project is never a requirement. So they have people working in OSes who have no idea about advanced paging algorithms or have never studied old style monolithic-but-highly-secure mainframe OSes.
It is still a great place to work, and the fact that there are so many problems makes it a boom for a talented manager who can set the ship straight.
uh.. was your professor fred brooks? ;)
That might work for small college projects but the real world is a different place.
In fact, the real world is many different places. It all depends on exactly what kind of code you're writing. If it's a project with many technical challenges relative to the code size, such as an application that uses a new algorithm or a new protocol, it's probably good advice. (A novel peer-to-peer client, say, or a new search engine.) In that case, your first code is really just an experiment, an exploration into the problem. Once you've bootstrapped your code enough that you can confirm that the approach works, you're ready to write the real code. You know, the code that has to be correct, efficient, stable, extendable and elegant.
You shouldn't run into second-system effects because you're still just trying to achieve the first system. The only risk of that is in trying to write your protocol to be more general and handle a wider set of cases than it really needs to.
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.
It is really funny to watch how the history repeats itself.
:)
I remember reading slashdot back in 2000 when it was full of doom's day predictions about how Win2k has 65,000+ bugs, Microsoft will never manage to finally release it, etc. (man I wish I could dig up there articles).. Now I'm seeing comments that Win2k is the best Windows ever made
Ok... I see the future! Here is Slashdot 2010:
"Ask Slashdot: Windows Vista was the best?"
"New Windows is delayed again..."
"Linux On Desktop is 5 years away?"
So what should they do then? I have no idea.
;)
write a progam that can understand the intricacies of windows and write a better version of the os. software will be writing software someday, just wait til your coding job is outsourced to a computer
What's amazing is not only did it work, but it worked for so long. Most of us in the business have known for years that MSFT was fielding sub-standard products. We'd see the same mistakes cropping up over and over, unless it was a product MSFT bought from someone else like Visio or SQL Server.
If anything MSFT's process was even weaker than most OSS projects. Try throwing buggy code at the Linux base and see how far it gets. Not only does bad code not get past the door but you'll probably get bitched at for wasting people's time by turning in such a piece of crap. The less automated version of what Allchin put in place.
Overall I think this change will be good for Windows and MSFT. It took getting their ass kicked by Google, Apple and OSS to open their eyes but give them credit for listening, even though Gates fought the change. Vista might actually be a big improvement.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
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
"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."
It's great to see confirmation of that. That practice accounts for the sloppiness of Microsoft programs. Apparently Microsoft creates extremely sloppy code, then fixes bugs until they decide that they can squeeze acceptance from the customers.
"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.'
That's another interesting confirmation. It's "obviously" Mr. Gates' role to know what his company is doing and prevent a crisis like this. I've often thought that he was mostly absent from Microsoft management since he took the title, "Chief Software Architect".
"... the growing threat from rivals such as Google Inc., Apple Computer Inc. and makers of the free Linux operating system."
Business writers write a lot of nonsense about computing issues, and that's nonsense. Microsoft has always been its own worst enemy. The competitors are not the reason Microsoft has a bad reputation.
"In recent years these companies have been dashing out some software innovations faster than Microsoft."
More nonsense. What Microsoft innovations? I can't think of any.
"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 employees, in my opinion, have always helped business writers write nonsense by giving interviews in which they tell the writers nonsense. It's not "a little bit" different. It's a completely different situation. Microsoft's situation is one of extreme self-destruction. For example, Microsoft tricked customers into buying what it called "Software Assurance". Now, the Microsoft faces enormous resistance from customers because they got almost nothing for their money.
"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."
That is complete fiction, entirely invented by the writer, based on what he thinks should happen. I've never seen any evidence that Microsoft was interested in a 1.0 version that was "generally bug-free". No new operating systems are necessary. Most customers will be happy with a "generally bug-free" Windows XP Service Pack 3. They won't need or want to buy another version of Windows.
Cover Up: "In 2001 Microsoft made a documentary film celebrating the creation of Windows XP, which remains the latest full update of Windows. When Mr. Allchin previewed the film, it confirmed some of his misgivings about the Windows culture. He saw the eleventh-hour heroics needed to finish the product and get it to customers. Mr. Allchin ordered the film to be burned."
Windows XP was not finished when it was released, in my opinion.
"The mass of patches and agglomerations that made up Windows turned it into an easy target for viruses and other Web-based attacks."
This is the first time some serious truth has found its way from Microsoft to the business press. My guess is that going public represents an attempt by Mr. Allchin to force the company to change. It's a revolt made possible by the inattention of Mr. Gates and Mr. Ballmer.
In late 2003, Mr. Allchin called on the help of two men. The first was one of Microsoft's best-known "shippers," people known for their ability to turn around troubled software pro
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?
The more Microsoft make itself sound like Linux but better...
.... Bull Shit.
No matter how you look at it, how you read about it, how you think about it, there is one things for absolute certain.
The core of the mindset at Microsoft is simply this "make people need you"
And the only way to do that is to NOT provide the people with the tools to do it themselves.
Though it has become common practice in the computer industry so as to insure or at least carrot an upgrade, the more you reinvent the less you genuinely innovate.
Microsoft is not an innovator at all, they are first and formaost a marketing company following in second place is their legal team used to help guide and defend their efforts at controlling the software industry, even going as far as sacrificial acts the, like playing chess, bring them greater returns than not sacrificing their own pawns. If fines for being caught doing illegal dealings, is considered by them as part of the cost of doing business, then what business are they really in?
Genuine innovation is not even in third place at Microsoft, as that place is held by their property suppression and buy out department. They don't Innovate, they simply buy what innovative property they can from others and then claim they developed it.
This article, how can it be anything more than marketing hype, as some readers have noted the unrealistic claims of writing from scratch. So.... given its comming from such a company with a growing criminal record.... And can you imagine Bill Gates still saying he's the little guy? Well he has recently told that lie... again.
The really sad part is that the majority of computer users today are not intune enough with the facts of development to enab;e them to see past this otherwise obvious marketing hype..... of we are juist like linux... but better
It doesn't matter so much how you create and test code, but rather what you code into your programs.
Are you coding in overall scope user stupidity, inherent manifested user frustration or some other debilitating mentality towards the end users?
A user can do no more with a program than the inherent mindset of the programmer(s) creating the program has provided.
Sell a man a fish and you feed yourself for a day, but if you teach him to fish.... what are you going to eat?
Thats one mindset... many of us know another one. Unfortunately the general programming industry doesn't seem to know it.
Software will genuinely be free when, and only when, it is easy enough and common enough to create it as you need it.... like math.... and using a calculator...
When that happens, proprietary software will be a rare thing. But from a POV of such an environment.... how does it make this article on MS dev practices look?
They should split it into modules small enough so one person can understand one of the modules completely.
Linux is not Windows
There are two major ways to write software. One is based on design patterns and a concept, an architecture. The other is based on try and error. On coding without planning. The result is, that after some development cycles, improvements and addons. The software gets inmaintainable.
After 30 years MS accepts now that software development needs a plan (not a business plan) , a concept. As real methods for such plans are available since the 1990th they are pretty late in starting to use them. But on the other hand in the OSS-scene is not using such methods either.
If consumers buy the paper that does the good reporting, other papers will follow, even if it conflicts with a parent company or advertiser. If consumers buy the same Gannett/AP fluff no matter what they print, the other papers will follow that. Unfortunately, most media consumers want pretty pictures, polls, and horoscopes.
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.
Wow. We at Slashdot are all humbled and amazed by your impressive resume of "I wrote a MUD". Please offer us more of your industry-applicable advice.
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.
Skynet? OH SHI-
That is unbelievable, it cannot possibly be true.
How could you start with millions of LOC badly structured code and organize them into a bug-free new version of OS in a year? What tool would Mr. Srivastava provide to do that, short of SkyNet?
The story is either a fabrication or revision of events because what it outlines is impossible. It must be part of a marketing campaign.
If this is true we should be able to tell via two indicators:
1. The final version of the operating systems will be smaller. We all know the effect of patching software and the corresponding bloat.
2. All those betas that are install, and all those developer releases will have to be revoked, as they are now irrelevant. Unless of sourse they employed an object oriented approach and the interface remains the same. This is not credible, or else they wouldn't be rewriting the OS.
If these two things turn out to be the case it would indicate that the article is true. My gut instinct - WTF? Can the advertising, noone buys the shit. The delays are because of the bloat already endemic, and - as they say - it wont happen over night.
...but it will happen...
It is true that Microsoft continually makes mistakes of gargantuan proportions. Think about the browser or streaming. But the one good thing about MS is it's ability to turn a huge ship quickly. Think again the end result of the browser war and streaming (IE and WindowsMedia) currently dominate their respective marketplaces. MS ability to do this is part culture, part capability and mostly money. It has a culture capable of change and self evaluation - something IBM was sorely lacking in the 90's (think OS/2 - they were still coding when they had already lost the market to windows). It is a great marketing organization and most importantly it has a war chest that can sustain huge losses before ultimately winning. But here's the catch to it's new development efforts. MS is moving into uncharted territory. No other company in the world has ever had to deal with an engineering team the size of MS. One might argue that the terrorist / cell-ish nature of open source development is better suited for large scale development efforts simply due to the challenges described in the mythical man-month. IMHO, all the money in the world does not cure those problems. It's kind of like poetic justice as MS' greed and phenomenal success has put it in its current predicament.
Lightspoke Web Based Database
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.
According to the timeline given, VISTA coding began around August of 2004 and the first trial release was a year later.
In other words, a complex operating system was developed in under a year and is slated for release at Christmas, a mere 18 months after its inception.
One of the FUD attacks from Micosoft against Linux was that Linux was 'immature', even though it had been under continual development since 1992. If over a dozen years of development doesn't qualify for maturity, certainly one year of development is the dictionary definition of immaturity.
Will SOHO users really want to roll VISTA out into their server rooms and desktops? I doubt enterprise users will.
Running with Linux for over 20 years!
Mach hardly could be called a strong "foundational" technologie... its allmost as ugly as the linux kernel.
When offered "only" $40-50k, they should think a bit more carefully on why the MARKET has fallen to this level. Perhaps, just maybe, programmers need to think about how to compete with a cheaper resource pool in order to make themselves worthy for higher pay. The dot-com bust destroyed parts of the profession and that simply won't change. All sorts of engineers get paid diddly for what they actually contribute. All sorts of professors and teachers get paid diddly for what they actually contribute. Tough. Welcome to the market economy, where prices are developed democratically.
They should split it into modules small enough so one person can understand one of the modules completely.
I would say they did. I have worked on projects like that before, unfortunatly what happens is if you dont have enough people grasping the entire archetecutre you end up with each module king of going their own way.
We termed this code "ravoli code". Each small chunk is well wrote, concise and serves its purpose well. But the individual ravoli's do not work well together.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Please excuse the bugs, it's a first generation product. But version 2 is coming soon!
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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.
Seriously, Microsoft should've purchased BeOS from Palm, and used that as a base for Vista.
"I'm not a cool person in real life, but I play one on the Internet". Galley
this is exactly what this article is. Google and Linux are gaining programmer mind-share so to counter this, MS has to try and *show* developers that they can be as cool as the new kids on the block. It's mutton dressed as lamb, it's an old hooker with new mascara. It won't fit, it don't work. Why? Allchin is facing the sack next year. QED.
Patriotism is a virtue of the vicious
So, we have a bunch of chair-throwers and book-burners at the top tier of M$. Not surprising they keep getting beaten up in the courts... "A fish rots from the head down," indeed.
(*Anyone tempted to reply, "it's a business, they can do what they please," has missed my point, so don't bother.)
you had me at #!
Here Microsoft repeats their marketing mantra with Vista as their championed solution. Never mind that the original Vista code was developed in the same manner as previous releases, and that it internally has the same bugs/glitches/features. Somehow the new development management process will structure that bad code into good code.
I find the story to be unbelievable. I think WSJ was sucked into this story as have so many industry publications in previous Windows releases. WSJ should be embarrassed by both their technical lack of understanding and their marketing naievete. A little background investigation of this story would have revealed it for what it is: the leading edge of a marketing campaign to push Vista and obsolesce XP.
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'm just hoping that this version of windoze(visdoze) will be fully compatible with m$'s fat32 file system, the 32GB size limit in XP is an massive annoyance, and it's sad that Linux is MORE compatible with an M$ file system then M$'s own OS.
The article is full of talk about building Lego like application which to me sounds like it can only be implemented by building on the concept of Design Patterns, especially well designed Interfaces for allowing modules to communicate with each other. As usual, it appears Microsoft is just following the footsteps of smaller, nimbler companies...
Every piece of software starts with a clean, elegant structure - in the mind of whoever created it. Over time some of their assumptions prove false, and more importantly, many of the "true believers" who originally engineered the system move on.
...it became harder to strap new features onto the software since new code could affect everything else in unpredictable ways.
FTFA:
The problem is a communication problem, not between programmers (nothing can really be done about that since they come and go) but between different parts of a complex software system. It has to do with data dependencies, not only at the program level, but also at the system level. It's a matter of the left hand not knowing what the right hand is doing. The problem is proportional with complexity and it affects the entire software development industry, not just Microsoft. But is does not have to be that way. There is a solution, one which, unfortunately will require a fundamental rethinking of software construction. It's never too late to retrace one's steps. See my site for more.
Here is a UML diagram of Windows Vista including the new Human Computer Interface
[Insert pithy quote here]
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.
By late October, Mr. Srivastava's team was beginning to
automate the testing that had historically been done by hand. If a feature had too many bugs, software "gates" rejected it from being used in Longhorn. If engineers had too many outstanding bugs they were tossed in "bug jail" and banned from writing new code. The goal, he says, was to get engineers to "do it right the first time."
All in all, the description sounds a lot like the Debian QA and build processes; automated builds, bug rates oncontributors and actions on contributors who bring in too many bugs.
"Everything is adjustable, provided you have the right tools"
>Mr. Srivastava had his team draw up a map of how Windows' pieces fit together. It was 8 feet tall and 11 feet wide
Twenty years of Windows, and they had to "draw up" that map instead of looking it up in their design documents. You're right that the complexity might be necessary, but reflect on how they don't understand the workings of their core product.
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.
When you rewrite something, you lose years of cumulative bugfixes
Shame that version 1 wasn't rewritten before release then, many of those bugfixes could have been caught I'm sure.
Never Rewrite? Sometimes. However when the code is too crufty, too much dead wood, many twists and turns, it can help to take the healthy stuff, burn down the rest and start afresh. However rewrites of complete large projects are a long term thing, but worth it in the long run. Take Firefox, Thunderbird, Mozilla. The only mistake they did there was not realise it was a long long term project - they should have kept the old code 'competitive' for a couple more years, if not putting too much effort into it.
And not doing rewrites makes even less sense when you are talking about modular code. If a module is clearly broken and you don't understand it, and the design is clear about how it operates, it can be quicker to rewrite the module - and you have the old module as a reference. This works best if you wrote the old module too of course, or if the old module is at least decently commented within the maze of twisty code that you are fixing.
The time and cost considerations of rewriting can sometimes be better than the time and cost to fix and upgrade an old system as well, especially if the old beardy hacker who wrote X in their language of choice has gone to pastures new and no-one else really knows that language. Say you had a massive website backend written in Perl that needs a complete overhaul - better to rewrite in something more modern (e.g., JSP with Struts or Tapestry, or any of the other web application framework languages) or to spend time modifying step-by-step the old codebase?
The experience is still relevant however, and for all of you young'uns out there, writing a MUD is a good side project as it broadly covers a lot of areas - networking, databases, parsing, AI and more, whilst not getting you bogged down in user interface minutae. You can also grab old circlemud level definitions and so on to allow you to concentrate on the engine.
A good route: Text Adventure Engine (parsing, single player aspects, database perhaps, simple AI) -> (new code) MUD (networking, more database, multi-player, better AI) -> (new code) GraphicalMUD (interfaces, etc). The latter should have excellent parsing, with good database, AI, networking. Then last step - rewrite the GUI and any other modules you are still unhappy with. That way leads (slowly) to a solid codebase you are happy with, and not a lot of written once and patched mess that you aren't happy with.
Professional systems integrators like Boeing handle huge projects like that as a matter of routine. Sometimes the projects get finished and work.
Part of the reason is an investment in scaffolding and test harnesses at each stage of integration. By the time you try to make the foo module talk to the bar module, both have been tested for interface compliance in the everything-but-foo-and-bar simulator.
Harder to replicate is Boeing's supply of fifty-something engineers who have Seen It All and intuitively wire safety margins into the right places of the specs.
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
I think the point of a rewrite, rather than a Version 2, is to reimplement your first implementation (version 0.1) to actually be decent now that you know all the issues that you are going to run into. In fact, the rewrite should start as soon as you know inside that the current design is wrong, or the code is too messy - by then you've encountered the worst of the issues in that module of code.
... well, that is what marketing exists for :p
What this rewrite should get you is the Version 1 that is small, elegant and relatively bug free and maintainable.
Then you can worry about the Version 2 feature bloat. Hopefully that rewrite at the beginning will do something to ensure that really bad second system effect doesn't happen. If it does
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.'
Excerpt: Microsoft Dictionary
Complex (km-plks, kmplks) adj. - 1. Patched and rewritten multiple times. 2. Code functioning despite being grafted onto a framework not originally built to support it.
syn: sloppy
ant: secure, logical
This isn't about the second design.
This is about the first design, reimplemented decently now you know what the issues are because you've run into them. The post above yours states that the Mythical Man Month also says this is a good idea.
That's why old software engineers should be paid a lot - because they will have encountered so many first implementations they can avoid the most common issues that lead to requiring a rewrite - meaning their first implementation is more likely to be good enough to not require rewriting.
FTA:"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.'
.Net applets all of which Paul Thurrot and Microsoft made huge media announcements about, and the way the betas looked incredibly similar to Mac OSX Tiger in both looks and functionality (the spotlight copy, the isync copy, the installation authorisation copy), my guess is that Longhorn was mostly redone because Bill Gates, Jim Allchin, Steve Ballmer and co. were so fucking worried about losing 1 or 2 measly percent of their market share that they decided to copy as many features of OSX as possible.
It may be true that they had engineering problems that made them restart Longhorn, but, given that Microsoft's Mac Business Unit would have seen the early betas of Mac OSX Tiger by then, and given the way that the Longhorn early alphas looked before Mac OSX Tiger was announced, with that craptacular huge sidebar on the right hand side of the screen with the Longhorn clock and the ability to host
In other words it would have gone like this:
"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 fucking ugly, and OSX so good, with Windows users switching in droves, that they would never be able to sell Vista unless it looked and acted like Mac OSX.'
in this case, monopoly is economic jargon - a concept that fits into a larger, academic model. Monopolies, as your 'real people' would define the term, don't exist in the real world. In fact, I would go so far as to say that it's a childish usage of the term. Real men (and women) don't use words they don't know what mean. This particular word is one where the naïve understanding is blatantly dense. (Possible reasons for this statement include: A) The word is used a lot in media, B) The naïve meaning doesn't occur in the real world (even in Puritan Scandinavia with their Governmental liquor monopoly outlets, it is quite easy to find other wine/spirits-suppliers), C) Nonexisting things don't receive much focus in serious news.)
Fuck the affected nonchalance of mediocrity.
And yet in the real world, Apple has rewritten its OS a couple times over, and particularly so with OS X.
Which is why it feels like a tightly-designed, polished, modern OS, and why Windows 2K/XP feels like a confused mess of details and half-arsed hacks slammed together.
There is a very visceral difference between the two GUIs, let alone a quality difference between the underlying code.
Microsoft must start from scratch, wholly breaking backwards compatibility, if they wish to compete with OS X and the Gnome/KDE BSDs. (Linux, I'm afraid, is just as spaghetti-coded as Windows.)
--
Don't like it? Respond with words, not karma.
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.
You mean my know nothing boss is actually following in the footsteps of Microsoft?
I didn't realize he actually he knew what he was doing all these years
"Oh, you hate your job? There's a support group for that, it's called everyone, they meet at the bar."
Sixty percent of the time, it works every time.
Well, the problem that MS is having is that even if they had designed windows well from the beginning, its purpose is in many ways different now. For example, a single user environment vs multiple users. A stand-alone machine vs. one connected to the internet all the time.
I'd hope that they're not just taking messy code and rewriting it in a neater way. I'd hope they're realizing that some of the design decisions they made in the first place were wrong, or are no longer valid, and replacing it with a better system, not just prettier code. Just because code still works doesn't mean it's useful.
I think backwards compatibility and legacy stuff is a huge weight around MS' neck. There are lots of practical reasons for them to support all that, but also plenty of good reasons for them to just cut the chain and move on. Apple did that with OSX, and it's worked brilliantly for them.
One time I threw a brick at a duck.
So they could be working on a project as a small group, spewing something that's useless crap to everyone else. But they choose not to.
Sounds like plain and simple good engineering to me.
"Plan to throw the first one away."
-- Fred Brooks, _The Mythical Man-Month_
It is, of course, important to understand the reasoning behind the quote. The book, while terribly dated, is still worth reading.
I understand this is snarkiness central and making snotticisms is sometimes more important that actually thinking but if you have ever tried to shift an entire corporate culture, organization and all of the underlying processes you'll discover that statements like the Doctrine of Allchin are generally whitewash. I'm sure the powers that be in Microsoft believe in their new world and I'm sure that the underlings that report directly to them do as well. Beyond that, at the layers of the organization where the work gets done it's nothing like that. They'll have the same change control the same management metrics and so on.
This is about marketing not programming you idiots!!!
Front page of Wall Street Journal every high executive reading this article saying Microsoft will be better than ever!!
Saying We Fixed our problems!!!
Open Your Eyes!
This propaganda is what microsoft has always been good at - creating a feeling of accomplishment and moving forward when nothing has been done!
This isn't exactly what the Tragedy of the Commons (wikipedia) refers to, but the parallels are there. In this case, Operating systems and media distribution are the commons.
In relation to this story, MCSFT may have seen the light concerning the quality of their software, but they are still doomed to failure (I should have such failure!) because they cannot hold onto marketshare by suing their users.
Actually
"In late 2003, Mr. Allchin called on the help of two men. The first was one of Microsoft's best-known "shippers," people known for their ability to turn around troubled software projects. Windows veteran Brian Valentine had a reputation for booming motivational speeches, beer bashes and stunts like showing up to work functions as Elvis, the Easter Bunny or even once a hula girl with a coconut bra."
Now we know how windows is built. Explains a lot.
"We are all geniuses when we dream"
- E.M. Cioran
... as the latest Microsft re-org gives witness to, with Alchin taking retirement.
It would appear that the Beast has resisted the attempt to bring order into its chaotic development processes, and has ejected the foreign body responsible for attempting to bring Order into Chaos.
Gates will continue to be the ultimate micro-meddler, introducing inconsistent and disruptive features and promoting competition between coders instead of cooperative endeavors to produce quality code.
Besides, everyone knows that corporate bean-counters who purchase software don't give a hoot about the quality or usefulness of the products they purchase. All they operate on is pricing, feature lists (where a broken feature is as good as a working one), and what "everyone else is doing".
sure, if slashdot is so biased and anti-Microsoft, then why is your post modded up insightful and the gp modded down? liar.
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.
The comments on WinFS don't ring true either, they are called a pig but they just released a beta on XP.
Maybe it's like ReiserFS having trouble getting integrated into Linux kernel.
Software is math and the first proof of a theorem is generally ugly.
Apples and oranges. The big difference with math theorems and computer programs is that a theorem still "works" perfectly even if its proof is ugly. All that matters is that the proof is valid. It can be a trillion lines long, but as long as it's valid, we can be certain that the theorem is true and that we can use it in our work.
Not so with a trillion-line program. A program that takes a million years to execute is as useless as a program that segfaults. It doesn't matter if the code is provably correct; if it's too inefficient, it's useless. A math proof can be inefficient but still "work".
Yes, I know, I know, a trillion-line math proof is useless if it takes a million years to verify, but we have automated proof-verification programs that could verify such a proof in, say, one year, which is at least tractable. All that I'm saying is that even though proofs and programs and conceptually similar, they're so different in practical terms that you really can't compare them.
"Feel a glory in so rolling / on the human heart a stone" --E. A. Poe, "The Bells"
I have to agree here.
"much sucessful OSS software is structured well".
It also has to have well documented code, and be designed so that you can get in and fiddle with a bit without spending two years understanding the app first. It also ought to have a community process that accepts well written code (with tests) from outsiders.
That's one issue I have with Open Office there - I am fed up with the "do you really want to save this
Another area of difference is decision making. companies have meetings then act on them; OSS projects have email discussions which get resolved one way or another -leaving a searchable archive of the discussion for later. Eventually those mail archives become the group memory.
OSS projects need to be open, to end users, and to develoeprs.
-steve
They've been saying forever "Windows will never be secure without a complete rewrite." Could this be their chance?
You forget the fiasco that was Copeland. A similar fiasco to Longhorn, except that Apple couldn't even turn the project around on its own, having to abandon it for NextStep.
-- "I never gave these stories much credence." - HAL 9000
Shrug, I was in school getting a PhD in math and my hobby was making a MUD. I decided at some point to code from scratch when the code I was using wouldn't do what I wanted and then started over, and my own program I wrote myself was about 90kloc over 3 years in my spare time...but it works fine. I realized at some point that I wasn't good enough to be a mathematician, but fortunately that game did get me my current job and I've also taken a couple of years of grad CS to actually learn more about how to program. So, I haven't been in industry very long but I have spent years learning how to solve math problems, and I'm a self-taught programmer. If that bothers you or makes you think I have nothing of value to contribute, please feel free to stop reading.
I think this is an issue of knowing that software is math and realizing that math is hard and you don't get the best result or proof in math the first time through. Sometimes if you want to generalize a result in math you need to go and use totally different techniques instead of trying to bolt things onto an existing proof. Solving math problems that nobody has solved before is much harder than just looking up a formula in a book and plugging in numbers.
That's why nobody will ever find a silver bullet for making software easier to make. The only easy math problems are ones you've solved before...so what happens is people learn to solve some problems that keep occuring in software and then build general frameworks for solving those problems and rearranging pieces of problems they've already solved before. They also figure out rules that people can follow to make it easier to track details of problems they're solving. That's why you have WYSIWIG GUI builders and automated testing tools and methods for naming things and such. Those tools and methods are designed to automate as much as possible finding solutions to problems you already know how to solve so you can spend less brainpower on those, and instead concentrate on the new things that haven't been solved before.
Best. Comment. Ever. Enjoy!
"The article is astonishing for its frank comments from the principles, including Allchin and Gates..."
You mean principals. Microsoft doesn't have any principles.
8-D
if i'm a grammar nazi, you're an illiteracy nazi.
An expression like "retarded shit" without motivating why it is a relevant characterization makes you look like a stupid teenager.
You probably want to hide that better.
Karma: Excellent (My Karma? I wish...:-( )
Now you know why Windows is a insecure, unreliable, unstable piece of shit that is too complex to use properly.
Big surprise. Only the Windows shills never had a clue.
The REAL point of this article is this: THEY NEVER FOUND THIS OUT BEFORE LAST YEAR!!!
Which means anything they've done over the past year WILL NOT SOLVE THE PROBLEM!
Now you know why Allchin is on the way out. He made the mistake of telling Bill something Bill didn't want to hear.
Which means Microsoft will go right back to producing spaghetti code as soon as possible.
Which is exactly what I've said a dozen times: until Bill Gates gets hit by a truck, MICROSOFT WILL NOT CHANGE!
Read my lips, morons.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
E X A C T L Y !
Thank you for describing the problem so succinctly. Now that hopefully everyone knows what the problems are, What are we going to do about it?
P.S. Sorry you felt like you had to post anonymously.
<sigh>
Heard any good sigs lately?
.. they use an automatic build LAB for years now. No-one hits F7 or cntrl-shift-B inside visual studio and 'Windows.sln' loaded.
AFAIK, building windows takes half a day.
Of course they didn't start over from scratch. They just switched kernels. They always develop 2 kernels next to eachother. Instead of working further with the XP kernel, they switched over to teh win2k3 kernel.
The article has further flaws: who announces a switch of core components AND a release date? You must be really out of your mind. They step into Mr. Cutler's office. Isn't he the lead designer of the NT kernel/system?
The article babbles along about MS wanting windows to be modular. It IS modular! very modular in fact. That same Cutler designed it to be modular.
No, not the best article a journalist could write...
Never underestimate the relief of true separation of Religion and State.
Because Microsoft's implementations could NOT force it on any of their customers (the OEM people who really buy Windows, NOT the end-user or the consumer,) and had some half-assed parallel-serial cable kludge.
And that kludge is all it would have ever remained as in the Windows world because it cost money to redesign the mother boards, money that the OEMs didn't want to spend.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
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)
So they admitted that they run their development projects worse than open source developers do, and that fact became public.
I call this sweet, sweet justice! Microsoft makes these claims about Open Source projects, and while they could point to, oh, say, OpenOffice.org as a perfect example of that, it is patently untrue of many other (X.org, Linux kernel, KDE) projects.
I've used Visual Source Safe and a couple of other source control systems. The argument to make is "should we use source control" and the answer is yes, it's one of the practices that separates a professional software developer from an amateur.
As for VSS, nice GUI, but the back end occasionally messes things up. The fundamental design of the system is that the back end is just a file share, the front end does all the work of interpreting all those bizarre little files stored on the server. So one bad client that crashes or goes haywire can mess the data store up for everybody. Very smart - not. The consequence for this is that if you run VSS on any significant scale, you have to use the test and fix utility at least once a week if you want to keep those files. Even then the database can get itself in such a mess that it cannot fix itself. If you're lucky all you'll lose is old version history on a few files. So if you 100% require the version history to be kept for ever, this is not the product for you.
Another consequence is that VSS cannot be used across the Internet like perforce or CVS. Subversion is the new shiny, try that.
My Karma: ran over your Dogma
StrawberryFrog
I'm am always amazed that people can look an a photomicrograph of a chip and ignore the complexity of the traces.
Yes there are now billions of transistors on a chis, but the real engineering is in the connections of all the transistors.
While the transistors, resistors and capacitors are essential to the functioning of the chips, their combinations into an IC is due to their connections in an IC.
They aren't glamourous, in fact they're existental, to components are conected or they aren't, but those connections are essential. Without them you're left with a few grams of dirty sand.
We have an internet built on disconnected computers when these very machines are marvels of connectivity.
Software is in the same disconnected state. We build modules but we don't build their connections, on the relationships between these modules.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
OH! I didn't realize that OS X was based on a rewrite of System 9. Thanks!
I'm just curious, how many times has Apple rewritten the entire OS from scratch? (re: "rewritten its OS a couple times over")
Wow! First time I've read the article and the entire /. 400 plus discussion in at least the last 5 years of reading slashdot daily. Many of you have truly excellent points. Thank you all. Appologies for the offtopic-ness. =)
Perhaps you should take a look at one of Microsoft's research development projects. It's a kernel written in C#..
0 2
The link will take you to Code9 a place where Microsoft allows the average person to see behind the scenes. Interesting stuff and a really GREAT movie/ concept OS!
http://channel9.msdn.com/Showpost.aspx?postid=683
Cheers
Smile.
Software is in the same disconnected state. We build modules but we don't build their connections, on the relationships between these modules.
Yes indeed. But it goes deeper than the module level. The problem also exists at the roots of software, i.e., at the operations level. Modifying a variable should be immediately broadcasted to every part of the program that depends on the variable. This capability must be an inherent part of the software construction tools and should not be left to the programmer. Ineffective communication is 90% of the software reliability problem. It is especially serious in legacy systems after the old programmers are long gone.
I said the kernel is written in C#..Mistake.
.. I think
.. cool .. http://msdn.microsoft.com/vcsharp/future/
The "kernel" is written in unmanaged code which would be C
The Managed Operating System is what is written in C#.
VEry interesting concept. I can allready imagine..
PS: C# and LINQ
PSS: SNAFU = Situation Normal All Fucked Up.
Smile.
I don't recall Microsoft ever saying they were "state of the art". Even so, most people always ignore PR spin. Not even Linux is "state of the art", and I've heard nobody say it is.
But it's not at all surprising to see a company promoting it's products, and at the same time criticizing itself internally. In fact, I think looking inward to find where you can improve is a positive thing. Companies which stop doing that, and instead promote an attitude of "Don't criticize or risk being fired" so that everything seems happy and cheerful... until it all fails, are a bad thing.
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.
Yes. And most times, that wrong process is the only process. Unless the project has a decent budget to hire business analysts and build storyboards, the only way to get concrete answers out of the client is to build them something that is a wild guess as to what they want, and use that as a means to solicit better specs. Extreme programming even uses this as an integral part of the process by having the client sit down with you as you build it.
Furthermore, most software packages evolve in step with the problems they are attempting to solve. Your specs describe last month's problems, not next month's, but sure as shit your software is going to be used to solve next month's problems. Programmers call this scope creep. Users call it real life. They're both right.
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.
Then go out and design some real hardware.
Then spend just a little time in a loony bin. (or a DMV, family court etc)
Then reread your hypothisis. You will be embarased by what you wrote.
BTW the brain has a 100% defect rate. Hardware has logic errors in proportion to its complexity.
Finally for you basic approach to work the average event handler would have to modify less then one piece of information. Otherwise you system would just lock up in cascading event handlers when you raised your first 'I did something' event.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
In late 2003, Mr. Allchin called on the help of two men. The first was one of Microsoft's best-known "shippers," people known for their ability to turn around troubled software projects. Windows veteran Brian Valentine had a reputation for booming motivational speeches, beer bashes and stunts like showing up to work functions as Elvis, the Easter Bunny or even once a hula girl with a coconut bra.
I'm sorry, but exec's should show a "bit" more professionalism than this crap. I wonder if the exec's at IBM's Poughkeepsie facility (where z/OS or OS/390 for mainframes) pull these stunts...
You probably haven't worked in a real team yet. Requirements often get formalized way after the code is written. Team members write the code the way they see fit, and not necessarily use your set of assumptions. Moreover, code is often written in parallel and then "integrated" into a feature, which means feature as a whole is often not compile until the last check-in (because chunks of code are missing) let alone polished and testable. So refactoring is a necessary evil. If you'd worked on anything larger than 100K lines of code you'd know this real well.
By late October, Mr. Srivastava's team was beginning to automate the testing that had historically been done by hand."
So, just curious, anyone know what tools they are using?
What you're speaking of is the waterfall methodology, that's how it was done for many years, and as far as mainframe COBOL programming, that's how it was done. Analysis->Design->Construction, and no turning back. Works great as long as you got the requirements correct and you didn't uncover new requirements as you designed, etc. But it's a rather rigid style, inflexible. Rational and the '3 Amigos' (Booch, Rumbaugh, Jacobson) and others are some of the folks behind RUP (rational unified process) and iterative programming. Also, Robert C. Martin is an excellent speaker and has many papers and talks on Agile Programming. But yeah, the "extreme programming" practices of folks like Torvalds, Alan Cox, Ingo Molnar, and the rest of the gang behind Linux is one of the reasons Microsoft has to work a little harder these days, and adopt more "agile" programming. And oh yeah, has nothing to do with language, C programming or VB programming or Python..
Don't get your advice from Joel. Or Fred. Rather follow professional's like Robert C. MartinJoel's example is Netscape. Now IE is eating Mozilla's dust, thanks to the rewrite.
This article is designed to generate interest in the magical next-gen tools behind Vista. The so-called 'software factory' approach, if memory serves...
. I mean, whatever happened to actually designing the application ?
That's something you did when you were dealing with certain types of limitations. In the mainframe days you had lots of limitations that we don't have today that required you to really plan out what you were doing (such as compiling required you to print up your program on punch cards, load the punch cards into the compiler and then load in the data followed by waiting for the response off a whole new set of punchcards.) Undoubtedly these limitations made for some amazing programming and discipline, but these limitations are gone, and there are plusses to that as well.
You must be astroturfing unless you bash Microsoft and/or praise Linux. Take your balanced opinion elsewhere - this is /., the home of the One True Way.
Slashdot - where whining about luck is the new way to make the world you want.
WinDev Win2k internal completion party, mid-December 1999.
Video stars Jim Allchin taking a baseball bat to a guy in a penguin suit in the parking lot.
Maybe head-stomping him too, not sure, it's been a few years.
Also shows him harrassing receptionists at Sun, Novell, and a couple other places.
BrianV throws swell parties though.
-AT
Working in a DevOps shop is like playing in a band made up entirely of keytarists.
Why is it good? Because if Microsoft starts producing better code and better product, it raises the bar for Open Source as well, leading to better code from everybody and the consumer wins.
If Microsoft learns how to build security into Windows as Linux does and Linux learns how to install/uninstall applications as easily as Windows, then everybody gets happy.
I have SuSE Linux 9.3 with the latest patches and latest (beta) version of Open Office. It fell over in a big heap every time I tried to save a document that contained graphics. Then it lost eight hours of my work that I was trying to finish before going on vacation. At that point I reeeeaaaalllly missed having MS Word. Maybe CrossoverOffice would be a good next purchase.
Tubby or not tubby. Fat is the question
Msoft has said that Linux and Open Source is like communism, so you must be wrong!
Karma: Excellent (My Karma? I wish...:-( )
Seems to me from reading the article that the problem is not so much that they have thousands of programmers each working on his/her little thing... the problem is that it is all supposed to be too tightly integrated: that it's not modular enough. Hence when you try to build. it crashes. The centralized cathedral cannot really help there. As the creature becomes more complex, so will be the tendency to crash. What is needed is a more modular design, each little thing doing it own little thing. Then you can have little groups of programmers doing their little thing independently, and building it and making work independently. All they need is proper protocols and standards so when needed the little bits can talk to each other... but centralizing cannot help, the code nightmare. The browser doesn't belong in tight integration with the core OS for instance.
Linux, by amateurs, for amateurs vs. Windows by professional for PHB's who don't know any better; I'll take amatuer. Amatuer used to be a compliment, call your wife a whore and see what happens.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Sure, they may build a OS under the ideal of `ground up` approach. But the fact that they are doing it so late in the game is not suprising.
OSX may be a pig but it will still outperform Vista in many aspects.
Just look at the system requirements for Vista and I'd love to see how OSX will just smoke under such a system.
Bring it on MS!
Also, with BSD and GNU/Linux moving forward in the server and desktop realm at a very fast pace. I don't think that it will be possible for MS can hold onto their market share. They will always have a place but not at their current numbers. Market dominance is a thing of the past for the Redmond ranglers.
MS knows that this is the last OS that they can make any serious profit margins on. By the time that SP2 of Vista is out, the alternatives will be even farther ahead in their offerings. The future looks promising indeed.
JsD
That's not to say MS's OS did not have it's own braindead limitations but they, as the market has shown, are more akin to a labotomy than a complete brain removal.
MS's limitations have manifested them selves into the need for a complete re-write to get it back to sanity. Remember only a fool embarks on an unnecessary re-write.
This is exactly why most OO advocates will push aggressive refactoring as a critical part of the software development process. If you're afraid to rewrite the kludgy parts, it's just going to get worse.
LOAD "SIG",8,1
Hence, imprisonment of criminals is not an example of a monopoly.
You're mostly correct with regards to utilities, except that in most cases they are what is considered to be a natural monopoly which most economists hold to be a special case.
Economists (of the neo-classical variety anyway) actually define a monopoly as a firm that can dictate the price to the market rather than having the market dictate the price.
Aside from which, as far as I can tell, by your definition Microsoft would be a monopoly because they are the only legal provider of Microsoft Windows, Microsoft Office, etc.
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.
By late October, Mr. Srivastava's team was beginning to automate the testing that had historically been done by hand. If a feature had too many bugs, software "gates" rejected it from being used in Longhorn. If engineers had too many outstanding bugs they were tossed in "bug jail" and banned from writing new code. The goal, he says, was to get engineers to "do it right the first time."
No wonder that Windows has so many bugs, becose there is little chance that the human mind can find a single bug in a single line of code that is made up of 500.000 lines or more. It is impossible. It is also clear that they way they where treating there engineers does not improve moral over there.
This is the start of Microsoft fall as the biggest software company on the planet. They may take one step forward, but they have already taken three steps backwards some time ago.
The problem is this: often, there are lessons you learn and insights that you gain through the process of implementing the system, and these lessons and insights were necessary for a good design.
Now, if you can give me some kind of formula to gain these same lessons and insights before I start coding, then I'd love to hear it. So far, the best idea is to just think about it really, really hard.
To put this a different way, you say to me, "If you are throwing away code, your design isn't good enough." But then I say to you, "I agree. But how do I improve my design?". There is no easy answer to this question. If there were, people would just do it. Sure, there are techniques, like doing class diagrams, doing prototypes in a high-level language, or writing detailed specifications. But hindsight is 20/20, and there are very, very few other ways to get 20/20 vision.
If the PC-software market would be truly divided between more than one dominant company, this would have several advantages:
The third point would really benefit, especially on the mental side. In the BBC poll yesterday on slashdot I sensed one pretty strong sentiment among the general public "it is good that MS is a monopoly, so that everything works together". I see this a lot in professional IT as well (e.g. developers in a all-Microsoft shop, and of course managers with MS or Oracle based IT strategies).
If the IT landscape was more heterogeneous people would be more appreciative for real interoperability issues, like open standards and protocol, and normal users might understand that not everyone uses the same wordprocessor when they send a document, or manager would understand that a product that claims to "do XML" is still as closed as can be.
Of course, on the technical side, we should make interoperability as easy as possible, on operating systems but also on other kinds of applications (e.g. office suites). Looking at all the differences between Linux distributions or desktops there still is much room for improvement, although it is not that bad considering how most big open-source projects is compatible with most Unix flavours. The important thing might be the mindset of such project that they work in heterogeneous environments and the willingness to make that happen.
On a final note, such a "utopia" certainly is possible. Look at the landscape for email, where open standards like SMTP clearly won with many alternatives for email-servers, clients etc.
Dude, OS X is based on a variety of the BSD "Unix" operating system. The code is all new. That's what makes for a rewrite: taking everything you learned, and applying it to a wholly new system that is so different, it is no longer compatible with the previous one. Any connection back has to be done via an emulator.
Apple did exactly the same thing when they jumped from the 680x0 CPUs to the PowerPC CPU: had to start with a new OS.
And If I recall correctly, just prior to the end of the 68k line, they made a last-ditch attempt to better things, with OS 7 being the new big thing, a significant reworking, if not a rewriting.
The only times Microsoft has made that leap is between Win3.1 and Win95, and Win95 and WinNT. Win2K and beyond have been bastard children, carrying a large load of luggage from WIn95. There were opportunities for fundamental design changes, but Microsoft has too much invested in its Office Suite to dare make an OS that's incompatible with it.
Best thing that ever could have happened to Microsoft would have been for the Justice Department to enact an effective wall between the OS and Office companies. It would finally have allowed the OS to compete.
--
Don't like it? Respond with words, not karma.
I can definately understand a student NEEDING to rewrite. Because they wouldn't have a clear idea of the problem. Once you've written a few bombs and learnt from your implementation mistakes, you should be able to avoid them in future and you certainly wont need to rewrite everything again.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Now, good bye. Talk to me in a few years when you've left high school.
Karma: Excellent (My Karma? I wish...:-( )
The article is so short on detail that it invites suspicion. I'd like to know what actually was the architectural problem behind Windows...and what was actually spaghetti code, and above all, what was there Windows 3.1 code still doing inside of Windows XP when we were told that all went away with Windows NT.Yes there is a need to rearchitect from time to time but this sounds to me like MS discovered that middevelopment through insufficient planning. Now they are going to rewrite everything from scratch? And what exactly are they automatically testing anyway?
Something doesn't add up. I seem to remember that with Windows XP, they rewrote Windows from the ground up. And with Windows 2000, they rewrote Windows from the ground up, and Windows NT, they rewrote Windows from the ground up...
I flat out do not believe them.
This is my sig.
Later I was a customer, my company bought a 9700 laser printer in 1980 ($500,000 - that's half a million), and those bastards wouldn't give us the technical info we needed to make maximum use of our technology. We were denied font file formats, low-level metacodes for typesetting, etc.
We then reverse-engineered the font format, developed & sold a program called COSMOS to create & edit font files, and Xerox couldn't do anything about it. Our first customer was their Business Information Systems in Rochester, NY!
Sure Xerox is still a big copier company. But Xerox paid the price: today they are an insignificant part of laser printing, and a non-entity in computing.
Slashdot entertains. Windows pays the mortgage.
Anyone who has been to the Windows HEC (Hardware) conference will appreciate the lengths to which Microsoft has to go to insure adherence to a common set of standards by all independant vendors and system builders. MS can't tell them what to do, they just publish specs and hope that hardware builders will sing from the same hymn book.
The bottom line is that the increased price of Apple hardware is worth it because it translates into better reliability.
(BTM I'm a Windows user).
Slashdot entertains. Windows pays the mortgage.
Just as a matter of interest, are you a programmer? You say you aren't a C programmer, do you program in other languages?
Anyway, what the parent says squares with my experience as a programmer (in C and other languages). The problem with what you are saying is that designing everything up front doesn't always work, because some problems only become apparent once the application is built. For example, you might not be aware of where the bottlenecks will be when you are designing the application. Having built it, it may become immediately apparent. Sure with more information and more experience, design improves, but even then, you can run into unforseen problems.
Advocating that all design happens up front is returning to the waterfall model of software development. The only problem is that it doesn't work. You might as well demand that all the specifications are accurate up front.
So, while I might not advocate rewriting every program, for smaller applications it can be a good idea. It is also quicker to write the second time because you are more familiar with the problem. In general I'd advocate rewriting it bit by bit rather than tearing it to the ground and rebuilding it each time.
meh
Just as a matter of interest, are you a programmer? You say you aren't a C programmer, do you program in other languages?
Yes, C++ is my language of choice, but I'm also familliar with Java and a frequent user of scripting languages (PHP, Perl, Python and Ruby).
Anyway, what the parent says squares with my experience as a programmer (in C and other languages). The problem with what you are saying is that designing everything up front doesn't always work, because some problems only become apparent once the application is built. For example, you might not be aware of where the bottlenecks will be when you are designing the application. Having built it, it may become immediately apparent. Sure with more information and more experience, design improves, but even then, you can run into unforseen problems.
From what I've experienced, is that when you design as much as possible up front, and have a team of software engineers which actually have a critizing look at what they're doing, you can avoid problems enough by far not having to do any rewrites. Sure, your design might be flawed due to some unforseen bottleneck, but you will not have to throw away code.
Advocating that all design happens up front is returning to the waterfall model of software development. The only problem is that it doesn't work. You might as well demand that all the specifications are accurate up front.
I'm not suggesting the waterfall model - I'm suggesting actually designing the application before writing code, instead of just writing and rewrite as your goal becomes clearer. I'm a frequent user of the V-model and RUP myself, personally I actually think the waterfall model is close to no model.
So, while I might not advocate rewriting every program, for smaller applications it can be a good idea. It is also quicker to write the second time because you are more familiar with the problem. In general I'd advocate rewriting it bit by bit rather than tearing it to the ground and rebuilding it each time.
Well, this might be good for prototyping certain functionality, but really, as soon as you're starting to write something "real" I really don't think planning to rewrite before even starting to code is a good thing.
- Leon Mergen
http://www.solatis.com
It seems to me that the rule of rewriting only applies to the same author. As the original author, you thought you understood the problem, you designed a solution, you implemented it. Then you realized you didn't completely understand the problem, so you (sort of) redesigned the parts you had to, reimplemented, etc. Once that process is complete, your probably really understand the problem and can reimplement the solution from scratch with a clean design that fixes all the hacky bits. :-(
But as someone who is just maintaining the original solution, you probably don't really understand the problem. And when you rewrite the original author's solution(s) with hacks and all, you'll miss bits of the problem you didn't understand, and you'll also introduce your own errors implementing things.
So, the solution for better code is to implement everything multiple times from scratch, and over a short enough time span so you can keep fresh in your mind the whole of the problem. Of course with complexities and costs as large as they are these days that's impossible.
Which is why all software sucks
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
How could they, even they, even MS, have written an entire OS in one year? or even two years? how is that possible? I do not believe it.
I am sorry, but you are insulting and asks for references when told to Google. You claim to not be a kid.
I guess I have myself to blame if I argue with children/trolls/idiots. This was the last I had to write. This is a very well known story, as I wrote from the beginning. If you haven't neither heard of it nor manage to Google, I don't care if you manage to read and understand the references.
Karma: Excellent (My Karma? I wish...:-( )
Linux was started back in the early 90's and BSD was written beforehand as was solaris.
Windows has decided lets make a brand new operating system today? Give me a break no code maturity no real fundimental base to their OS. Atleast when MacOS did it they utilised BSD.
And to do this in a span of just a few years (1 or 2)... I foresee even worse bugs being introduced into the system with the lack of code maturity they've chosen to abandon.
Sorry, but that is sad. You really haven't anything better to do with your time?!
Go find a sport that is fun (I recommend tennis, thai/kick boxing, jogging, weights and badminton) or try to meet girls or write code or play games or read books or sleep. Make the world or yourself better/weirder.
Also, it helps your self image to not act like an asshole just to irritate random people. Everyone but psychopaths do want to be the hero of their story -- and note an overgrown teenager.
And (1) High site ranking on Google isn't easy to get, (2) it is an old, old story from '91 -- which has been well documented. If you really haven't even heard about it, it do show your lack of age or something.
(As a hint... generally bad news about the controllers of the largest ad budgets in the world doesn't get spread that widely.)
Karma: Excellent (My Karma? I wish...:-( )
Yes, C++ is my language of choice
Cool mine too.
I agree with everything you say. Good upfront design saves a huge amount down the track. I guess I am trying to balance that against the fact that problems that are not anticipated in the disgn will arise while coding.
meh
Rather than making the elephant bigger and bigger it needs to become a coordinated herd of ...Gnus' maybe?
When the people fear their government, there is tyranny; when the government fears the people, there is liberty.
An alternative to the complexity of creating a web of state modalities (volatile, nonce, automatic, private, public, protected, static, persistent, etc.) and event model entities (mutex, monitor, listener, adapter, signal, slot, section, notification) which all have to be drawn in painstaking detail by under-educated and overpaid slackers with asperger's is to eliminate state and implement systems which can be reasoned about by infallible computer programs, instead of UTA grad school drop-outs.
-I like my women like I like my tea: green-
There is a big difference between rewriting because you feel like it, and rewriting because the universe has changed. There may be some fields where the specifications are nailed down enough that you can design the entire application, but let me lead you through a real world application that I was and still am involved with.
In the beginning, the application was a small Microsoft Access database with a handful of users. It was created by someone with only a passing knowledge of third normal form and some hideous design decisions. I was hired to make it usable, which I did by normalizing the data structures and rewriting the most offensive user interface components. This application was used and exteneded continuously for a few years before the corporate owner of the application realized that what we were doing could be useful to others, and so the program was ported to a Web Application using ASP.
Clearly, not much can be salvaged between Access Basic and ASP for the UI, so that was completely rewritten, but the underlying data structures were shared between the two (as were queries, report layouts and such). The database was migranted to SQL server for both front ends. Once it was online it was discovered that some of the requirements for the online users were different from the local users, so many modifications were made over time to improve the experience for the online users. This was successful, so instead of just serving other companies which played the same role in the industry as the original company, other industry players in other roles wanted to participate as well.
So we added interfaces, functions and data structures to the web app to support the other industry players (in the end we ended up with six levels of the industry interacting in our system). Quite clearly we had overloaded our original design, so from time to time we would reconstruct portions of our system to be more flexible and support a more realistic world view. However, development deadlines and ever increasing demands for features caused some cruft to remain. Sometimes modules had to be rewritten to support the new requirements (as you can imagine, a commissioning system designed for the lowest tiers of and industry broke when extended to all the layers that existed).
That brings us to the current day. We are rewriting the application, piece by piece, in ASP.NET/C# using many best practices which were difficult to implement is VBScript (an accursed language if there ever was one). The users have no idea which portions have been rewritten as many of the changes have been in the creation of business objects that improve the testability, scalability, and maintainability of the code. (I still have nightmares about COM objects and IIS lockdown thereof...)
The point is, we had no idea that this project would balloon from a simple Access database to an industry access point where thousands of companies interoperate each day. To say "design up front" when dealing with the real world is nonsense: design for flexibility is a great idea but breaks down when you go from a 20 hour hack job database to a multi-tier enterprise system.
No, the real answer is to iterate. Iterate fast and furious, learning where you need to go next and then doing it. Anyone with a rule on "don't rewrite" in our situation would be trying to bolt thousands of hits per minute on top of Access, and that is just stupid. Anyone who tried to design for our current situation would have failed to deliver in 20 hours the original product and would have been canceled without completing the first phase. (Additionally, I suspect any design that disconnected from real world experience.)
The business world doesn't sit around for pronouncements on high of the "correct" solution. More than once we have had to rewrite portions of our code as laws changed or we brought alien players into our system. (Like lawyers, who have a special access form to review information in some situations). We do a lot of data driven components that can be changed e
Sig under construction since 1998.
Yeah... okay...
and as a devoted MacUser since 1994, I can tell you this: up until Panther, each release of OS X was vital to improving the experience.
Let's not laud Apple for having pretty yet dysfunctional software.
Ugh, go read Code Complete. Now, a lot of folks have a knee-jerk reaction against Code Complete, but you should approach it with an open mind. There are a lot of things in the book where you'll go "wha?" or "that doesn't make sense" or "I don't like that". But I can pretty well guarantee that if you really sit down and honestly compare how you do X with how the book says to do X, the ideas in the book will work out better.
It sounds like your professor is more of a "hack it until it works" rather then a developer. I've met a few of those types of programmers, and it's sheer luck that they get anything to work on the first go-round. They have to rewrite because the bug count in the first version is so high, or the code quality so low, that fixing it takes longer then it would to rewrite.
Now, sometimes it *is* worth it to re-write from scratch. But you need to understand the risks involved and how to weigh the reasons for/against doing the rewrite.
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.
The problem is that you may or may not fully understand the problem when you start. Even if you THINK you do. Even if somehow, you absolutely did understand the problem, given a few years, the problem or it's scope may change. Advances in hardware may bring features that were always wanted but were rejected as impractical within the realm of possability.
When the problem was originally solved, the hardware might have been just barely able to handle it, so nice design got sacrificed for performance.
Then there's those 'one off' programs that somehow come into general daily use.
Admittedly, it's preferable to refactor and rewrite one module at a time, but if enough time has passed, that might be even more problematic than a rewrite, in particular if the software wasn't designed appropriately in the first place. There's a heap of code out there written when anyone who knew what a compiler was could be a 'professional' programmer.
Arguably, if you refactor and rewrite functions and modules agressively enough, it is just a rewrite in stages. With creativity that process can even change the application framework.
In the most extreme case of never rewriting, there is code still running on emulators because the platform is long gone and so is the compiler. Just getting the code to compile again would be close to a rewrite. In some of those cases, the binary no longer even matches the source because someone had to patch in changes. If you NEVER rewrite anything, that's where you end up.
> To say "design up front" when dealing with the real world is nonsense: design for flexibility is
> a great idea but breaks down when you go from a 20 hour hack job database to a multi-tier enterprise system.
Ah, you miss the point, grasshopper. What you have been doing is designing new versions of your application. The original advice is intended to get you to design up front for the version of the application that you plan to put into production. And don't change the design spec until that version has been fully implemented at least once.
Adding a web-based front end to your database is not a trivial feature. It's best to save major additions like that for the next version, but if you have planned your project in a modular way with a foresight toward things like different user interfaces, you make the re-write a much easier job. Your example doesn't contradict the advice, it reinforces it.
Design up front. Use your imagination. Play "what-if." Develop a plan for future expansion. This is the way to earn the "analyst" portion of your "programmer/analyst" job title!
Now IE is eating Mozilla's dust, thanks to the rewrite.
Mozilla had four years to catch up when the competition simply stopped development altogether, and Internet Explorer still dominates the market. In no way whatsoever can a reasonable person conclude that "IE is eating Mozilla's dust".
The only advantage Netscape had over Microsoft's bundling tactic was that ISPs mostly bundled Netscape on their setup CDs. They threw that away when they didn't release a usable browser for years. They didn't release a usable browser for years because they rewrote and spent time on things like XUL, chatzilla, etc.
The development team simply had no priorities whatsoever, and web developers are still paying the price today - if Netscape/Mozilla.org had simply concentrated on making a web browser instead of reinventing the fucking wheel, Internet Explorer would have a) had to compete instead of getting the market handed to it on a platter, and b) it wouldn't have anywhere near the market share it does today.