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 .
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!
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.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
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), 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.
Potato chips are a by-yourself food.
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...
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
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.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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...
No, I'm not cynical. Honest.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
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.
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.
> 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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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
Let's compare:
...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?
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.
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.
- I don't need to go outside, my CRT tan'll do me just fine.
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).
This sig made only from recycled ASCII
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.
...
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