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 .

Comments

Good point

[Bandito]

He says:

"My theory is that this happens because it's harder to read code than to write it."

He couldn't be more right. I've recently been asked to port some code from another group in the company. Upon first reading it, I found global variables being referenced from everywhere, and it looked terrible.

The more I looked at it though, the easier it got to read, and having an existing code base to work from made things much easier.

Plus, when I have problems with it, I can blame it on a "design error" by the previous programmers!

Re:Good point

[Skyshadow]

This is why it's important to force your developers to (gasp) comment their code. Of course, 99 times out of 100, this won't happen because either (1) the boss thinks that'll slow you down and you'll miss your release date or (2) your boss has never written a line of code in his life and doesn't even know you can comment on that computer codes thing.

Re:Good point

[czardonic]

Commenting poorly written code won't help you worth a damn. Plus, why assume that someone who writes bad code will write good comments? Good code speaks for itself.

Re:Good point

[StaticEngine]

Good code is not just code that compiles and runs efficiently. Good code also has the following properties:

• Clear, Consistant Formatting - This code complies with the company standard for writing code. Indents are properly nested, Functions are named consistantly, variables use Hungarian Notation or some other standard. Any programmer should be able to look at code by another programmer and pick up on it very quickly, without shaking their head and saying "What the hell were they thinking?"
• Copious Comments - Lots of comments, clearly written and explanatory. What does this function do? Put a block at the beginning explaining it. How does this algorithm work briefly? Write a paragraph if you have to. The best comment I heard was from a friend about a former coworkers code: "It's English with some C++ thrown inbetween the comments."
• Documentation - Anyone who shrugs this off is an idiot. You always have time for documentation. And it's not just for the instance where a programmer gets "hit by a bus." It's for people who leave behind code when they quit, or go to a new project. It's for the new hires, so they can understand and study and learn good design, good techniques, and developer rationale. It forces developers to explain themselves. And it allows non-techies to understand what they're doing. Imagine you had to get through 12 years of grade school with no books. Pretty frightening, eh? Documentation is good. Write it.

Coders who follow these rules truly are an asset to their company. Geeks who hack, write unreadable code, and utter geek credos about enforcing obfuscation and being purposefully vague have no place in a business environment.

Re:Good point

[zmooc]

Good code speaks for itself about what it does, but not about WHY it does something and that's were comments come in handy.

Re:Good point

[Anonymous Coward]

If you think no comment is ever useful on well written code, you shouldn't be a developer. If someone new has to come into your project (especially a jr. engineer), well placed comments will greatly decrease the time required to understand the overall function of your code. By assuming your code speaks for itself, you're assuming everyone is exactly as familiar with the code as you. This basically forces a newcomer to study your code down to every nook and cranny before it even makes sense. Not commenting your code is nothing other than lack of discipline and a sign of indifference towards the overall success of the project.

Re:Good point

[Anonymous Coward]

Per line comments rarely add anything. But per function comments are a god send. Keh?

Re:Good point

[Anonymous Coward]

Bug fix comments with Bug ID and fix date are also really nice.

Re:Good point

[mshiltonj]

Commenting poorly written code won't help you worth a damn. Plus, why assume that someone who writes bad code will write good comments? Good code speaks for itself.

Not always. A new method in a class does not explain itself in absence of the whole class. If I'm working on just this one method, I want to know how if fits in with the rest of the class -- without having to read the whole class.

Code warriors write the code, and it may be great, but more times than not (in my experience), it's less skilled folk who have to support and maintain the code. The Warriors have moved to to develop the next great thing.

Re:Good point

[rodgerd]

Because sometimes code which looks bad to the casual observer is bad for a reason, usually to do with the peculiarities of and environment - a buggy standard c lib, a braindead app server or somesuch. Good commenting makes it clear that this is broken by design and attempts to fix it will cause more problems than they solve.

Likewise, I've left comments in code to the effect of, "I know this is broken, but we had to have it yesterday. It should be written better using x, y, and z techniques"; this flags to future developers (and me) that it's a FIXME and points a route for the fix.

Re:Good point

[Anonymous Coward]

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.

You know, you were probably fired because somebody in management didn't like you or your attitude, because somebody had to go, your salary was too high, or because you were on the wrong project. People are even occasionally still fired for poor performance, I hear.

I must confess, however, that my employer will get much better documentation about what I've done if I leave voluntarily...

Re:Good point

[Anonymous Coward]

Heh. I've seen programmers kept on to support their own shoddy code, but I haven't seen any programmers let go because their code was too good. If you need to obscure your code to keep your job, theres something wrong with your performance.

Re:Good point

[TeeWee]

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.

If you really mean that, than there's something seriously wrong. If you need that kind of obscurity to get job security, perhaps you should look in the mirror more accurately and find other ways to raise your performance. Or your manager knows jack shit about IT.

Creating code that a machine understands is easy. Creating code that humans understand is what makes coding difficult. Any able manager would love to see a coder in his staff producing code that any programmer off the street can jump into and work on efficiently. I'd get that coder a raise to make sure he doesn't leave! Far from destroying job security, it increases job security!

Re:Good point

[beable]

However, not all comments are useful. I have seen code that goes like this:

//
// Now we can release the lock on the handle.
//
Handle->ReleaseLock();

And it goes on like that for hundreds of lines, in one function. Every line has three lines of comments that give no more information than the line of code gives. Every function is hundreds of lines long with multiple "if" and "else" branches. This is nothing more than:

i++; // add one to i

It is crap, and it doesn't help. Not all comments are good. But I can just imagine the programmer writing it thinking "I'm writing some really good stuff here! Look at all those comments! This MUST be good!". But it's bad. Very, very bad.

Re:Good point

[mightbeadog]

I think programmers, and geeks in general, naturally see things in new and unusual ways. This is a great tool for invention and problem solving. However, we also tend to suck at seeing things the way others see them. Some of us just can't do it, and thus have no social skills. Others of us have learned to do conciously what the majority does naturally, maybe RPGs help. :-)

Anyway, being unskilled at seeing things as others do, we tend to misjudge how obvious our code is. And when we do write comments or other docs, we have trouble judging their usefullness. Therefore, the quality of comments tends to be somewhat random, even when we believe in their importance. Also, lack of feedback means we can't hack documentation, so commenting is never as much fun as programming.

I'm a little confused..

[Anonymous Coward]

I wasn't aware that Borland -was- failing. They do have a cross-platform language that's on par with Visual Basic in the ease of use department, that's more than Microsoft's done. In fact they're one of the only companies that -support- cross-platform development with both of their products, and they're the only company that's actually responsive to the community that uses their software for development.

Re:I'm a little confused..

[ICodeThereforeIAm]

You must be young. Borland used to have a PIM (sidekick), a database (DBase), a spreadsheet (Quattro) and a wordprocessor trying to compete with MS. Needless to say, MS won. Now Borland is focused on their development tools.

Re:Isn't it obvious?

[tshak]

