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 .
SMS: Joel, what, in your opinion, is the single greatest development sin a software company can commit?
Joel: Deciding to completely rewrite your product from scratch, on the theory that all your code is messy and bug prone and is bloated and needs to be completely rethought and rebuild from ground zero.
SMS: Uh, what's wrong with that?
Joel: Because it's almost never true. It's not like code rusts if it's not used. The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it.
Joel blasts rewriting code some more, but doesn't really get into alternatives. Instead he talks about forcing programmers to get with the program, and if they don't, fire them.
Isn't there sometimes a happy medium between completely rewriting the whole codebase and continuing to hack it up? 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. Or you could separate the old code into a library that just does the computational part of a program, and then write a new GUI around it from scratch.
He takes Netscape as an example, saying the worst mistake they made was to rewrite it from scratch.
I admit that it would have been nice if they released the source code to Netscape 4.x, and not just Mozilla. Even if the code was the most gawd-awful thing in the world, in the years since Mozilla started don't you think we (the open-source community) could have at least fixed some of the more annoying bugs in Netscape?
Actually, NT was a completely different product line (servers, high-end workstations), with the eventual goal of replacing another product line (home PC's). Now, with XP, the "old" product line has been depreciated. It's also not ridden with 16bit code from the DOS era, as your post implies. Keep in mind that there's a difference between rewriting functionality, and even emulating functionality (for backward compatibility), then a complete rewrite of the entire codebase (in the millions of lines of code!)
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
The support for OS/2 in NT is fundementally different to the DOS/Win16 or POSIX layers, even by what MS says.
The Resource Kit says that the only subsystem you have to disable to get C2 complience is the OS/2 system: ie it's the only one that calls directly to the kernel. The DOS/Win31 and POSIX systems do not call to the kernel.
NT4 kernel has ONLY OS/2 compatibility. The bulk of the operating system is not available until the shell loads and the user logs on.
All os2ss.exe and os2.exe do is shunt the calls direct to the kernel for execution. The file in question is there for OS/2 apps to call if they want console messages, it is a MKMSGF file, after all.
But the technet seems to go a fair bit into OS/2 and the subsystem, while the POSIX system is just there as an afterthought. "We support POSIX".
No, NT has correct version numbers because they follow from OS/2.
OS/2 - because choice is a terrible thing to waste.
I agree with you up to a point with IE. Microsoft certainly isn't making any money on it, and doesn't look like they have any idea how. But the difference is that a company with a monopoly to fall back on can afford to keep around loss leaders whereas a startup can't. In the case of IE, I believe that Microsoft can, and is, trying to use it to leverage into other markets by trying to build proprietary lock ins to their .NET server products and lock everyone else out of those markets.
I have to admit, my rant wasn't intended to target you specifically. It was more of a general rant. Maybe I'm just cranky because k5 is still down.
:-/).
;-)
And I agree that comments aren't a substitute for documentation. Use cases and UML don't lend themselves to source code comments. However, my comments about "Cliff's Notes" still stands. Comments judiciously sprinkled within code helps casual scanning for meaning much faster and easier no matter your coding skill. Coding skill simply speeds the case where comments are not present.
In answer to your question, while certain logical constructs are best expressed in code, overall concepts are usually just as easy if not easier to express in a natural language.
Unless you are writing programs and libraries that are only going to be used from end to end by other programmers, the outside world is dictating needs, requirements, and problems. That outside world speaks a natural language. If you cannot map the problem set and the solution set to a natural language, I submit that you do not have an adequate knowledge of the problem.
However in this case, comments would be a side effect.
Programming languages describe and work with the nuts and bolts. No programming language that I am aware of is sufficiently abstract to directly map to complex real world problems; no creative use of partial template specialization in C++, dynamic classloading in Java, dynamic function definition in Scheme, etc. can do this.
Conversely, no natural language that I am aware of can adequately describe a truly logical, deterministic domain either (just check out legal documents for proof). There needs to be more translation between the two.
For now, those bridges are comments and documentation.
-----
For a less abstract argument, let's leave computers out of it for a second. Two people from Indianapolis can communicate with each other better than either can communicate with someone from Sydney. They all speak English, but the dialects, the idioms, and the inside jokes may not translate. So when we write for general distribution, we try to keep those local colloquialisms to a minimum (and no, I admit that I haven't been a perfect example of this in my posts
Now keeping this analogy in mind, a programmer has an intimate relationship with a computer/compiler/system libraries/whatever. Together they have many inside jokes, goofy idioms, and function prototypes that mean absolutely nothing to someone else who, not being necessarily stupid, simply has a different focus or area of expertise.
While it may be more effort, and it may reduce some of the free-wheeling fun you would have had if you were alone with your CRT, doesn't it seem appropriate to make it more comprehensible if for no other reason that to allow others that specifically don't know as much as you to learn from a good example? Wouldn't that help to encourage others to continue using your code instead of scrapping it just as the interview topic suggests? Wouldn't it help to keep a few less wheels from being reinvented?
Maybe I'm too idealistic. Maybe I'm just not jaded enough. But for me, part of being a lead software developer or a senior software engineer or a project lead is not simply to crank out a mountain of code while others look on and a select few help out. We don't code forever. Some of us get sick of it before too long. Some go into management. Doesn't it make sense to try and *teach* the ones coming up to do what we do? For me, it does. But, again, I am lazy sometimes. A few extra comments means that more than half of the time, I don't need to be asked what something I wrote was intending to do regardless of whether or not they are as good a coder as I am. They just read the comments.
...I'm also prone to being long-winded.
- I don't need to go outside, my CRT tan'll do me just fine.
In answer to your question, while certain logical constructs are best expressed in code, overall concepts are usually just as easy if not easier to express in a natural language.
This is more or less what I was trying to get across (not all that effectively, I guess); comments are most helpful when they give the reader more information than they can easily get from reading the code, and code that's easy enough to understand without comments shouldn't be commented "on principle". I guess it's just that my idea of "easy" is a bit different from that of other people. <shrug>
At any rate, I do comment and document my code (or at least, I'm trying to do better than I have in the past), and I agree with the point you make with your Indianapolis and Sydney analogy. I guess I'm just cranky today, too...
Comments should explain WHY, not HOW.
If all the comments are doing is telling you exactly what you already knew from being moderately literate in the language, then they are just ugly chunks of text that get in the way of reading the program.
But that doesn't mean verbose comments are bad. If the verbosity is dedicated to telling you *why* something is being done, rather than giving a play-by-play description of how, then it is very useful. If I see a for-loop that counts backward from ( array_size -1 ) down to zero, don't give me a comment that says "counting backward in a loop". I can TELL that. But what I can't necessarily tell at a glance is *why* the author chose to count backward instead of forward - what was the algorithmic purpose to doing it that way - THAT is what I want to see comments explaining. And with THAT type of comment I am very happy when it comes with a lot of verbosity.
The worst examples of useless verbosity are when you see code written by someone who has *just* learned a new programming language and is unfamiliar with the "culture" of that language. They tend to document things that everyone already knows like the back of their hand. (For example, a novice C programmer tends to go into excessive detail about the use of null chars to terminate strings.)
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Like Joel, I have been programming for 20 years, so I'm certainly not trolling just because what I have to say isn't the in thing with the core of the Slashdot audience.
I read Joel's interview yesterday, before it was mentioned here. Good interview, I thought, he makes lots of good points. But the debate about it here has nothing whatsoever to do with what was said there. Many of the comments key off of the word "Microsoft" and so immediately assume that the interview is crap and has something to do with justifying Microsoft's monopoly position (are these people really bots?).
Most of the the comments, though, are taking little bits of advice and twisting them around into mini-lectures about commenting style or programming issues, or they're simply being used as jumping off points for the poster's own spouting. Let me make this perfectly clear:
These people are not professional programmers.
Anyone who has been through the wringer of commercial software development, and not just a few classes and some tiny open source projects, wouldn't be so religious about such trivialities. Real software development is different. It is not a battle between the Evil Bad Commenters and the Perfection of Beautiful Computer Science (or more correctly What My Professor Said in Class Last Semester). That's not how it works at all. All programmers know about commenting, about indentation style, and so on. There's more to developing commercial products, though: deadlines, missed features, last minute requests from the client, strict requirements for supported platforms, and so on. In this kind of environment, commenting style is a very minor issue (not to say it isn't important, but ranting about it is like ranting to an experienced guitarist about your pet music theories--when you barely know how to play guitar at all). A good way of spotting such people is to ask them what they think of "goto." Odds are you'll get all sorts of vitriol about the evils of goto and the benefits of structured programming and how you should never, never, ever, even if your life depended on it use a goto. An experience programmer would shrug and say "sometimes they are useful, sometimes not."
My advice: Learn, practice, work on projects, and over the years you'll become a pro. A college student without significant software engineering experience is not in a position to rant about how commercial development doesn't fit his ideals. The true sign of experienced developers is that they've been through it all and have enough experience that they don't feel the need to rant every chance they get--or at all.