Slashdot Mirror
How To Make Software Projects Fail
Bob Abooey writes: "SoftwareMarketSolution has an interesting interview of Joel Spolsky, of Joel on Software fame. Joel, a former programmer at Microsoft, discusses some of the reasons he thinks some very popular software companies or projects fail, including Netscape, Lotus 123, Borland, etc." This interview brings out some mild boiler-room stories which sound like they could be the basis of a good book, along the lines of Soul of a New Machine .
Alot of .com's I've worked at in the past 2-3 years always wanted to "lowball" developers and engineers, while lining the pockets of resource managers, implementation managers, marketing people, etc.
/. - so I'll probably take a big hit on the karma - but I just was the casualty of another dotcom failure - and this was a seriousl problem.
Then a skilled/talented developer and/or engineer wants more money. The employer does nothing to retain them - thus the skilled/talented employee leaves.
Now who maintains the code?
The other problem is bringing in short term consultants for long term projects. The non-technical people who make these executive decisions don't seem to see the feasability of KEEPING their code maintained by the talented/skilled person who BEGAN the development on it.
I know alot of consultants read
Another problem is hiring non-technical managers to manage technical people. At my last job we had a manager off of an automobile manufacturing production line quit his job at the auto company to take a job as the manager of a group of Unix admins. This "bumper jockey" had NO CLUE what we did for a living, and treated us like a bunch of unionized UAW slobs, and not like professionals.
How can a non-technical boss effectively manage technical people???
Also - how about all the Ceo, Cio, Cto, eieio - types with their big salaries, catered lunches, etc... Alot of them have NO programming or hands-on technical experience. Hell - I've had the CTO come up to me and tell me that "The Internet was broken" when he knocked the dongle out of the side of his laptop - severing the network connection. And this guy is our Chief Technology Officer???? *lmao*
I'm not saying that only technological people can make technology companies work - but I do feel that managers should take some sort of hands-on classes to learn some basic programming and internet skills so they have SOME SORT OF CLUE about what WE all do for a living!
[Connection closed by foreign host]
Obviously, MS biggest problem though is that they don't know when to give up and actually rewrite. For instance, it seems that the windows series of operating systems are all made with the intent of being backwards compatible and reusing core parts back to early DOS systems. Backwards compatability and code reuse is nice and all, but there is a limit to it and a time to give up.
It will however be interesting to see what comes out of the "total rewrite" of IIS.
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
Joel's company goal is to be bought out by Microsoft. No, I don't know this for sure. But when writing that much it's hard to hide your opinions.
True, MS's monopolistic policies notwithstanding:
... IMO anything Real makes has never made it out of Beta, and naturally, don't unload the stupid System Tray icon that leaks memory like a sieve, because "you could lose some key features and performance benefits."
... but come to think of it, the only people to blame is Microsoft's competition, with their heads up their asses who can't put out decent software that works. Windows 95 didn't become the standard because it was great software, Win95 became the standard because OS/2 was marketed improperly, and IBM didn't work hard enough with OEMs. (that's gonna bring on flamage, so go ahead)
... I hate Microsoft as much as the next guy, having to put up with their software, but then again, I don't see many other "competitors" really trying ...
.... heh...
"Everyone thinks, poor Netscape, they were a victim of MS practices" - yes, they were, and yes, they innovated, but come to think of it, NS4 was crappy software that sucked.
"Poor Real Networks, MS is integrating all that stuff into the OS." - Good riddance
We blame Microsoft because their software sucks, and their practices suck
Only now, with Linux and Open Source, can WE the users contribute to what we want, not what some guys proposed business model wants. I mean seriously
ICQ pioneered instant messaging, but give me a break, the things been in beta for years and uses up more memory than most anything.
My note to all burgeoning software companies - Make me something that doesn't suck,and I'll pay for it, don't force me to upgrade every 20 minutes to a more bloated piece of crap that is nothing more than a "portal" for all those neat advertising engines you've snuck in there....and I swear, if I hear someone say "monetize the desktop"
If he said "Microsoft ate their lunch" one more time, I was gong to puke my lunch all over my keyboard.
Anyhow, I think he speaks horrible advice from a computer science standpoint. "It dosen't matter how bad, buggy, cludgy, and crufty a code base is, never ever rewrite it". If you don't understand what the code is, if it's impossible to read, don't worry! that's the sign of good code!
It speaks alot of Microsoft's tactics, do whatever it is that takes the absolute least effort possible, and charge as much as you possibly can for it. All of those other companies failed because they were focused on quality, whilst they were focused on nothing the bottom line.
Here's what I think is the worst software sin: writting shitty code and pretending it's not shitty. Regardless of how much gloss you put on it, bad code is rotten to the core, and it reflects that in stability and security. Why on earth do you think Microsoft falls flat on its face in those areas?
I remember a story about JD Rockefeller. He was touring one of his oil works, and he saw someone soldering the oil cans shut. He asked him how much solder he uses on each can. The man told him, something like 48. Rockefeller said "from now on, use 36". That's exactly the type of cutting corners companies like Microsoft do. THat's not good for the customers, it's not good for society, and it's not good capatilism.
Jordan Bettis
``Wherever you go, there's another stupid sigfile quote.''From the interview's lead-in material:
At Microsoft, the job title of Program Manager is given to the people that design the software. They dream it up, write the specs, hold countless meetings, and basically lay the path for the developers to follow. The developers (Software Design Engineer) are tasked with actually programming that software (and thus would be considered "programmers"). Just to round out the roster, the Software Design Engineers in Test (SDET) write the testing suites used by the test teams, and the Software Test Engineers apply those suites to the code following a test plan that they create. In that heirarchy, only the SDE and SDET jobs could be accurately described as "programmers".
Note that this is actually not so cut and dried, wherein SDEs often do design work and test work, and SDETs often do the work of SDTs. PMs don't program, however (well, aside from javascript&html prototypes, anyway).
The point? Calling this Joel an ex-Microsoft programmer is misleading, because he was not. However, the position he held at Microsoft actually lends more credence to his views on design than if he were actually an ex-programmer, as part of the job description of a program manager is doing software design.
(Brief descriptions of all these job titles can be found at Microsoft's college site.)
However, I feel slimy for just reading that stuff. Here is what I got:
1. Bugs are fine if they get your product delivered.
2. Load in useless features to drive sales, knowing that your code will suck.
3. Once you have gobs of crap code and a large user base, there will never exist the possibility of re-designing things (eg, WinXP) since it doesn't matter that code sucks (see point 1) and all that counts is revenue.
4. Being efficient is a waste of time. Let the hardware catch up with the crap code.
5. The customer never has valid input anyway.
6. Do it fast and furious, even if January 1900 is broken. Consumers are idiots anyway.
These may be great for sales, but ultimately you will build crap. Garbage in, garbage out. I would rather design good software that was well designed and efficient than vomit up mounds of bloat that will ultimately topple under its own weight.
Software built poorly will never hold up over time. If you look at how little UNIX has had to change over the past 30 years to keep up with "The Internet Age" versus the amount of work done to get XP "working", the future looks bleak for Microsoft. In 20 years, their OS need 25GB of RAM simply to boot up. Of course, this seems not to concern them.
----- Refactoring is the reason why man does not mistake himself for a god.
Yes, there are a lot of companies who have been squashed (or, as Joel would say, "Had their lunch eaten") by Microsoft in large part because of Microsoft's money/marketing, but there are also a lot of companies that nose dived into failure because of their own ignorant business and technology decisions.
While Microsoft may not like the costs and annoyance of court cases and DOJ action, it must give them some satisfaction because most of those companies bringing suit against Microsoft are doing so because they think that's their best option. I would argue that for these plantiffs making better products would be a "better option."
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
The reason they they need to go for a 32-bit system is that the hacks built into DOS was just not enough for their (then) expanding programs. Put simply, they exhausted DOS and were looking for help to get 32-bits under way. Hence the MS-IBM cooperation on OS/2, and NT from MS's fragment of it. FAT32 is another extention of the fs to allow the use of fat ideas into larger disks.
The original name of NT was "OS/2 NT". It's just an evolution of an IBM product that they had code sharing rights for. Ironically, the first version of NT [ie 3.1] is correct: version 1 and 2 were the common OS/2 base.
Apparently the one true MS invention was MS BOB. It has a massive entry in technet. Enough said.
OS/2 - because choice is a terrible thing to waste.
It's supposed to be a simple function to display a window or something, but for some reason it takes up two pages and has all these ugly little hairs and stuff on it and nobody knows why. OK. I'll tell you why. Those are bug fixes. One of them fixes that bug that Jill had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes a bug that occurs in low memory conditions. Another one fixes some bug that occurred when the file is on a floppy disk and the user yanks out the diskette in the middle. That LoadLibrary call is sure ugly but it makes the code work on old versions of Windows 95. When you throw that function away and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
Now, maybe I'm just ignorant because I've never really developed anything with the 640k barrier or had to haggle with XMS and EMS and other whatnot, but it seems to me that those bugfixes are needed because there's something else fundamentaly wrong with the code. IMO, sometimes you just have to rewrite, because your code is just fundamentally wrong.
Take DOS, for example. Microsoft added Windows. Then they made a bootloader, added real multitasking, and called it Windows 95, which wasn't that bad. Then they made some fixes, and called it Windows 98, which supported newer hardware, but was more unstable. Then only God and the developers at Microsoft know what happened to Windows ME, but that's when the bugfixes started causing bugs themselves. I mean, plugging in a USB printer shouldn't freeze the entire system!
Microsoft knew that they had a fundamentally wrong approach to an OS, so they wrote NT, 2K, and are new phasing out ME in favor of XP. XP replaces ME because ME is crap. However, this dude doesn't seem to realize that his own company isn't following is "wisdom."
Maybe I'm just cynnical, but I wonder if there is some kind of ulterior motive here.
Join the Slashcott! Stay away entirely Feb 10 thru Feb 17! Close all tabs to prevent autorefresh!
From a purely intrinsic point of view, I agree with you StaticEngine. From a purely practical point of view, I couldn't disagree more.
Let me explain myself. I have been the type of programmer you speak of. I have written copiously commented code. I have properly formatted my code and used standardized function names and such. After all, I was taught in college to write and comment my code so that any programmer could walk in off the street and understand it easily; that made it easy to replace me and I was.
It seems that when you follow good programming practice, you end up destroying your job security; and as silly as it sounds... it appears to be sooth.
Jaded in a realistic world.
Codifex Maximus ~ In search of... a shorter sig.
He's not talking about the Mozilla project, he's talking about the transition from 3.0 to 4.0. Basically Netscape threw away a lot of good code and some very nice algorithms for the sake of newness. They also developed a java fixation while the language and libraries were still very immature.
By the time the Mozilla project was announced, Netscape was already out of marketshare and had a product that was cleary inferior to ie 4. Considering the amount of bugs in the initial release of ie 4, making an inferior product was no easy feat.
Jamie Zawinski has a great deal to say about this period in Netscapes history.
--Shoeboy
As for point 1, I don't really think Joel would say that bugs are "good" or that they shouldn't be fixed. Just fix them in the most economical manner.
I do somewhat agree with you on the other points, though I'm going to take the liberty of doing some "charitable" interpreting of Joel on a couple of the points:
2. Load in useless features to drive sales, knowing that your code will suck.
I think, with respect to this, Joel isn't interested in useless features. What he is basically saying is that if users REALLY want a feature, you're stupid to to take the attitude that "I know better than you: you don't need this feature". You just lose customers that way. Remeber, the customer is always right.
3. Once you have gobs of crap code and a large user base, there will never exist the possibility of re-designing things (eg, WinXP) since it doesn't matter that code sucks (see point 1) and all that counts is revenue.
Well, although I do believe there are certain situations where a complete re-write is in order, I think he makes a valid point. I think Joel (again I'm interpreting here) would say that it is better to revise the current code, clean the current buggy code up and "perfect" it rather than to start over. After all, starting over doesn't even guarantee you that the new code will be any less crufty than the old code, just different! (Although, sometimes your design was fundamentally flawed to begin with and you need to start over to deal with the intrinsic problems in it, but hopefully those kinds of problem can also be dealt with by revisioning instead of starting over completely.) Start over with a new code base and you just end up with new bugs sometimes. Plus, as he points out, not releasing an updated product in the market for 3 or 4 years REALLY hurts a technology company.
4. Being efficient is a waste of time. Let the hardware catch up with the crap code.
Hmm, he does sound a bit like he's saying that. But, to be charitable again, I'll interpret him as meaning that it's not worth spending a lot of money and time to get small incremental performance increases or size decreases. But, obviously you're not going to set out to make your code as inefficient as possible. And he does have somewhat of a point about Moore's law. How many people are still using WordPerfect 5.1? Undoubtedly there are still a few people. . . but is Corel making any money from those people? Probably not, and since Corel is a company that needs (desperately at this point) to make money, they are going to add features that user want, that they think will give them a competitive advantage to Microsoft, even if that means increasing the size of the program a little bit.
I challenge you to name a business that never made a mistake.
They all do, or they all will make a mistake. Pointing out that Netscape or Real lost because of a mistake is disingenious, because EVERY business makes some sort of mistake. They spend too much time adding on buggy features, or they spend too much time getting it stable that they lack features, or both at the same time.
But, Microsoft's monopoly position mean that they're almost immune from mistakes. They can afford to have 3 teams rewriting code. They can afford to be a loss-leader for YEARS. They can write crap, but make sure it gets users from version 2.0.
And, Microsoft makes mistakes, mistakes that would put any other software house out of business. Look at how late they got into the internet, and how many people they bought out to catch up? The billions of dollars spent developing IE.
At that level, Microsoft doesn't need to give a fuck if they make a mistake. They have immunity from mistakes. They can use their monopoly to hide it, cover it up, or get a second chance later. Others, without a monopoly, cannot afford the expense of keeping up.
Hmmm...side thought. Maybe all that 'junk' DNA is Mother Nature's "Bug Fixes".
What a horrid column. Cringely just gets worse and worse. For example:
Java is buggy? A language is buggy? What's that supposed to mean? Perhaps he means that Sun's Java compiler is buggy or their JRE is buggy, but neither is true. As software goes, both are extremely un-buggy. Unless he actually has some evidence to the contrary. No, I'm just kidding; I realize evidence would be completely out of place in that column.
I'm sorry, Gates and Ballmer have bet their company on Java? I guess since he doesn't actually research his writing, why should he check it over afterwards?
Seriously, I've read more insightful comments browsing slashdot at -1.
I believe the key to Microsoft's success is knowing when to let go of a bad idea. Such as MS Bob, MS Chat and various others. It is when you still believe in a product which doesn't make money that you fail. It doesn't have to be superior or even new. It just has to have piss poor marketing and no good entrance to the market to lose.
Going on a rant here: this is why I believe Eazel failed. They held on to their file management program, but failed to realize it would not make them money when they needed it most. This is what I believe happened with Netscape also. They could not figure out a way to utilize Navigator for profit, but kept developing it. It would have probably been a good idea to release the source code then, while MS would only have been comfortable going as far as no-charge with IE (thus, giving Netscape the upper-hand). I also believe IE was a failure with Microsoft as well, though people don't realize it. Now that IE is free MS makes no money on it, and does not, IMO, know how either. The result of this action is that Microsoft is stuck developing the worlds most popular web browser for free with no way to recoup development costs. A total loss to Netscape? I don't think so..
Dijkstra Considered Dead
He missed expecting developers to work 9+ hour days as standard practice. A good book is "Debugging the Development Process". The author also worked at Microsoft, he was a project manager for a couple of different projects that were missing deadlines. He said often they were working 12 hour days all the time. When he started making people go home and also managed the to-do-list better the project would stabalize.
Just so I don't come off as a total moron, I did read the article and agree with it a great deal, especially the parts about rewriting code from scratch.
Besides, if you are going to rewrite a bunch of code, you just do it, and don't tell your manager. And then you make sure your unit tests pass afterwards. It's called refactoring...
I'm probably a bit biased towards Mozilla, and yes, it is a commercial failure, but I have a feeling it won't be known whether its successful software until about 5 years from now. It could be the Apache of web browsers, or it could be just the product that caused the end of Netscape as an independent entity.
And finally, it's probably also true that C# will turn out to be a better language (purely technically) than Java, and will rival it as a platform, but I really fear that its going to be hindered by the fact that Microsoft controls it much much much more than Java is hindered by the fact that Sun controls Java. And Java is by no means a failure.
pooptruck
This article is really about the economics of rewritting software.
The fundamental difference between free software and commercial software is that free software is about the product, commercial software places a higher value on the profit than the product.
The classic engineering design method is to build something, break it, build it again break it again, etc etc.
Ive never heard of good engineering design comming from build it, break it, fix just the bit that failed, break it, fix just the bit that failed, etc
The whole program is one product, patches dont always fit in nicely with the overall program flow, thats when a program becomes ugly.
Ugly code is more costly to free software because it stops people wanting to get involved, if commercial software is ugly they just pay them more money or something, managment doesnt care how much programmers like readign the code, they just care that it works and its on time/budget
If the minimum wage had gone up at the same rate as CEO salaries since 1990, the minimum wage today would be $25.50/hr.
Or is it that CEOs work that much harder than they did ten or twenty years ago?
The guys at the top did NOT pull themselves up by the bootstraps. They were hoisted up on the backs of others. Don't get me wrong. I have met some truly brilliant minds that were in charge of some companies. But I've also met some true boneheads who still gleefully pulled in $500K/yr+. We're moving headlong back into the days of the robber baron who rules over his fiefdom with an iron fist. Yeah, those were good times. Well, of course! When was the last time you took a pay cut for some peon...er...someone else's job?
- I don't need to go outside, my CRT tan'll do me just fine.
Yes, it's true. If you make a major mistake, you get killed, often by Microsoft. Some people think it's a pretty sad state. I just think it's capitalism and evolution. Dodo birds are extinct, and so is Visicalc. I don't want to be extinct, so I try to learn from the mistakes of the companies that have tried to go up against Microsoft. It's easy for me because I was inside and I know something about the way R&D worked at Microsoft. I've tried to share many of these lessons on my site.
To succeed in commercial software you have to get beyond being shrill and angry about Microsoft. You have to be cool headed and smart and study the past and make the right decisions for your company, not the right decisions for some arbitrary sense of aesthetics (although of course I am as big a fan of clean documented code as anyone.)
Production code is not so pretty. Open source code is not so pretty. No real code is all that pretty. It takes time to study it, understand it, and read it, to understand how it got the way it is. The more widely the code is used, the more true that is. For Fog Creek's latest software product, CityDesk, we stayed up one night tracking down a bug that only happened on Chinese Windows, where asc(chr(x)) turned out not to be equal to x, an assumption we had been making. How many of you ever thought about getting your code to work on Chinese Windows? No matter how well that piece of code was designed, I'm sorry, I've been programming for 20 years and I never realized that asc(chr(x)) was not always equal to x on some platforms, and I designed it wrong, and until someone tried it on Chinese Windows, I never would have known. Now the code uses byte arrays instead of strings and doesn't have that problem. There's a nice comment in the code saying "use byte arrays instead of strings because of MBCS versions of Windows." The code now works perfectly, but the byte arrays are a little bit uglier than strings. If ten years from now somebody rewrites CityDesk from scratch, I'll guarantee you that 95% of the Windows programmers working today would make the same mistake again, and stay up all night again.
If a piece of your code is ugly and doesn't work, by all means, rewrite that piece. If it's ugly and works perfectly, you're wasting valuable hours rewriting it, time that could be spent doing something that will gain you market share. If you really have an undecipherable mess of spaghetti, 9 times out of 10 you're just being lazy about deciphering it because it seems like more fun to create it from scratch, but it's the ultimate in arrogance to think that your newly created from-scratch version is going to be all that great.
Joel Spolsky
spolsky@panix.com
Joel On Software
I'm an IT consultant, making a living by developing applications for large companies. This is a totally different environment than the one described in this interview. My programs have one buyer, and typically run on a single machine.
I have been through a couple of code rewrites. In one project, we simply started from scratch. New database (Oracle 7 -> 8), new data model, new OS (UNIX -> NT) and a new programming language (C -> Java). I had the system requirements and the new data model as input, and I designed all the rest. I never looked at the original code, except to check the semantics of a few queries. (Joel's "hidden knowledge" doesn't apply here, since we were going to a new platform anyway.)
On another project, I redesigned and rewrote parts of the system. Each of those conversions have cost me dearly, and I wasn't really satisfied with the results. (In a partial rewrite, the new code needs to fit in with the existing system, and things get messy very quickly.) I wouldn't have done any of thos rewrites if the old architecture had been able to handle the new requirements.
Finally, I have one remark about aged code: comments are your friends. If you need to look at a piece of code twice before understanding it, you should add comments. If a particular construction is not obvious, explain why you do it that way.
I've only seen it done properly once. Literally half of the screen width was reserved for comments. (Yes, that is excessive, but it encourages people to write things there.) Every change to the code was tagged with the change request it belonged to. In many cases, the old code was still there, but commented out.
I'd argue that program code is not "hard to read" by itself. It is written that way. Programmers never consider the fact that their work will be read by humans (including themselves). Once you step out of that mindset, you will write readable code.
WWTTD?
He is correct that a rewrite is expensive, and can (and usually does) take a long time.
However, the mistake is not in doing the rewrite, but in not managing the process well.
The number one reason for doing a rewrite is for a cleaner, more stable architecture for writing new features against. The need for a new architecture is discovered in the process of adding new code to the old, and discovering issues that were not adequately addressed in the older version, or in learning better methodologies, or in the existence of better tools and programming processes.
Programs that have been improved by a total rewrite...
Windows NT/XP over DOS (and DOS windows)
Excel over Multimate
Word For Windows over Word for DOS.
Adobe Indesign over PageMaker
Quake over Doom
Quake II over Quake
That is off the top of my head...
ALL real successful software was origninally generated by extremely small teams of EXCELLENT *STAR* quality programmers. (There are not very many of them. If you don't believe that programming is a talent industry, you don't really understand what it takes to make successful commercial software).
The only real other option is unlimited resources (time and money) and it seems that where this exists is at Microsoft, and in some open-source projects.
The biggest problem comes from management believing that random team of programmers can create a new platform from scratch and that it can be done in a schedule that permits dropping the old code base.
ID does it by continuing to build new platforms with very small extremely talented teams.
ADOBE and Microsoft did it, with lots of time energy and effort, with parallel development against the old code base.
But this does not mean that it shouldn't be done. Those that do not rewrite eventually lose, because they are not able to respond to the market on the old code base, and are not able to make the kind of advances that a required by the customer base to upgrade if they use thier product already, or to switch or begin using their product if they hadn't already been convinced.
Managers are going to be disserved in the long term by reading Joels thoughts on the process, and ultimately the companies they work for will be eaten for lunch by new competitors that are not burdened by legacy code, but also really understand well the problem space they are trying to solve.
Software projects fail because they fail to innovate in the places that matter:
1. Software architecture - sorry, but a browser written using monolithic C++ isn't going to be as maintainable as MS's COM-based architecture.
2. Features - new features have to actually be useful and work. Without this, no level of marketing is going to sell a piece of crap (Mozilla comes to mind).
3. Tools and languages - new tools and langs often hold the potential to simplify development drastically, but many managers deliberately avoid new tech because they think they are being competent by playing it safe. In reality, it's actually safer to move to newer tech than to let your code decay.
Engineering managers suck in general. The only good ones I ever knew were ones who knew how to make ballsy decisions that buck the trend of convenience and political correctness.
no, he developed Hungarian Notation in the 70s as a small part of his PhD thesis at Xerox PARC. His thesis has a very interesting concept in it: imagine that programming is a game where two programmers are given the same task to work on, independently. They are allowed to communicate before beginning, but not once they start. If they produce identical code, they win big.
The point is that this is exactly how the software industry works: if you and I followed a set of conventions that caused us to generate the same code, we could maintain each others code with no extra effort (and rewriting it would produce the same result again :)
it illustrates what is wrong with perl's "there's more than one way to do it"
Supplying IE to competing platforms may be a way to lower the perception of MS as a monolopy but also take into account thier current stragety in the way of .NET services.
.NET services. Whats important here is not neccassiarily (SP) the platform of which .NET is running but the fact that the platform can run .NET.
.NET to all MAC users as well as PC users. So even if they didnt make money off the customer for the OS they may (of course it is up to the customer to use .NET) purchase .NET services and provide revenue in that aspect.
.NET.
.Net to all x-box users. Think not only did you buy little Timmy a game system but now for a mere 21.99 a month you can have internet access and all the goodies that come along with it and you dont even need a PC.
It seems to me that MS is really moving into a position to sell the
By providing IE for the MAC you can now provide
This is also one of MSs biggest reasons for the X-Box. Its not simpily a gaming platform with a DVD player. Its a ploy to get a PC running IE into millions of homes. Some of which may not even have a PC. The X-Box can run IE and most likey has a lot of software intergration points to
In this way MS will be able to provide internet service and
Ok my thread of thought has gone way off. Must be hunger..time for lunch!!
"Don't mess with him, he taunts the happy fun ball."
Do programming classes still make you put a comment on each line of code? E.g.: /* set x to y plus offset of 3 */
x = y + 3;
Come out of that sort of training, and it takes a while to realize that comments aren't stupid, your teacher was. Comments should NOT say what a line of code does. Except in obfuscated code contests, if what one line does isn't obvious, either the writer or the reader is incompetent.
Every module and function should have a block of comments to say what the module or function does, what the function arguments are, and especially give the specs, and tell what assumptions are hidden in the interface If possible, go back after software testing is done and note the conditions in which the module was tested -- this is invaluable for re-use, since it avoids the assumption that "this part was thoroughly tested", when it wasn't actually tested for what is now being done with it. Every time someone has to update the program, it's a "code re-use" for the modules that weren't touched...
In large functions, you might want to put in comments for each major block of code, but first think about whether the function ought to be split up... Line by line comments are needed only when you are doing something that is unusual, not straightforward, or handling an issue not stated in the specs; say WHY you are doing it that way, or why you have to do it at all.
However, I have to take issue with your position that rewriting code is bad because it throws out all the bug fixes that past programmers spent time and effort finding and fixing. I suggest reading an article in IEEE Transactions on Software Engineering 1/2001 issue. "Does Code Decay?" I would like to post a URL to that article .. but unfortunately it requires payment.
Eick, et al's conclusion was that indeed code does decay. Their definition of decay was "A unit of code is decayed if it is harder to change than it should be, measured in terms of effort, interval, and quality." (italics theirs) The source of their data was the entire change history of a 15-year old real-time software system for telephone switches with over 100 million lines of code. What they did is measure the number of files that a single change had to modify. What Eick found was that once the initial development flurry of activity died off the probability of a change needing to result in modifying more than one file was less than 2%. Within five years the probability had increased to greater than 5%. It is Eick's contention that this is a sign of code decay because the number of "simple" changes was dropping and the number of complex, involved changes was increasing.
Furthermore, they found that modules began to exert "gravitional" effects on nearby modules. This resulted in blending and stronger and stronger coupling of the modules.
They listed a number of causes of decay:
- Inappropriate Architecture
- Violations of the original design principles (The program is required to do something that was not anticipated at design time)
- Imprecise requirements
- Time pressure
- Inadequate programming tools
- Organizational Environment (low morale, high turnover, poor inter-developer communication)
- Programmer variability (some code that should only be touched by experts is mucked up by novices.)
- Inadeqate change process
Bad management of course will magnify the issue.To that list I would also add that as the field matures we learn better and better techniques. A very good example of this was the seachange that I saw when the use of exceptions were first introduced. I remember all the effort of trying to communicate an low-level error condition up to the calling chain. Error codes return values -- what a nightmare! Once I saw exceptions and understood them -- It made the quality of my code much, much better.
So to Eick's list I would add general advances in the field result in the realization that what was previously considered "best" practice is no longer the case. This happens in every scientific field and computer coding is no different.