Actually, reading this interview shows how there where serious blunders performed by NS, Borland, etc. In each case, while MS improved their software, the other companies rewrote their software.

Re:Isn't it obvious?

[Alpha State]

It is funny how every company he talks about lost to MS. Seriously though, one of the things he does say is:

Fortunately for Microsoft, they did this with parallel teams, and had never stopped working on the old code base, so they had something to ship, making it merely a financial disaster, not a strategic one.

IOW, have more money than God and throw it at any problem you're having trouble with. The minnows in the pond get beaten up by the 800lb gorilla (or something).

or (3)..

[rho]

or (3), incessantly repeated nerdisms such as "if it was hard to write it should be hard to read" instill an improper sense into young, impressionable programmers.

what a load of crap

[gmack]

Old code does indeed age.. what happens when you tweak a program to do something you hadn't thought of when you designed it?

What happens when you cludge it a coupple more times?

Eventually you need to go back and redesign the section you are working on from the ground up with all of your goals in mind.

This is not throwing out the old knowlege it's learning from it and there are plenty of examples where it's worked out for the best.

What was spelled out in the interview was a recipy for a buggy mess.

Perhaps you should read the article

[Skim123]

Before you jump to false conclusions. A lot of companies that Microsoft "drove out of business" were driven out of business because they made stupid mistakes. Yes, MS's money and marketing helped, but some of the stupid things these companies do is their own damned fault.

You may want to check out this article by Robert Cringely: Microsoft's C# Language Might Be the Death of Java, but Sun's the One to Blame.

A lot of truth in that...

Re:Perhaps you should read the article

[SoftwareJanitor]

The interesting thing is that Microsoft made plenty of stupid mistakes too, but since they were powered by monopoly profits in OSes (and earlier on by licences for BASIC in ROMs), they could afford to wait out their mistakes and just keep throwing money at the problems until they straightened them out. As long as a company is successful in the long run, people forget most if not all of their stupid mistakes, but if the stupid mistakes take down the company then people remember it. The history books are written by the victorious (in the short term at least), so I would take a lot of this guy's story with a grain of salt, as it is certainly far from unbiased.

It is a pretty bad situation for a market to be in if any one company is so big that all they have to do is wait for their competitors to make a mistake in order to be able to crush them. When any one company wields so much power, it makes it nearly impossible to sustain any sort of competition. Not to mention that when a market is ruled by an 800lb gorilla, all of the smaller players are pretty much forced to take more risks and make other decisions differently than companies do in a market where there are at least two or three players splitting up significant chunks of market share. Sometimes those risks pay off brilliantly, sometimes they are stupid mistakes.

Re:Perhaps you should read the article

[scrytch]

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..

IE is no more a loss leader than any other piece of windows is. Doesn't matter what they tell the judge, it's a piece of windows. It's probably saved them a lot of money in the long run as well by not having to implement and integrate various viewers into other programs. Winhelp is gone, the help system now is 99.9% IE.

Even if it is a loss leader, it still sells Windows. This can scarcely be considered a failure. Bob and Comic Chat were a failures ... quit while you're ahead.

Re:Perhaps you should read the article

[SoftwareJanitor]

Microsoft has had a monopoly position for a long time. Most people don't remember when there wasn't a such thing as an IBM PC or MS-DOS. Microsoft got into a monopoly position with MS-DOS pretty quickly after its release in 1981. Within a couple of years it had killed off CP/M and the 8 bit 65xx OSes. So certainly since at least 1984 or so Microsoft has basically had a monopoly position in OSes.

But wait... that wasn't Microsoft's first monopoly position. Even before MS-DOS they basically had a lock-hold on BASIC interpreters, which were one of the most critical parts of the pre-IBM PC desktop. Apple's BASIC, Commodore's, and Radio Shack's were all licensed from Microsoft. Most CP/M machines also bundled Microsoft BASIC. In fact a strong case could be made that the MS-DOS monopoly which grew into the Windows monopoly was itself leveraged from the BASIC monopoly.

There is a difference between pointing to monopoly power as the primary reason for Microsoft's success than the only reason. Saying that Microsoft's monopoly power had nothing to do with the failures of other companies is as wrong as saying that those other companies made no mistakes.

As for Microsoft's marketing, I am not so sure I would call it 'shrewd' as pervasive and persistant. They've outspent just about everyone else for years, with the possible exception of IBM, but that is easy when you have monopoly profits to fall back on. It would be hard for a startup to outspend Microsoft on advertising, even in a niche.

Re:Perhaps you should read the article

[tpv]

>> The interesting thing is that Microsoft made plenty of stupid mistakes
>> too, but since they were powered by monopoly profits in OSes (and earlier
>> on by licences for BASIC in ROMs), they could afford to wait out their
>> mistakes and just keep throwing money at the problems until they
>> straightened them out.

> 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.

What worked for microsoft was to enter a market, take control of it, and then find new markets to take on.
When they got big enough they did that in parallel.

They started with BASIC, then MS-DOS, and then tried to maintain control of the OS (with Windows) at the same time as writing applications to take on people like Lotus. They they went for the server market, the database market, etc.

They can afford to kill of stupid/failing products because they have a number of revenue sources.
Borland screwed up all their markets, and manage to scrape through with a set of development tools.
Lotus lost on the apps, but managed to hold on to Notes long enough to get bought out.
Netscape lost the broswer war, and got sold off for spare parts (NetCenter and Enterprise Server).

If you're only competing in one market, then you have to get it right pretty much every time (Oracle). If you let the ball down you will end up loosing your market, and getting bought out (Informix).

MS didn't win because they had a monopoly, they won because they used their monopoly (both for power and resources) to allow then to diversify into and market they wanted.

Re:Perhaps you should read the article

[SoftwareJanitor]

"So certainly since at least 1984 or so Microsoft has basically had a monopoly position in OSes."

Not quite buckeroo. In the late 1980's platforms from Apple and Commodore(and even Atari to some extent) were very viable, and continued to be up until around 1990.

Apple, Atari and Commodore, all put together even as early as 1987 could barely have scratched into the 2 digit market share range. And certainly of those the only one that was making any share in business sales was Apple. Even then, Apple was never very successful outside of the desktop publishing and graphics niches. Atari and Commodore were never serious competitors to Microsoft. Heck, Commodore even sold MS-DOS based x86 boxes. Hardly much of a competitor.

At which point DR-DOS and OS/2 were very viable competitors with Microsoft and had large chunks of marketshare.

Oh please. Neither of those ever sold any significant numbers. Microsoft already had over an 80% market share by then. I'm not saying that they weren't viable products, but that is different than being viable competitors. OS/2 and DR-DOS were never viable competitors at least in part because neither of them could ever crack the preload market. Microsoft was able to keep them locked out through restrictive contract terms amongst other issues.

Having viable products in competion with yours doesn't necessarily prevent you from having a monopoly. If you have a seriously dominant market share, then you can have a monopoly even without being officially granted a government sanctioned monopoly or without necessarily being the only product available. It seems like a popular thing for Microsoft apologists to claim Microsoft isn't (or wasn't) a monopoly by wanting to make the definition of what a monopoly is so restrictive that there practically isn't such a thing.

It wasn't until 1995-1996 that Microsoft became a real monopoly, when everything else just disappeared into the nowheresphere.

Please. Both Atari and Commodore were out of business by the 1994 timeframe, and neither were more than gasping for air for the last several years of their lives. Apple is essentially the only non-x86 holdout in micros. Microsoft certainly extended their monopoly during that time period, but it was far from the turning point.

You're also grasping for straws on the BASIC thing.

How so? Microsoft was making a royalty on virtually every microcomputer sold in the 8 bit days. About the only exceptions were Atari and TI, who had their own proprietary BASIC. Just like with most packaged PC's these days, it was virtually impossible to avoid paying the Microsoft tax even back then. Sounds like a de-facto monopoly to me.

He's only partly correct about the rewrite thing

[Bwah]

With your average application from scratch rewites are probably UnCool for the reasons mentioned in the article.

For other kinds of systems I'm going to have to argue that rewites can be very beneficial.

For systems where the development team has access to a regression test suite and the old (working) code at the same time rewrites are much more easily done. You simply treat the existing code like a prototype. Something that captures all of your requirements, but maybe not using a design that ended up working out (read as: turned into a freaking hairball as time passed!) You work through the old code, understand it, and then build up a new design that works out cleanly in all of the places where the old code was a hack.

When you are all done (or as you are working), you hit it with the test suite. This works out best if your process requires that all of those pesky little bugs found in the old code had to have test cases to reproduce them. (Obvisouly there are limits to this ... the infamous 1 in a million "random" crash, etc.)

Anyway, I think Joel's statement was just a little to broad. He's correct in some cases, but not all. Of course maybe I'm just one of those overly confident coder types ...

Re:Taking lessons from...Better Yet Check this one

[darkPHi3er]

"Joel: Don't get me started! If you're a software company, there are lots of great business reasons to love bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make users' lives better (if they use them) and don't usually hurt (if they don't). As a user, if your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible, but you went for two months without new features that you needed, and THAT hurt."

Can you spot the "seat of the pants/never piss of the installed base"-oriented design fallicies just in that one paragraph:

1. More features are always better features

2. Coders are not responsible for optimization

3. Hardware vendors must not change h/w designs that would break installed base, even to improve their architecture

4. Your s/w is SOOOO... important that shipping delays for optimization/tuning/additional debugging are not to be accepted

further from the rest of the interview;

6. There's never a reason to rewrite extent code, EVER...(here's my nominee for that reason -- Microsoft Outlook)

7. Architecture is secondary to UI, maintanence of the UI experience is the MOST important standard

8. Any problems caused by #7 above should never be fixed by redesign, but instead should be prioritized and patched by response to User problems.

i could go on, but i think i've gotten the highlights, did i miss any???

Gee, can anybody figure out a s/w product(s) family that seems to be a living demo of (my phrase) "Design By Release Date, Redesign by User Complaints" School of coding????

i'll even agree with Joel that you should be very careful with "scratch" redesigns, and too many people would rather rewrite viable code than fix it....

BUT JEEZ, should you hold on to a payroll system written in FORTRAN69 (or LISP or ALGOL or FORTH...), just because it works, even if you have NO OTHER apps in FORTRAN and don't have one single FORTRAN programmer working for you????
.....

Death by Engineers

[Skyshadow]

I'm in the alternate situation: Too many of my execs (except, for some reason, the VP of Development) are engineers.

This leads to a whole host of problems:

Many of them tend think they're smarter than people in non-engineering roles.

Pursuant to this, they don't think PR and marketing and sales are "hard" or really even "important".

Again after #1, they're always right when in disagreement with marketing or sales guys.

Most of them haven't developed in a decade+, so now they know just enough to be dangerous -- make micromanaging decisions about detailed subjects things they don't understand well enough, chase unnecessarily after bleeding edge tech, etc.

Fail to understand that not everyone wants to always work 14 hours a day.

Laugh off meetings, so that eventually nobody in the company knows whats going on.

As a result, nobody's heard of us (no marketing budget, no trade shows, no nothing) and nobody's buying our products (engineers tend to make lousy sales guys; despite what they might believe, nobody wants to listen to a 3-hour ridiculously detailed presentation on your product).

There's got to be a happy medium someplace.

Not "fron scratch"

[Brian Kendig]

Just a correction to a point raised in the interview:

Netscape made the "single worst strategic mistake that any software company can make" by deciding to rewrite their code from scratch.

Netscape didn't rewrite the browser from scratch. Back in April 1998, Communicator 4 was the current version; to get from there to the open-source Mozilla browser, everything that couldn't be distributed (code from other companies, and security code with export restrictions) was stripped out of the source code. What was left was made available as the start of Mozilla. It didn't even compile at first, but Mozilla didn't start from scratch.

Admittedly, the fact that this next-generation browser hardly worked at all for more than three years did keep Netscape from capturing any market share, but the browser had already been commoditized, and the battle had already been lost.

I think that the real browser battle is yet to come -- when the bulletproof and iron-clad Mozilla, carefully fine-tuned to scratch every developer's personal itch, is finally ready sometime next year to take on whatever Microsoft has got. I think that's when the real interesting things will happen -- not just on the technical and marketing fronts, but also on the legal front, as Microsoft finds ways to make sure Mozilla isn't a threat...

Sure-fire way of making a software project fail:

[kcbrown]

1. Act like a cheezy salesdroid. Promise to implement everything the "customer" (usually some other department of the company) requests and tell them that it will be done in a very short period of time like, say, a month or two. Mutually exclusive features are really good here. Say and do whatever it takes to "sell" them on the project.
2. Talk with the "customer" on a regular basis. Promise to make all changes that they request, especially the ones that would normally be far outside of the scope of the project -- the ones that any sane engineer would insist requires a redesign. Promise that it won't be a problem to make these changes and that it'll only take a couple of weeks at most.
3. Push your developers hard. I mean really hard. They'll have to work 20 hour days for weeks at a stretch in order to meet the design goals and the target release date, after all, and they do work for you, after all, and you did promise the "customer" it would be done on time, after all. When the project gets behind schedule, fire the team lead(s) to provide "motivation" for the rest of the developers and to show everyone that you mean business. They were just getting in the way anyway. It doesn't matter that they had the most knowledge about the project, because we all know that software is easy.
4. When you near completion of the project (assuming your developers haven't bailed out on you already, but hey, the economy sucks right now so they'll be happy to be your bitches), hold another meeting with the "customer". You're almost sure to discover that they didn't really need what you're building that much anyway. Oh, well, at least it was good exercise for your developers! At least, for those that are still around. Hold a meeting with your developers, declare victory, and retreat (um, I mean "advance in the opposite direction").

No, I'm not cynical. Honest.

All things in moderation--including comments

[achurch]

I'll agree with your other points, but this:

Copious Comments - Lots of comments, clearly written and explanatory. [...] The best comment I heard was from a friend about a former coworkers code: "It's English with some C++ thrown inbetween the comments."

is nonsense. If your code isn't written well enough to make it obvious to another programmer what it does, then no amount of documentation will help the poor sop who comes along after you and has to maintain your code. Programming languages are just that--languages--and can be used to express concepts just as well (better, in some cases) than human languages. For example, if I see:

for (i = 0; i < array_size; i++)
free(array[i]);
free(array);

then it's perfectly obvious that it's freeing the contents of an array; I don't need you to tell me so in a comment, and in fact if you do, it gets in the way. As one of my university professors said, "Use comments to tell me something I don't know."

Comments are good things, of course--used sparingly. But there is such a thing as "too much of a good thing."

Re:All things in moderation--including comments

[dillon_rinker]

make it obvious to another programmer what it does
The point of comments is not to say WHAT you're doing...as you say, that's obvious. The point is to say WHY you're doing it.

d := d*360/400;
x=gsin(d);
d := d*400/360;

Any programmer can see that I'm mangling d and calling a function. It might be useful to add the following comment, though...

// gsin function requires argument in gradients
// convert d from degrees to gradients before
// calling the function, then convert it back

Now, when you're trying to improve performance or figure out why d changes value subtly in this routine, you can rewrite the code as

x=gsin(d*360/400);

Comments are good things - you should use them copiously to explain your thinking. Any compiler can figure out WHAT you're doing; a human being can thus do likewise. Only a sentient being can determine WHY you're doing it. Use your comments to communicate with sentient beings. It may take a paragraph to explain a single line of code. A page of code may require only a single line of comment. Use your own judgement, but always remember that your target audience is someone completely inexperienced with your project somewhat inexperienced with the language you're using.

A little unrealistic

[Ars-Fartsica]

Joel assumes that crusty code is always filled with knowledge. No, sometimes its filled with crap. More code often means more bugs, not less.

I agree with the spririt of what he is saying - often the "rewrite" is an ego thing - one programmer wanting to write his code instead of reading someone else's, but there is no doubt that most serious professional programmers have looked at code that simply needs to be thrown away.

Bloatware

[Shafalus]

I have learnt a lot of good practices from one or two of Spolsky's articles, and for that I was prepared to put up with his cocky know-all attitude and routine rubbishing of every software company except the ones he has stock in, but lately he is full of tendentious statements like

In 1993, Microsoft Excel 5.0 took up about $36 worth of hard drive space. In 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space. All adjusted for inflation. So stop whining about how bloated it is.

So the space it takes on the hard drive is the only cost of bloatware? Try downloading IE 6 on a dialup connection and then check your phone bill.

Re:He certanly is into lunch, isn't he?

[Osty]

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!

And this is the difference between academic code and commercial code. Ever looked at 90% of the research projects from graduate students? Most of them barely work, or only work on one specific set of hardware (and not anything else), or require a huge set of work-arounds to get the code up and running. The reason for this is because this is theoretical work. It doesn't matter how well it works (well, unless your thesis is on optimization, but that's different), only that it works well enough to demonstrate your research. Commercial software is the complete opposite. It has to work, and work well, on many different configurations of hardware, and many different versions of software (Windows 95 vs 98 vs 98se vs ME vs XP, Windows NT4 vs 2K vs XP, Mac OS 7.x vs 8.x vs 9.x vs OS X, and so on), or your potential customers aren't going to buy it.

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.

You didn't read the interview, did you? One of the main points in there was that by throwing away your old code and re-writing from scratch, you're throwing away years of experience and bug fixes. To use the example he gave of the nasty function that was supposed to do something simple but had a whole bunch of seemingly useless extra crap in it, the point was that all those extra little things that you'd throw away in a rewrite were necessary bug fixes. You throw them away, and unless you wrote those bugfixes in the first place (not likely, and even if you did, not likely you would remember), you lose all that information. That means that your new, "cleaner" version is very likely going to have similar bugs. Perhaps even the same bugs you fixed in your older, crufty code. Rewriting your code from the ground up is not focusing on "quality" (it may be focusing on "quality of code", which is a pretty useless standard so long as your code is proprietary), but instead focusing on "triviality". The bottom line is that in business (any business, not just the software development business), the bottom line is what's important. If you don't like that, stick to academia. You'll be happier there, and your potential peers in the commercial arena will be happier having you there.

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.

Irrelevant red herring, and a bad example to boot. You're equating a potentially dangerous situation (in your example, less solder means a less solid joint, which means the oil could leak) with a harmless situation (reusing your old code, crufty as it is). In one case you're making a conscious decision to be less safe, while in the other you're making a conscious decision to leverage the work that's already been done.

As I said, I don't think you read the article. If it makes financial sense (you will sell enough copies to recoup your extra development cost and extended time to market), then there's nothing wrong with re-writing code (though Joel did suggest looking at the old codebase while writing the new, so that you won't miss any of those one-off bug fixes that are neccessary but are also the source of the cruft). The problem is that it rarely makes much sense. Especially when you're in a competitive market (as all the examples he gave were -- when you're competing against Microsoft, the worst possible thing you can do is be more concerned about code quality than making a featureful, useable product that's available quickly).

Re:Before everyone points at Microsoft .....

[Merry_B.Buck]

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...

Unfortunately, if I write software that doesn't suck, doesn't need patches, and does what you want, you'll buy one copy (Netware 3, WinZip, Eudora) and in 2 years I'll be bankrupt.

If I write software with tons of broken features and requiring constant upgrades for 'compatibility' and security (SAP, QuickBooks, and Windows 95), I'm guaranteed plenty of repeat customers.

Now if you'll excuse me, I need to go buy a $100 ink cartridge for my $30 printer.

Re:Taking lessons from...Better Yet Check this one

[Anonymous Coward]

So, as the old adage goes, if it ain't broke, don't fix it. That FORTRAN may be crufty, but it never blue screens or segfaults.

And you can't extend it or thread it and you can only throw hardware at it (which although being a good option, it's good when it's your only option).

Joel doesn't advocate retaining that FORTRAN codebase. He advocates maintaining the codebase and moving it slowly to where you want - not just scraping it and starting from scratch. You could make a wrapper around the fortran and then move parts of the output to another language. This is what Joel teaches. Not just File|New at the first sign of trouble.

Valid point, but something else to think about:

[JSBiff]

I agree with you that sometimes the design is fundamentally, intrinsically flawed and needs to be thown out; but more often times you can revise and evolve code.

As far as Microsoft redesigning the OS with NT:
Microsoft is one of the few companies who can afford, financially, to have parallel development teams. When Microsoft started building NT they had help in funding the development because IBM was helping them (remember that NT started out of the OS/2 project that Microsoft was working on with IBM). And later on they had made such a fortune on Win95 + Office 95/97 that they had more than enough money to fund parallel development.

Microsoft realized that, at least in the early versions of NT, normal users would have a hard time administering NT and running a lot of the programs they wanted to use under NT. That is why they paid developers to keep developing Win9X/ME, EVEN AFTER they decided to redesign the OS. I would say that Win2k Pro is the first version of NT that most users would have no more problems with than if they were using Win9x.

Since most companies can't afford to keep parallel development teams in order to maintain the old product until the new product is "ready" for all their users, it usually (though not always, I think) makes more sense financially to try to evolve and revise the current code base.

Point 2: Microsoft IS, in most cases, following exactly the strategy that Joel outlines. Take Internet Explorer for example. Up until IE4, IE just plain sucked as a browser. Microsoft kept revising/evolving it though; With 4 it still had lots of annoying things about it, but was generally usable. With 5.x they fixed more bugs, got a lot of things working fairly well (of course, there were still some things that were annoying about it, especially from a web developers' perspective, like a bad implementation of Cascading Style Sheets, which still isn't quite right (but I'd hasten to add that Netscape 4.x's implementation of CSS is much worse; sometimes valid CSS would CRASH some of the 4.x browsers). Now they've released IE 6. Still not perfect, but adequate and productive for most users. The point of my writing about IE like this is that Microsoft has been able to, relatively quickly, revise their browser, whereas Mozilla/Netscape6 has basically become really useable only in the last 4 months or so (here's where I point out that I'm composing this in Mozilla under Linux).

So, I'd say that Joel's point is somewhat valid, and that Microsoft, in fact, does follow his logic, in most cases (Office, SQL Server/BackOffice, IE, etc).

Re:why are we listening to this guy?

[cygnusx]

>why are we listening to this guy?

Um.. possibly because this guy has a better track record that *you* do when it comes to pushing out reasonable quality *commercial* software, and on time?

Re:Code rewrite

[mav[LAG]]

Isn't there sometimes a happy medium between completely rewriting the whole codebase and continuing to hack it up?

This happy medium is described well by Bruce Eckel in Thinking in C++. He says in the chapter on design (paraphrased): "don't worry that getting some aspects of a design wrong will mean you have to rewrite everything. You won't - properly-written classes shield you from your mistakes." This is from the section that talks about the problems that occur early on in implementation, but applies equally to rewrites.

For example, maybe you can identify certain modules that can be isolated and rewritten, then tested rigorously against the old code to make sure they're functionally identical.

This is called refactoring and is now a widely-accepted industry standard practice for improving a codebase without rewriting it from scratch. The official web site is here.

NT was for nothing

[Sloppy]

No one seems to be taking up this position in their replies to you, so I'll give it a try...

Maybe NT really was a mistake. Maybe Microsoft would be even richer if they had just kept evolving Win9x and let it accrete more features.

Did Microsoft really gain anything from NT? I don't mean gain things that important to geeks (reliability, performance, cleanliness, etc), I mean gain anything that is important to being commercially successful.

Name one feature that NT has and 9x doesn't, which has resulted in increased revenue for Microsoft.

Re:Isn't it obvious?

[scrytch]

> IOW, have more money than God and throw it at any problem you're having trouble with

Didn't work for IBM in the early 90's, didn't work for Detroit in the late 70's and early 80's, still doesn't work for the government.

Re:why are we listening to this guy?

[Jester99]

This was win16. Excel is great now, but do you remember how much it sucked before office 95?

Win95 wasn't built in a day, you know.
Win95 development started around, oh, 1993 or so? Meaning he was in charge of the versions of VB and Excel/Office95 and whatnot that debuted concurrently with Win95 -- the same versions you praise.

Re:Rewrite vs compatability

[Enrico Pulatzo]

It seems from Joel's comments that code rewriting is totally a bad idea. I found his comments about not worrying about code size not too suprising, especially when thinking about microsoft office. Its a bummer that code just sits there and collects blocks of individual special compatibility cases, such as looking for an old DOS call or something similar. Eventually this code should be rethought, to reasses if these individual checks still matter. I seriously doubt, given the tone of the article, that this happens with suites such as office. Big bummer...

MS successfulness != code quality

[ortholattice]

According to Joel, the single greatest development sin a software company can commit is "deciding to completely rewrite your product from scratch, on the theory that all your code is messy and bug prone and is bloated...A programmer will whine about a function that he thinks is messy. 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."

My God. So this is what Microsoft code looks like? It's a miracle it can be maintained at all. This sounds like sloppy coding by trial-and-error, at its worst. Code filled with "ugly little hairs and stuff" that "nobody knows why" is almost a guaranteed recipe for buggy, unstable code. If all these "bug fixes" were properly commented to begin with there would be no argument as to why they should be kept. Thank God for open source, where programmers are _proud_ to show off their code (well, a lot of them, anyway).

I would attribute the successfulness of Microsoft, and the failure of others, to factors other than the quality of its code.

Re:MS successfulness != code quality

[simm_s]

You don't code much do you? The point is that the environment you are given may not work as told.

This sounds like sloppy coding by trial-and-error, at its worst.

Not always:
Example: The hardware on device X has a timing hazard under conditions Y. Even if your code is perfect it will not work under every condition (that is the real world). So under that condition you do something that seems to have nothing to do with the design under normal condtions. Voila! Problem is solved your code is more robust.

In the land of make-believe you can just ask the hardware maker to recall their million+ units to fix your silly little issue, but we live in reality.

Those "ugly little hairs" may not make sense to the 10th maintainer on the project that was ported three platforms ago (Even if commented). I've seen alot of opensource code and some of its pretty damn unreadble. I've seen libraries given with no api reference or samples, drivers with no documentation, and the list goes on. I guess "real men" figure it out just by reading the source. While wasting hours trying to get the code to work in their project.

Poorly documented open source is just as closed as proprietary code.

Re:Good point NOT

[cjsnell]

Coders who follow these rules produce what? 3000-6000 lines of code a year? Ain't gonna get product out the door that way. What you get is code with lots of comments about what it is supposed to do, but doesn't because of all the time spent on documentation instead of design and debugging.

Excellent point. My philosophy about commercial software is this:

Never forget why you're writing the code to begin with. The point is to get working, stable code out the door as fast as possible. Anything that does not accomplish this is a waste of time.

Doing your architecture work is fine, but do it on a whiteboard in your cube with your co-workers. Don't waste time holding formal design meetings and drafting useless documentation and diagrams because, honestly, nobody will ever read them.

Modularize/componentize your code as much as possible. Document what the module as a whole does and what data it requires and what data it returns . You shouldn't have to waste time commenting every single peice of code. If you''ve modularized and documented what the module does, any decent programmer can figure out the rest.

In addition to not hiring idiots, don't hire people who love to wallow in bureaucracy and process. Besides not getting jack shit done, they impede everybody else.

If you want to comment and spend hours drawing Visio diagrams, fine. Wait until after the product is released to do this. These do not accomplish the goal (see point #1).

Chris

Re:Isn't it obvious?

[scrytch]

You're utterly off the mark if you think you're going to provoke me into some Randroid rant in support of capitalism uber alles. Fact is, you know damn well as much as I do that the government does some things well, but other things it throws enormous sums of cash at are still extremely ineffective. You'll note I mentioned other behemoths that lumbered about throwing good money after bad, not just governments.

> The internet? Highways? Electric power (which failed privately)?

Show me a government owned power company in the USA. Regulation is not ownership, much (not all) of it comes because the monopoly was government-enforced in the first place, so they now have to control it. I work in a social service nonprofit, housing comes to mind as something the government consistently screws up (all the effective housing programs here are other nonprofits that don't receive government funds). This is all of course US-centric -- other nations governments might do some of these things well. It just further demonstrates that having the money does not mean it gets spent wisely in every case, which is the point you seem to be trying to sidetrack me from.

Thinking "simply"...

[DocStoner]

[1st and foremost: I use and support Microsoft products. The software and OS's work "OK". No further explanation or flaming is necessary.]

Everything this guy says tells programmers to consider the bottom line, the almighty dollar. This attitude works in other industries, but will eventually bite them in the ass. (Automotive anyone?)
He's actually giving us the directions on how to beating MS. So, if you are producing such and are in this to make a fortune today instead of tomorrow... take notes they will be invaluable... for the near future.
However, we all know this is the worst advice for those of us who use and program open source software. We want simple code. We want it to do just the basics. If it's too basic for you, here's the code, feel free to add to it.
Remember the automotive industry? Japan (and Germany) started out with simple basic cars and trucks. And the typical American car buyer? "They're so small, so plain and slow." Hmmm, now these little 4-cylinders are blowing the doors off of the bigger American cars. Because each time they built their cars, they started out simple and refined each part before they added on.
MS is winning today, but soon people will like their programs and OS's like they demnd their cars now, reliable and economical. It will happen, but how long will it take?

Hubris, laziness, and impatience

[ttfkam]

Let's compare:

for (i = 0; i array_size; i++)
free(array[i]);
free(array);

and now let's look at:

// get rid of the array
for (i = 0; i array_size; i++)
free(array[i]);
free(array);

Has your life *really* been so harmed? Is this *really* so terrible? Comments should not be written with the thought that your university professor would know what everything else means. Comments should be written so that all of those folks without a PhD in CompSci. know what it means.

What if the next joe to hit your code doesn't have a degree? What if the recently-hired intern was just handed a "C in 21 days" book and told by the manager to "fix it" because the programming team is snowed in (or similarly unavailable) and the customer is screaming? (Yeah, try and tell me that's never happened...)

A fine use of comments is (for example) every ten lines to say, in general, what is going on. One thing I used to do is write a comment at least every 10-15 lines. Why? When the next joe who comes along has to read/edit my code, scanning through some periodically placed comments will *always* be quicker and easier than reading the code. ...assuming they are English speakers of course. Proof? I have programmed (I don't count the BASIC years) for ~10 years. I have been writing/speaking English for over twice that long. Which do you think I'm better at?

The code effectively shows my implementation, but may not show my intention. I have coded for years. I started dreaming in code several years ago. Shortly thereafter, the code actually worked when I typed it in the next morning. That isn't the point. How good a coder you are isn't the point.

When you have a hundred thousand lines of code to go through, comments become like "Cliff's Notes." For the quick patch (probably the majority of code being written by most people), comments are invaluable. Who cares if I didn't read Moby Dick if I can still pass the pop quiz? If I need to make an indepth study, I can still do this, but thank god for the "Cliff's Notes."

Now then, on to the "proper" use of comments.

1. Write out what you are planning to do in English. (or whatever else may be the dominant language in your development group) Fill in every step in the problem. This is NOT psuedo code. This is akin to: Find out who www.yahoo.com is, open a connection, ask for the main page, and check to see if our cache is still valid. If the cache is stale (the yahoo page has been updated), get a new copy of the main page. If the cache is still valid, pull the page from cache instead. Drop the page into the "ready" bin and send a message to the user that the page is here.

2. Make a copy and label it "documentation."

3. Go back to the original, fill in all of the logic in whatever programming language at the appropriate points in your "documentation," and label it "source file."

This means that your documentation is done, your code is adequately commented, and your algorithm and intent(!) are clearly defined for both your co-workers (and yourself when you have to fix something ten months from now). If you can't spell out the problem and the solution in your primary native language, you sure as hell better not be trying to spell it out in a programming language that members of your team have only been using for two years.

The only excuse not to do the above is laziness. For some people, laziness is not considered a bad thing. It was noted as being one of the main virtues of a hacker -- hubris, laziness, and impatience. Hell, according to this measure, I myself am lazy from time to time. But cut the bravado, the beating of the chest, the battle cries of "I'm smart enough to figure this out, so should you be," and call a spade a spade. Avoiding comments means that you are being lazy.

Re:Hubris, laziness, and impatience

[Harri]

If your code is written so that it requires this level of commenting to understand, it is _crap_.

If you have a block of code that says

// do X
[ code that does X ]
// do Y
[ code that does Y ]
and so forth

Change it so it says

void doX(){
[ code that does X ]
}
void doY(){
[ code that does Y ]
}

// ....
doX();
doY();

Each function should do _one_ thing. Comments should be reserved for stuff which it isn't possible to express in the code itself.

Re:"never a good idea to do a complete rewrite"

[SoftwareJanitor]

while the POSIX system is just there as an afterthought

That is being generous. It is my personal opinion that Microsoft only included the POSIX subsystem in order to be "checklist compliant" to bid on government and commercial contracts that require POSIX compliance. Furthering my suspicions, they basically made the POSIX subsystem more or less useless by crippling it, and making it virtually impossible to run POSIX applications and Windows applications at the same time in any sort of useful manner. So bad was the POSIX subsystem that Interix and Cygwin were created to replace it as well as numerous other porting tools (WindU, MainWin), etc. Microsoft has since borgified Interix in order to make sure it never becomes any sort of serious way to wean Windows users off to other OSes. They want it to only be a one-way street.

Microsoft DO good re-writting !

[warloch71]

The first OS was DOS. Then came on top of that Windows 1, then 2, 3, and finally 3.1 and 3.11 At that point, someone at MS looked at the code and get sick. So They RE-WRITTEN FROM SCRATCH a complete new OS : NT, from which was born what is probably the best and most stable OS ever released by MS: NT 4. At that point there where two branch: the DOS legacy kernel (Win95, Win98, WinME), and the re-written kernel: NT4, 2K and now XP. I don't know where the non-rewritten legacy code of WinME is in ANY WAY better than 2K.

Chars and bytes arrays are both the wrong solution

[StrawberryFrog]

How many of you ever thought about getting your code to work on Chinese 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.

Nope.

The right solution, which many would take if doing it again today, is to do it all in Unicode.

the crack good?

[7-Vodka]

GOD man, if i'd written software that worked perfectly the first time like that, i would MOVE ON and do something else to sell. Also, if you've sold your software to all the people who want to buy it (i'm assuming this is your point, that plp already own your earlier working copy thus you cannot charge them again), then you should have made a lot of money in the first place.

Re:To succeed in commercial software...

[King Of Chat]

People should try putting some damn comments in.

Early on in my programming career, I was looking at such a piece of code - something which was simple when first written (in C) 5 years previously, but had so many mods, the function was pushing 1000 lines (ugh). Some guy had put in this change, commented it as "for performance improvement", then commented it out with an extra comment explaining that it was taken out because it didn't work. At the time I thought "why is this guy making himself look like a dick?". Later I got it - he'd left it like that just to stop some other poor bastard making the same mistake (it was a calculation thing which we were always pushed to improve performance).

If you do something wierd or clever, for f*ck's sake put a comment in (do as I say, nbot as I do).

Bloatware

[dreamquick]

"If you're a software company, there are lots of great business reasons to love bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make users' lives better (if they use them) and don't usually hurt (if they don't)."

The thing about bloat is that it's not a bad thing until it *kills* your product.

Lets say my product has been through several major versions and has a reasonable userbase - but is bloated & the majority of the users complain about it seeming slow.

Now according to that interview we should just learn to deal with this via moore's law rather than actually having the vender write code more responsibly.

However if my competitor introduces a smaller, less bloated product with more features than your product that also runs faster, then you run the risk of having the userbase start to convert.

Once that happens if you follow the rules from this interview you are doomed - you cannot rewrite to reduce bloat, you are not supposed to be interested in reducing bloat.

The only exceptions are :

the userbase has to be smart enough to appreciate what advantage any change would bring, otherwise they just act like sheep (the AOL arguement).

the product is not "sticky" - e.g. i can just copy all my existing content into the new system, meaning transition is painless.

cost of ownership is high - if i have to spend $200 to buy my product then i will naturally be reluctant to waste my investment / look stupid.

Moral of this story - only build bloated software if you have stupid users, or you have them pinned in a corner with no-where else to go, or if they paid through the nose to buy it.

Man, you are a bunch of sad, sad people

[bilboyablan]

Man, I have been a Slashdot reader for several years, and I have noticed before that the audience/posters really can be really acidic/negative at some times.

But this is ridiculous. All of you people nagging on Spolsky, have you at least read some of his articles at all? They are really good, suggest a pragmatic hands-on approach to software development, and are a real joy to read.
And please, I am not a Microsoft freak at all, but could you for once acknowledge that they have done some things right?

And you are really anal, focusing on small details instead of getting the point. What does it matters if Spolsky had this or that position at Microsoft, or if he in fact participated in active programming or not.
In fact he did, read
http://www.joelonsoftware.com/articles/fog000000 00 75.html (yes, I could have done a HREF, but I don't care about it, just copy the damn text and paste it on your web browsers address bar, I know you can do it).

You are really a bunch of sad whiners, and I am sick of you. Bye slashdot, I am tired of your inmature and negative crowd.

Re:API specs?

[CArmeanu]

Well, how should we understand your comment? If there is a bug within the API you use, just don't care and use it as documented in the specs? So you would try to sell/share/use some product that fails due to a lack in the API?

I think Joel is right and should not care about the specs. If it doesn't work, it doesn't and you find a solution to get around. The client or user wouldn't care why it doesn't work. He would simply stop buying your products and tell his friends and colleagues not to do so also.

But, this is exactly what he is talking about anyway ...

Chris

the Dodo

[Anonymous Coward]

The dodo died because man hunted them to extinction for pleasure (because "they looked funny"). Nothing to do with evolution.

Hungarian notation considered harmful

[beable]

Clear, Consistant Formatting: [...] variables use Hungarian Notation or some other standard

I find Hungarian notation much harder to read than not using it. For example, I find the Unix man page for strcpy which looks like this:
char *strcpy(char *dest, const char *src);
much easier to read than the Windows-style Help which is full of stuff like "LPCSTR lpBuf" and suchlike. The idea which is commonly called "Hungarian Notation" says that a variable name should include the type of the variable as a prefixed abbreviation in front of the name. This leads to stuff like:
byte[] baBuf;
whereas without Hungarian, it might be called:
byte[] message;
which would be much more meaningful.

Especially in object-oriented programming, the type of a variable is the least important piece of information about the variable, and has no place being abbreviated and prefixed to the name. The most important thing about a variable is what the programmer is using the variable for, and that information should be what the name of the variable tells another programmer. If somebody really wants to know the type of a variable, then their editor or IDE should tell them what it is. If it doesn't tell them automatically, then they should look at the variable declaration, which will state exactly what type the variable is. If programmers want the variable name to tell them the type, then what is the point of declarations? And why bother putting a comment near the declaration saying what the variable is for, because people aren't going to read the declaration or comment anyway, because they are just going to look at the Hungarian warts.

The argument that Hungarian notation reduces the possibility of assigning variables of different type to each other is long dead with compilers well capable of throwing errors if any incompatible type assignments are attended. I think that Hungarian notation is dead, or at least should be.

Re:Hungarian notation considered harmful

[CounterZer0]

This leads to stuff like:
byte[] baBuf;
whereas without Hungarian, it might be called:
byte[] message;
which would be much more meaningful.

Or you could do this:
byte[] bamessage;
whereas without Hungarian, it might be called:
byte[} Buf;
which could be much less meaningful.
If you're going to knock on something at least do it correctly. I agree, Hungarian notation can be harder to understand sometimes, but other times, it makes more sense. Plus, it enforces a STANDARD naming system, not just 'This looks good to me' conventions. BTW: Unix man pages are usually easier to read than windows help for just about anything ;)

Re:Hungarian notation considered harmful

[A.Gideon]

Embedding type information within variable names is an artifact. It stems from poor coding practices, which permit great "distance" between declaration and use. It stems from poor tools, where these tools don't facilitate locating a declaration.

This practice is also inefficient, potentially very so, in that redundancy is being increased. Worse case, some function's name must be changed because of a change in the return type (or argument list).

There are such changes - depending upon the language being used - that will not require alterations in the calling code. For example, if a return of type T is changed to return a type derived from T (which therefore supports the full T interface), then callers remain uneffected. But if the return of type T was embedded within the function name, then all calling code must be changed.

Expensive.

Re:Isn't it obvious?

[markmoss]

while MS improved their software, the other companies rewrote their software. Improved??? If you are talking about anything since DOS 6.2/Windows 3.1/Office 4.x, don't you mean "Fixed a _few_ of the old bugs, added many new bugs, added features no one uses, dumbed it down, and made it incompatible with the previous version so eventually people who know better will still have to downgrade to the new version to stay compatible with the idiots they have to work with."

Re:Chars and bytes arrays are both the wrong solut

[TheSliver]

The anti-Unicode stance, which tends to be wholly American is interesting since before the attempts to unify character set encoding there was complete chaos in non Roman character sets. This wasn't thought at all interesting or useful because it didn't affect US english software.

Each of the language systems had their own methodologies and for some multiple encoding schemes.

Unicode is a painless way to protect your app from different character set operating systems so long as it is implemented at the core. Bolting it on afterwards is nasty.

The real reason MS really whacked WordPerfect

[jyoull]

OK so I sold computers and software during the time that this all went down and this is what happened...

1) WordPerfect for DOS, coded in assembly language, was one damn fast, tight, piece of work. The best word processor for DOS, hands down, no question about it. Everyone used it.

2) MS and IBM announce OS/2. I go out and buy a big fat book about "Programming for OS/2". MS starts pumping the application developers to build OS/2 products. At this time, MS Windows 286 and 386 exist, and MS says they're to be phased out in favor of OS/2, the future of operating systems.

3) Fast forward a couple of years, not too far... MS dumps its OS/2 partnership with IBM and releases new versions of Windows, saying that Windows is now the future of operating systems, and they don't need IBM's help. Shortly after this, Word for Windows 1.0 magically appears. WordPerfect Corp. sends a letter to all its dealers that says (paraphrasing from memory) "MSFT told us that OS/2 was the only OS we needed to code for, we believed them, and consequently we have no Windows product at this time... but we're retrenching and will put out WP for Windows as soon as possible. Oh shit."

So, this game was not lost to assembler EXCEPT in this sense -- if WP for OS/2 was written in assembler lang. instead of something higher up, a quick port from OS/2 code to Windows code would have been impractical or impossible. Would love to hear from some of the WP developers about what actually went down around this event.

Re:To succeed in commercial software...

[ericsink]

People here are missing the whole point. Everyone seems to be saying that programmers don't read code because the code is poorly commented. Ridiculous.

Joel is right. Programmers don't read code because they don't like doing it.

Most programmers act like the universe revolves around them, apparently believing that their job should never ask them to do something that isn't fun.

It doesn't matter whether the code is well-commented or not -- it usually needs to be read. The natural tendency to read code is an excellent way to distinguish the best developers from the rest.

Bad point

[quark2universe]

Repeat after me ... Job security is a fallacy. It does not exist. It never has and it never will. It is supposed to be your protection from being laid off, right? If your company has any least little bit of financial struggle and they want to appease Wall Street, LAYOFFS. You're not safe. "Job security" is a lousy excuse for not commenting your code.

Re:why are we listening to this guy?

[Anonymous Coward]

This is from Excel's help file for the mod function:
--Returns the remainder after number is divided
--by divisor. The result has the same sign as
--divisor.
--
--Syntax
--
--MOD(number,divisor)
--
--Number is the number for which you want to
--find the remainder.
--
--Divisor is the number by which you want to
--divide number. If divisor is 0, MOD returns the
--#DIV/0! error value.

3.1 divided by 9.3 = 0 remainder 3.1 so mod is 3.1
9.3 divided by 3.1 = 3 remainder 0 so mod is 0

If you can't read documentation to determine how a function should work you might be the reason a software project fails.

Re:Good point NOT

[dazed-n-confused]

After the product is released, nobody will allow you the time you'd need to write comments or user documentation or Visio diagrams. The only effective way to produce documentation and commented code is to generate it as you go along.

I'm surprised you haven't yet been modded down as a Troll, you are so far off-base. See Dave Parnas' "Software Fundamentals" for a detailed exposition of why your approach is wrong, wrong, wrong.

Your objective should be to get working, stable, maintainable, supportable code out of the door. This means it's commented and documented (and, yes, diagrams count as documentation). If you fail to do this, you're failing your users and (ultimately) your company.

Job security?

[LinuxParanoid]

Dude, think about what you are saying. Do you want to keep maintaining your old crappy code or pass that job onto someone else? Or do you want to go write some new code?

Your perspective assumes your company requires a fixed amount of software. Think more imaginatively.

Better documentation means you can shove maintenance to a more junior programmer with less pushback.

Also, without good documentation, its a b*tch to try to outsource/handoff pieces of the code you don't want to bother writing.

Besides, I don't care how well documented your code is, you should always be able to convince a boss that its more efficient for you to make changes to it (even at higher salary) than some cheaper guy who has never seen the code before.

--LP

Death March

[beanerspace]

Ed Yourdon wrote a book a couple of years entitled "Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects".

Whenever I hear of a software project failing, I think of this book because it explains in gory details what happens when software is treated like fast food instead of architecture.

When Joel Spolsky gripes about "re-writing" as the cause to failure, he's both right and wrong at the same time. Rewrites don't kill projects, MISMANGED rewrites kill projects.

There are some other points that raise my suspicious about Spolsky's training and experience. Since the 90's, there has been a big effort in the industry to develop large scale products with some semblance of reuse. Hence, one of the determinat reasons for the lurch into object oriented program.

Spolsky descriptions sound to me like he's still thinking of code, and of failed projects that were lacked modularity. Nor did he give much attention to other major factors such as FEATURE CREEP, where a small system becomes spagetti over years and years of maintenance. Same with scalability, challenges definately occured in the past decade or so with the massive changes in processors, operating systems and their associated APIs/internals.

But again, it all gets down to one's approach. If you treat software development like you're flipping burgers for the lunch crowd, then you're going to have to deal with the indigestion that comes along with building a house sloppily.

Differing goals

[bakuretsu]

I think a lot of people are confused into thinking that quality software makes successful software. This could not be further from the truth.

True, successful software should *work*, but that doesn't mean there isn't a less commercially successful software package out there that just works better.

Case in point: BulletProof FTP for Windows is a highly acclaimed and highly successful FTP client. Their marketing strategies are right on the mark, and thanks to this, they have raised the revenue required to maintain their code, their website, and even acquire G6 FTP Server from Gene6 Software.

BulletProof FTP is commercially successful.

I, personally, use LeechFTP, it's distributed as freeware, and isn't even supported anymore. Sure, it has it's quirks, but it didn't cost me anything. Commercially successful? No. Quality programming? Yes. LeechFTP is the only FTP client I know of to implement a multithreaded design for uploads and downloads, a feature that I use daily to transfer entire website directory trees (having three simultaneous logins to the FTP helps drastically).

LeechFTP was never marketed to produce a profit, and if it were, it would fail. BulletProof Software undoubtedly followed all of the cut-throat and low brow schemes that Joel outlined to maintain their market share and draw a revenue. That doesn't mean their product is no good, but to some extent the goals of producing quality software and producing PROFITABLE software have to be separated.

Microsoft has built themselves up to a point where they can spend enough money to retain enough programmers to keep their products working as well as Mr. Joe Average requires for his needs. That is a luxury for them. Without those resources (or the help of many dedicated programmers that will work for free), other companies will have a very hard time balancing those two goals.