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 .
people tell stories in boiler rooms?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Microsoft comes up with some similar product, markets it, and all the world's joe q zombies follow along and MS ends up driving the original vendor out of biz
I imagine the interview goes something like:
Joel: We drove them all out of business.
pooptruck
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!
1. Come up with a really cool and useful idea.
:)
2. Implement said idea, and tell others about it.
3. Build a solid piece of software and test it.
4. When Microsoft notices, refuse to sell out to them.
5. Be crushed under the weight of a mighty monopoly when they throw their machine at you and give away a product that does the same thing as yours for free.
6. Try to play the "release often" game against Microsoft.
Repeat steps five and six until desired failure is achieved, or until your stockholders turn into an angry mob, whichever happens first.
Wheee!
-- Twilight1
Step 2: Put him in charge of software development.
Step 3: Do nothing as priorities change weekly and deadlines slip away.
Step 4: Do nothing to stem exodus of clued-in employees to less-screwed companies.
Step 5: Force remaining employees to work 15 hour days. Provide subtle reminders that there's a recession out there.
Step 6: Do nothing as even non-clued-in employees flee.
Step 7: Hire a sweatshop in China to crank out code; present this sound like a good idea.
There, that was pretty easy. And, to be honest, everything beyond Step 1 pretty much happens on its own.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
I'd HIGHLY suggest reading a SoaNM. One of my favorite books (fiction or non).
No sig for you.
So, will it make the main page next week when he talks about how "bad" Linux and Mozilla are? As the backseat editors like to say, "Rob, start spell-checking that title now; you know it's coming."
For that matter, i wonder what he'll have to say about Linux. Ten years and they're still on version 2.[4,5]. That might actually make him happy.
One might ask the same about birds. What ARE birds? We just don't know.
Alot of .com's I've worked at in the past 2-3 years always wanted to "lowball" developers and engineers, while lining the pockets of resource managers, implementation managers, marketing people, etc.
/. - so I'll probably take a big hit on the karma - but I just was the casualty of another dotcom failure - and this was a seriousl problem.
Then a skilled/talented developer and/or engineer wants more money. The employer does nothing to retain them - thus the skilled/talented employee leaves.
Now who maintains the code?
The other problem is bringing in short term consultants for long term projects. The non-technical people who make these executive decisions don't seem to see the feasability of KEEPING their code maintained by the talented/skilled person who BEGAN the development on it.
I know alot of consultants read
Another problem is hiring non-technical managers to manage technical people. At my last job we had a manager off of an automobile manufacturing production line quit his job at the auto company to take a job as the manager of a group of Unix admins. This "bumper jockey" had NO CLUE what we did for a living, and treated us like a bunch of unionized UAW slobs, and not like professionals.
How can a non-technical boss effectively manage technical people???
Also - how about all the Ceo, Cio, Cto, eieio - types with their big salaries, catered lunches, etc... Alot of them have NO programming or hands-on technical experience. Hell - I've had the CTO come up to me and tell me that "The Internet was broken" when he knocked the dongle out of the side of his laptop - severing the network connection. And this guy is our Chief Technology Officer???? *lmao*
I'm not saying that only technological people can make technology companies work - but I do feel that managers should take some sort of hands-on classes to learn some basic programming and internet skills so they have SOME SORT OF CLUE about what WE all do for a living!
[Connection closed by foreign host]
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.
Obviously, MS biggest problem though is that they don't know when to give up and actually rewrite. For instance, it seems that the windows series of operating systems are all made with the intent of being backwards compatible and reusing core parts back to early DOS systems. Backwards compatability and code reuse is nice and all, but there is a limit to it and a time to give up.
It will however be interesting to see what comes out of the "total rewrite" of IIS.
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
Have a product that competes directly with Microsoft...
Bob Abooey is getting stories posted on Slashdot?
Now I've seen everything.
--perdida
Joel's company goal is to be bought out by Microsoft. No, I don't know this for sure. But when writing that much it's hard to hide your opinions.
ahem. what was NT for? sometimes, you just have to come to terms with the fact that as tested, bug-fixed and studied as a chunk of code may be, it was developed as part of a misconceived model of either visible functionality or internal architecture or both. DOS and its progeny like win32 were clearly cases of this, and MS weathered a complete rewrite c/o cutler and co. quite happily. the fact that there are examples of disastrous complete rewrites doesn't mean that the examples that worked are meaningless.
Rather then discuss it on a direct finance approach, this article discusses the merits of finance as a regard of speed of production, as well as ease of use.
Don't forget:
7. Rewrite your codebase from scratch and disappear from the market for 3 years
8. Beg the "open source" community to do your coding for you.
Joel didn't mention it, but a big reason that MS ate everybody's lunch (in the early 90's, anyway) was that the other products totally sucked. Excel rocked, and 123 for Windows was late, buggy and difficult to use. Ditto for WordPerfect for Windows. Ami Pro was about the best word processor - except for Word.
Just so's that we don't forget the good ol' days...
I've been a fan of Joel's work for a while now, and he seems like a smart guy who believes in DTRT. It's hard to believe people like that work at MS, given the quality of most of MS's output. But I know another MS programmer, and he too is a very smart guy with a sense of morals and a sense of the Right Thing. So where's all the evil come from? Or is there something I'm missing in all this?
Use VB
This is just more idiocy. What a ridiculous waste of time. I haven't figured out the optimum solution to the problem. I have to roll it around in my head and then come up with a High-level design doc but you want schedules down to the hour level... yeah right.
True, MS's monopolistic policies notwithstanding:
... IMO anything Real makes has never made it out of Beta, and naturally, don't unload the stupid System Tray icon that leaks memory like a sieve, because "you could lose some key features and performance benefits."
... but come to think of it, the only people to blame is Microsoft's competition, with their heads up their asses who can't put out decent software that works. Windows 95 didn't become the standard because it was great software, Win95 became the standard because OS/2 was marketed improperly, and IBM didn't work hard enough with OEMs. (that's gonna bring on flamage, so go ahead)
... I hate Microsoft as much as the next guy, having to put up with their software, but then again, I don't see many other "competitors" really trying ...
.... heh...
"Everyone thinks, poor Netscape, they were a victim of MS practices" - yes, they were, and yes, they innovated, but come to think of it, NS4 was crappy software that sucked.
"Poor Real Networks, MS is integrating all that stuff into the OS." - Good riddance
We blame Microsoft because their software sucks, and their practices suck
Only now, with Linux and Open Source, can WE the users contribute to what we want, not what some guys proposed business model wants. I mean seriously
ICQ pioneered instant messaging, but give me a break, the things been in beta for years and uses up more memory than most anything.
My note to all burgeoning software companies - Make me something that doesn't suck,and I'll pay for it, don't force me to upgrade every 20 minutes to a more bloated piece of crap that is nothing more than a "portal" for all those neat advertising engines you've snuck in there....and I swear, if I hear someone say "monetize the desktop"
Firstly, that code is harder to read than write.
Writing code takes heaps long than reading code, and how can you write code if you arent capable of reading code fluently.
Secondly, if a program gets really old then rewritting the code can improve quality heaps... patches are just that patches.. the rewrite should include the patches.
Thirdly, this guy used to work for microsoft, what would he know about writting quality code ?
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.
If he said "Microsoft ate their lunch" one more time, I was gong to puke my lunch all over my keyboard.
Anyhow, I think he speaks horrible advice from a computer science standpoint. "It dosen't matter how bad, buggy, cludgy, and crufty a code base is, never ever rewrite it". If you don't understand what the code is, if it's impossible to read, don't worry! that's the sign of good code!
It speaks alot of Microsoft's tactics, do whatever it is that takes the absolute least effort possible, and charge as much as you possibly can for it. All of those other companies failed because they were focused on quality, whilst they were focused on nothing the bottom line.
Here's what I think is the worst software sin: writting shitty code and pretending it's not shitty. Regardless of how much gloss you put on it, bad code is rotten to the core, and it reflects that in stability and security. Why on earth do you think Microsoft falls flat on its face in those areas?
I remember a story about JD Rockefeller. He was touring one of his oil works, and he saw someone soldering the oil cans shut. He asked him how much solder he uses on each can. The man told him, something like 48. Rockefeller said "from now on, use 36". That's exactly the type of cutting corners companies like Microsoft do. THat's not good for the customers, it's not good for society, and it's not good capatilism.
Jordan Bettis
``Wherever you go, there's another stupid sigfile quote.''Yeah, and you should take some sort of hands-on classes to learn some basic business management and finance skills so you have SOME SORT OF CLUE about HOW the rest of the world works.
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.
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?
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.
With your average application from scratch rewites are probably UnCool for the reasons mentioned in the article.
... the infamous 1 in a million "random" crash, etc.)
...
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
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
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
"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????
.....
Ten quid, she's so easy to blind. And not a word is spoken...
Hold on, this man worked at Microsoft from 1991 to 1994. He led the Excel team. He led the VB team. This was win16. Excel is great now, but do you remember how much it sucked before office 95? And who the heck used VB for 3.1?
Even better! he wrote the Juno e-mail application. Believe me, this was no fine engineering here. Why does he know better then anyone other Tom, Dick or Harry what makes software project tick?
http://kered.org
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...
Projects fail because people have good Ideas but can't ever get them on the market because either, people can't accept it because it is above their head, or it wasn't practicle.
You Don't have to burn books to destroy a culture, you just have to get people to stop reading them. Ray Bradbury
Granted, Joel has written some interesting articles in the past but this interview screams of hindsight.
How about something new and interesting?
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.
From the interview's lead-in material:
At Microsoft, the job title of Program Manager is given to the people that design the software. They dream it up, write the specs, hold countless meetings, and basically lay the path for the developers to follow. The developers (Software Design Engineer) are tasked with actually programming that software (and thus would be considered "programmers"). Just to round out the roster, the Software Design Engineers in Test (SDET) write the testing suites used by the test teams, and the Software Test Engineers apply those suites to the code following a test plan that they create. In that heirarchy, only the SDE and SDET jobs could be accurately described as "programmers".
Note that this is actually not so cut and dried, wherein SDEs often do design work and test work, and SDETs often do the work of SDTs. PMs don't program, however (well, aside from javascript&html prototypes, anyway).
The point? Calling this Joel an ex-Microsoft programmer is misleading, because he was not. However, the position he held at Microsoft actually lends more credence to his views on design than if he were actually an ex-programmer, as part of the job description of a program manager is doing software design.
(Brief descriptions of all these job titles can be found at Microsoft's college site.)
Hmmm....one interesting thread in his article was that Microsoft was able to beat their competitors (in the application space) not with any evil, monopolistic scheme. Instead, Microsoft's software development was less incompetent than their competitors. The two greatest words in the English language! De Fault!
Well, I guess the more-incompetent competitors can always "buy" a nice government lawsuit. That'll make it even.
-Donut
However, I feel slimy for just reading that stuff. Here is what I got:
1. Bugs are fine if they get your product delivered.
2. Load in useless features to drive sales, knowing that your code will suck.
3. Once you have gobs of crap code and a large user base, there will never exist the possibility of re-designing things (eg, WinXP) since it doesn't matter that code sucks (see point 1) and all that counts is revenue.
4. Being efficient is a waste of time. Let the hardware catch up with the crap code.
5. The customer never has valid input anyway.
6. Do it fast and furious, even if January 1900 is broken. Consumers are idiots anyway.
These may be great for sales, but ultimately you will build crap. Garbage in, garbage out. I would rather design good software that was well designed and efficient than vomit up mounds of bloat that will ultimately topple under its own weight.
Software built poorly will never hold up over time. If you look at how little UNIX has had to change over the past 30 years to keep up with "The Internet Age" versus the amount of work done to get XP "working", the future looks bleak for Microsoft. In 20 years, their OS need 25GB of RAM simply to boot up. Of course, this seems not to concern them.
----- Refactoring is the reason why man does not mistake himself for a god.
Yes, there are a lot of companies who have been squashed (or, as Joel would say, "Had their lunch eaten") by Microsoft in large part because of Microsoft's money/marketing, but there are also a lot of companies that nose dived into failure because of their own ignorant business and technology decisions.
While Microsoft may not like the costs and annoyance of court cases and DOJ action, it must give them some satisfaction because most of those companies bringing suit against Microsoft are doing so because they think that's their best option. I would argue that for these plantiffs making better products would be a "better option."
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
How To Make Software Projects Fail?
How about asking Microsoft. They seem to do this every chance they get.
The evil comes from the top, not the guys who are hacking out the code. Those guys are not the problem , it's the bloodthirsty evil bastards who run the company that we hate.
- Hire a bunch of people who don't share fluency any one language in common. Throw them all together and make no provisions to improve communication.
This is happening at my comany -- we're roughly 50% Chinese and 50% Americans/Canadians (not all white, but all native english speakers). We can't communicate very easily because the Chinese don't speak much english and the rest of the company doesn't speak much Chinese.
So, we end up just trying to work around each other -- since we only have two people who speak both languages fluently, we have to pick and choose how we use 'em. Pretty dumb.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
Actually, as long as the non-business engineer does his job he's a lot less dangerous than the business people who refuse/ are unable to understand the limitations in engineering. Unless, of course, the engineer is *shudder* in charge of schedules or budgets.
"Can I say you're my lovepuppy?" Founding member of SODAMNHOTT
Asians can be good coders. They are like worker ants in that respect. But I would not rely on an Asian to come up with a creative design or great product idea. Their minds don't work like that.
or (4), given the current state of the world economies, all the coders are trying to keep a bit of job security.
moores law is not going to be around forever, and if you take it
away, just about everything he says is crap.
he treats people with old computers with as much disdain as
gnome programmers do, its pathetic.
Let's have a close look at the costs involved when running a Linux system.
An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.
Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.
According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).
The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.
Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".
The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.
I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.
Design it using Linux... youll spend more time fixing Linux than writing your program
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:
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."
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.
I was just going to say "hand them over to me," but if you want to get all technical and long winded, be my guest.
-- Minds are like parachutes... they work best when open.
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
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.
Linux advocates are in a no Win situation
It's supposed to be a simple function to display a window or something, but for some reason it takes up two pages and has all these ugly little hairs and stuff on it and nobody knows why. OK. I'll tell you why. Those are bug fixes. One of them fixes that bug that Jill had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes a bug that occurs in low memory conditions. Another one fixes some bug that occurred when the file is on a floppy disk and the user yanks out the diskette in the middle. That LoadLibrary call is sure ugly but it makes the code work on old versions of Windows 95. When you throw that function away and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
Now, maybe I'm just ignorant because I've never really developed anything with the 640k barrier or had to haggle with XMS and EMS and other whatnot, but it seems to me that those bugfixes are needed because there's something else fundamentaly wrong with the code. IMO, sometimes you just have to rewrite, because your code is just fundamentally wrong.
Take DOS, for example. Microsoft added Windows. Then they made a bootloader, added real multitasking, and called it Windows 95, which wasn't that bad. Then they made some fixes, and called it Windows 98, which supported newer hardware, but was more unstable. Then only God and the developers at Microsoft know what happened to Windows ME, but that's when the bugfixes started causing bugs themselves. I mean, plugging in a USB printer shouldn't freeze the entire system!
Microsoft knew that they had a fundamentally wrong approach to an OS, so they wrote NT, 2K, and are new phasing out ME in favor of XP. XP replaces ME because ME is crap. However, this dude doesn't seem to realize that his own company isn't following is "wisdom."
Maybe I'm just cynnical, but I wonder if there is some kind of ulterior motive here.
Join the Slashcott! Stay away entirely Feb 10 thru Feb 17! Close all tabs to prevent autorefresh!
I agree with one of these.
3.) Actually, if there is one lesson we have learned in the past 20 years, it is that hardware vendors have an almost impossible time making people recompile.You need only witness the design of IBM's OS/400 platform, which places a thin layer of microcode between the processor and the OS, the problems Intel has had in generating support for Itanium, and the transition to Java/C# from recompiles on every platform. You can innovate, but you had better not break compatibility with the existing platform.
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.
--tkr
Guys, if there's one thing we've seen, it's that good software does not always = profitable software. Like it or not, the big money is in programs like Windows that may not be all that great technically,. but have the marketing and OEM contracts to force it into becoming a standard.
Likewise, Juno wasn't great from a technical perspective, but that's not why it's a giant FUBAR. It's the business model that's crippling the company - how many times do we need to see that even limited ad-sponsored ISPS Just Don't Work.
Would I go to Joel for advice on how to actually write code for a given project. I don't think so, no - he's almost certainly a good programer, but there are plenty of other people out there who're probably more skilled. But from the perspective of managing software development - well, Joel does have a lot of experience doing THAT successfully (at least at MS).
One last thought - I wouldn't hold Juno against him as proof of business stupidity - he wrote that client in a simpler time, an innocent time. A time when click-throughs really were worth something - or so the marketing mavens thought.
I'm the stranger...posting to
He's not talking about the Mozilla project, he's talking about the transition from 3.0 to 4.0. Basically Netscape threw away a lot of good code and some very nice algorithms for the sake of newness. They also developed a java fixation while the language and libraries were still very immature.
By the time the Mozilla project was announced, Netscape was already out of marketshare and had a product that was cleary inferior to ie 4. Considering the amount of bugs in the initial release of ie 4, making an inferior product was no easy feat.
Jamie Zawinski has a great deal to say about this period in Netscapes history.
--Shoeboy
Just hire an open source advocate to finish do the project. It will no doubt fail miserably. As an analogy, look at how Linus messed up Transmeta.
This is a troll for those that don't get it.
He writes about the reasons other companies were bought out by Microsoft. When he worked there he noted that the most appealing things to Microsoft were both a codebase and interface that Microsoft might produce (see FrontPage buyout). He has emulated this in his web content sofware, Citydesk, at the expense of his product. Above all see how the software isn't advertised - that's not its' goal.
His general esteem of Microsoft seems a little too warm. Sure, he worked there, but he didn't get at all annoyed and only blamed himself when the Microsoft FTP library couldn't do passive transfers. He didn't move to another FTP library that would do the job - he retained the broken Microsoft library.
Yes, I have no evidence. But just spend a day reading Joel and then tell me what you think.
So where's all the evil come from?
Well, you see... Back in the mid-1970s, one Richard M. Stallman went to schoool with a quirky fellow by the name of Bill Gates. While young Billy wasn't considered the coolest kid in the school, his wealth demanded a status of its own.
One day, little Ricky Stallman wanted to head over to Billy's house to have fun in the swimming pool. But Billy said "No, Ricky, you aren't welcome, you stupid pinko bastard. Besides... You'd contaminate my pool with geekiness."
Well, Ricky wasn't very happy about that reception, so late that night, he snuck over to Billy's house and peed in the pool, thus contaminating it with geekiness. Billy went swimming the next day, and the day afterward arrived at school sporting a new pair of glasses. Ricky bragged about what he had done.
A few years later, The y-less Bill Gates and his friend, Paul Allen, founded a tiny software company, which, repeferring its size, they named Microsoft. Ricky, making the semantic misinterpretation of a lifetime, thought that they had named the company after a certain reproductive organ. He visited Bill, and asked to join his club. To support his membership bid, Ricky pulled down his pants and said, "Look!". Bill called the police, had Ricky Stallman charged with indecent exposure, and a lifelong resentment of all things Gates had begun to germinate in poor, little (note double-entendre) Ricky's brain.
Twenty-some odd years later, Ricky has managed to convince many fellow misfits that rich people (much like mean people) suck. These people are relentlessly beating war drums, and heading off on regular jihads much like the lemmings they are.
For all these reasons, and many others that I won't bother to bore you with, Microsoft is evil. This is, in essence, what such arguments boil down to.
(The rest of us use whatever OS is needed to run the programs we prefer to use. All things being equal, we'll take the free-as-in-beer stuff to save ourselves a few bucks. Stealing a few lines from other people's public source code is a great way to save ourselves time, too.)
Mozilla.org doesn't look like a happy friendly bunch of open source developers. The site is a static pile of crud, and they never made clear the ties between Netscape and Mozilla (like, will the Netscape funding go away when they reach 1.0 - or will it have the wind knocked out of its sails).
It is rapidly becoming harder for them to maintain their code, and develop new software that might earn them a profit.
"You spoony bard!" -Tellah
(and yes, I realise it's still beta - but most software is still hyped before 1.0)
As for point 1, I don't really think Joel would say that bugs are "good" or that they shouldn't be fixed. Just fix them in the most economical manner.
I do somewhat agree with you on the other points, though I'm going to take the liberty of doing some "charitable" interpreting of Joel on a couple of the points:
2. Load in useless features to drive sales, knowing that your code will suck.
I think, with respect to this, Joel isn't interested in useless features. What he is basically saying is that if users REALLY want a feature, you're stupid to to take the attitude that "I know better than you: you don't need this feature". You just lose customers that way. Remeber, the customer is always right.
3. Once you have gobs of crap code and a large user base, there will never exist the possibility of re-designing things (eg, WinXP) since it doesn't matter that code sucks (see point 1) and all that counts is revenue.
Well, although I do believe there are certain situations where a complete re-write is in order, I think he makes a valid point. I think Joel (again I'm interpreting here) would say that it is better to revise the current code, clean the current buggy code up and "perfect" it rather than to start over. After all, starting over doesn't even guarantee you that the new code will be any less crufty than the old code, just different! (Although, sometimes your design was fundamentally flawed to begin with and you need to start over to deal with the intrinsic problems in it, but hopefully those kinds of problem can also be dealt with by revisioning instead of starting over completely.) Start over with a new code base and you just end up with new bugs sometimes. Plus, as he points out, not releasing an updated product in the market for 3 or 4 years REALLY hurts a technology company.
4. Being efficient is a waste of time. Let the hardware catch up with the crap code.
Hmm, he does sound a bit like he's saying that. But, to be charitable again, I'll interpret him as meaning that it's not worth spending a lot of money and time to get small incremental performance increases or size decreases. But, obviously you're not going to set out to make your code as inefficient as possible. And he does have somewhat of a point about Moore's law. How many people are still using WordPerfect 5.1? Undoubtedly there are still a few people. . . but is Corel making any money from those people? Probably not, and since Corel is a company that needs (desperately at this point) to make money, they are going to add features that user want, that they think will give them a competitive advantage to Microsoft, even if that means increasing the size of the program a little bit.
...imagine if your company hired a Medieval Studies major to lead a company of engineers. Oh..wait...that happened to me!
Well, she can't be all bad, look at what she did for Lucent.
There are not many famous asian coders, but in electrical engineering, they and the immigrant Indians dominate the industry. They go through puberty later and thus, they have a slightly higher average IQ than caucasions.
But one thing seems certain, other than Tony Suzuki in 1983, I have not heard of too many innovative shrink-wrapped coding gods that are asian.
Innovation is not exaclty correlated with raw IQ in some people I suppose.
blacks hispanics and females go through puberty earlier and thus are more often closer to average intelligence and unlikely to be genius-level aptitude.
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.
Maybe they should interview him again when he's not so hungry.
``Life results from the non-random survival of randomly varying replicators.'' -- Richard Dawkins
You do realize that NT, 2K and XP are of the same lineage and ME is a Win9X upgrade, right? NT came long before 98 and has been a long since stable OS, even version 3.51.
My college asked me to rewrite their pascal program in Java. I asked why. Their excuse was that it ran under DOS. I think it was a lame excuse.
Anyway, the never rewrite code idea.. never optimize.. We now see why Windows is such a terribly bloated hog,.
I think he forgot to mention the move of MacOS from m86k to PowerPC, and finally to OSX which is a wholy different kernel and can be considered a pretty major rewrite. And they did it without suffering! Ok, apple hasn't always been doing well, but it wasn't directly related their rewrites or huge porting projects.
I challenge you to name a business that never made a mistake.
They all do, or they all will make a mistake. Pointing out that Netscape or Real lost because of a mistake is disingenious, because EVERY business makes some sort of mistake. They spend too much time adding on buggy features, or they spend too much time getting it stable that they lack features, or both at the same time.
But, Microsoft's monopoly position mean that they're almost immune from mistakes. They can afford to have 3 teams rewriting code. They can afford to be a loss-leader for YEARS. They can write crap, but make sure it gets users from version 2.0.
And, Microsoft makes mistakes, mistakes that would put any other software house out of business. Look at how late they got into the internet, and how many people they bought out to catch up? The billions of dollars spent developing IE.
At that level, Microsoft doesn't need to give a fuck if they make a mistake. They have immunity from mistakes. They can use their monopoly to hide it, cover it up, or get a second chance later. Others, without a monopoly, cannot afford the expense of keeping up.
Hmmm...side thought. Maybe all that 'junk' DNA is Mother Nature's "Bug Fixes".
Another problem ....is a female project director who thinks her job it to keep other women way from programmers as a way to keep them on the job and control their behavior and output....as absurd as this may sound I have seen it happen....
This is a great response, couldn't have said it better.
I get the impression that this guy really really really has his head up good old Microsoft's kiester. Don't get me wrong, I think people use code-rewites a little too often, but I don't think they are on a whole a bad thing. Sometimes you need fresh code, hell that is what Carmack does with each new ID game. As for the code-rewrite destroying Netscape, it is an intersting rationization, I mean we all know it was the freaking M$ monopoly that killed Netscape.
By the late Douglas Adams, may he RIP:
:(
I love deadlines - I love the whooshing noise they make as they go by
I still can't believe he's gone
Any technology distinguishable from magic, is insufficiently advanced.
He's right. Want to make a ton of money in the software buisness? quickly develop buggy bloatware and convice your customers that their software runs slow because they're soooooo behind the times with the computer they bought last year for 2000 bucks.
Good, fast code takes too much time... While you're working on your great app, your company is going out of business...
It will be interesting where things go in the next 5 years with GPL'd code that can't disappear when the business goes under... But instead can continue to be improved.
You could say Microsoft won't be "eating anyone's lunch"
Happens all the time.
A bunch of the guys I work with left a pharmaceutical firm because their development jobs got outsourced to Romania.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
I do not see how this is a troll.
Sure, marketing is an easy target to bash, but I'll be damned if I work at a company that has no clue how to sell itself.
A witty saying proves you are wittier than the next guy.
Compete against a company with apparently unlimited resources. They can keep throwing programmers at you, buying more magazine ads, articles, and columnists than you*, and keep doing this until you fail. Microsoft, with a monopoly on operating systems and OS revenue, comes to mind.
Borland languages? Hire away their best programmer. Netscape? Give away a product to undercut them. Wordperfect? Buy ads until the reviews start tilting your way, and (in the Netscape preview) bundle it with the OS for 1/4 to 1/8 the retail price of the competition. 1-2-3, ditto.
*A recent newsgroup article said of a magazine, "Everything in [the magazine] is an advertisement, and some of them are marked as such."
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).
Clear, Consistent Formatting
Forget about importing free third party code that doesn't adhere to your formatting standard them. you bend to the maintainer of a particular piece of code, and in a large project there may be many major maintainers. It helps of course if all in-house people can agree to a layout style, but you're going to have to deal with foreign code anyway, so don't stess over it.
If it really matters for publication purposes, use a pretty-printer. All decent programmers are not put off by slightly different indentation styles across major code sections so long as there isn't too much stylistic scizophrenia in a given file. And no, you don't want programmers who can't "handle" it touching code -- they mess things up too much.
Hungarian Notation? Ugh. Spare me the need to be ever so explicit about types. Good programming is all about layers of abstraction. It isn't a "pointer to an object with 5 abstract member functions: open, close, read, write, and control". It's a pointer to a DEVICE, damn it! Learn the paradigms and abstractions before delving into the code.
Copious Comments
How many times have you seen, "i += 1; // increment pointer"? Doesn't help, does it? You document the trees but ignore the forest that way. Get the internal abstractions and paradigm out of the way and you're done. "This state machine maps input data and current state to an output message and new state." There! Done!! Documented!!! You don't need the "what's a state machine?" people around.
Documentation
Less is more. Really. The trick is to maximize the ideas communicated per words written. It takes time to think up, time to write, and time to read. At some point there is no excuse for not reading the code. Documentation should be a roadmap, not a novel.
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.
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.
As for unreadable code, I've found that good programmers who have low defect rates and high productivity can read code like prose, provided the paradigms ("what was he thinking?") are explained early on. It's the medeocre ones that need the handholding.
These mantras are derived from the belief that coders should be interchangable, that design, and documentation should fit the needs of the lowest common denominator. Well, that's a waste of talent. You're forcing those who can crank out correct code an order of magnitude or more more productively than the average to slow themselves down by a corresponding factor.
Stop hiring idiots. Pay three times the average wage and hire only the best. You'll have much better productivity/cost ratios. So what if 4/5 programmers can't understand the code? The one you've got does the work of 2 to 3. And others like him can pick it up with little or no effort.
You could've hired me.
Joel seems to conclude that because a lot of prominent companies have failed at code rewrites that they are a bad idea. He's right that you can't put your existing product on hold while you rewrite the code from the ground up. But if you don't take the hit one time, it will cost you in lots of little ways over a long time. Would he advocate never upgrading a companies IT infrastructure because of the disruption that would cause? Probably not. The key is to test stuff first, and try to get everything switched over when it will inconvience the fewest people.
One big problem with rewrites that he doesn't address is the "second system effect" from The Mythical Man-Month. This is the urge of, when your doing your redesign, to but everything into it, conquer the world, put every single feature in. This, in my opinion, is what happened with Netscape. Joel seems to think that this kind of problem is inevitable with rewrites, I disagree.
The buisness side of the equation I think he missed is all the companies that have disappeared because their product couldn't be updated for changing times, and they couldn't afford to do a rewrite. Some startup, or a new arm of Microsoft, comes and throws tons of money at a done from scratch solution, and becomes the next leader.
Anyway, that's what I'd tell Joel if I worked for him on some project that was riddled with crappy code. And if he fired me, hey, plenty of other jobs.
His POINT is that Microsoft decided to write a new OS from scratch (NT) because the OS at the time (DOS/Win3.1 if memory serves correctly) was fundamentally broken in several important ways.
But, Microsoft new that NT wasn't ready for mainstream home use, so they kept revising DOS into Win95, Win98, and finally WinME. And WinME, after all those revisions, has gotten so totally crufty that bug fixes introduce new bugs. That is the original poster's point.
Microsoft, of course, was concurrently revisioning NT to make it so that eventually it would be useable by home users.
If all code written was as simple strcpy() and moving numbers around in an array then there'd be no need for comments but unfortunately in the REAL WORLD things are never that simple and adding comments greatly increases the amount of time it takes maintenenace programmers to figure out what the heck a piece of code does.
Joel's memory seems a bit selective to me.
In fact, Microsoft employed two of the very tactics that Joel blames for Borland's demise to enter and conquer the database arena, thereby hastening Borland's fall.
After Borland paid $440 million for dBase, Microsoft picked up Foxpro - essentially a rewrite of dBase - for a mere $137 million to gain a foothold in the database market and underpriced the competition with the introduction of Access at $99!
He missed expecting developers to work 9+ hour days as standard practice. A good book is "Debugging the Development Process". The author also worked at Microsoft, he was a project manager for a couple of different projects that were missing deadlines. He said often they were working 12 hour days all the time. When he started making people go home and also managed the to-do-list better the project would stabalize.
All the execs would rather lay off people than cut their [own] salaries.
Well, of course! When was the last time you took a pay cut for someone else's job?
Perhaps this is incompetence on the part of the owners, but it's not management incompetence to take as high a salary as you are allowed. You just don't turn down money from the boss. Your work and everything under you is your problem, the expense of your salary and everything above you is your superiors' problem.
Their minds don't work like that
I don't think that is a fair statement. I think it is more that their culture puts more emphasis on conformity than creative thinking and their educational system puts a lot of effort into more engineering type processes than artistic ones. But those are all pretty broad and vague generalities. It is better to judge each individual on their own merits.
lowball the workers/coders.
But before dwelling.. if 9/10 software projects fail, then why so much money for project managers - that have moved on before the shit hits..
lets define fail - throw more money/people at the issue - like MS and you will deliver something. AFAIK MS has never released project cost estimates publically. On budget is what we are talking about - over the life of the project.
I know of an app that is now up to killerapp ver 10.5, which implies version 1..10 are not in use.
the upshot is pm really is a science, but the head honchos spreading porkies are brought down to earth in an interview by asking 2 questions'
was it on time and budget. - name example
if so, why is that company now on version 4,5, and how many extra dollars were spent bringing it up to that level.
a good consultant always leaves something unfinished, and never says no to anything - says yes, then qualifies that yes.
avoid that sort.
MS has been able to win by working on a very simple base. It is easy to write single user apps. Just do it. Oh, lets add in networking. Security? What is that? We want all your passwords and credit card numbers on Passport, it takes 30 minutes for someone to figure out how to get the information. Get it out quick, shut it down quick.
.NET infrastructure due to insecurities to change the accumulated wisdom at Microsoft. This ain't dos, this ain't win3.1. The competition won't matter, it's the lawsuits that will. This is real computing, the stuff the mainframe people were mocked about when the pc ate their lunch.
It will take a major blowout of
Derek
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The single comment that made me say this was his response that without extreme circumstances, a rewrite isn't needed. What he fails to realize is that the world OUTSIDE of your codebase changes, and even without a radical platform shift, a rewrite could become vital to the continued success of the product. If I was coding for a static system, I'd agree with him. Drastic code changes would be rarely needed. But the world doesn't work that way. I rarely use harsh words like "twit" when replying to interviews, especially when I've never heard of the person being interviewed before, but he doesn't seem to understand the scope of the real world, despite having a much firmer grasp on software market conditions and workings than most programmers. Of course, he seems to have les of a grasp on code dynamics than the average programmer, so maybe this is all just an indication of him being less suited to coding than maybe being an average manager.
jX [ Make everything as simple as possible, but no simpler. - Einstein ]
...a former Microsoftie explaining how Netscape failed?
"Well, we bought another company's browser, threw the Microsoft logo on the splash screen, and gave it away for free. Nobody bought Netscape's when they could get ours for free, so there goes the R&D budget for Netscape. We're raking in *our* R&D money from the Windows/Office upgrade treadmill we put the planet on, and..."
~Philly
Wow, we need to get together in the office tomorrow! Surely there cannot be 2 companies running such identically idiotic schemes out there. Could there?
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.
Whats saying that a programmer can't go back into the function, rewrite it with new code, code maybe from a better API and then make the function run faster and be bug free.
software. Products that failed because they were 'late' to market. Bloat is fine, just get everybody to buy bigger machines. If it sells, it is good. Sounds like the american auto industry in the 60's before the japanese invasion.
Wordperfect 5x was written in C. They were caught off guard because the next thing was going to be OS2, then MS came out with win3.0, which took off. I couldn't bear to run anything in that, and since the haven't used any MS stuff.
If linux is ever run by marketroids, I'm first one out.
Derek
That notwithstanding, excellent article.
Those Marketroids are the ones who figure what people need and what they dream about having so they can suggest a product that will appeal to the majority. What is the meaning of a good product when no one wants it?
This reminds me of the movie industry. I see plenty of foreign movies receiving awards, oscars, etc. Maybe they're good but I don't usually like them. Hollywood movies appeal to the majority of the population and that's why everybody watches them.
I'll be the first to admit that Mac made mistakes. Probably more than Microsoft as far as marketing and pricing is concerned. But I have yet to find any major mistakes with their new OS. I've been using it for four months now and it quite litterally hasn't crashed yet. My room mate has the supposedly 'unbreakable' XP and it is far from that. It crashes as much as old mac OS 9 did and lets just say that was one of Macintosh's mistakes.
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.
Now we know, in the M$ world bugs=knowledge. No wonder SpyG^H^H^H^H MSIE takes up a 500M foot print. Whoo hooo!
The real question is, "How do you sell that shit?"
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
One big problem with rewrites that he doesn't address is the "second system effect" from The Mythical Man-Month.
Spot on. The key to successful rewrites is not to attempt to build the "ultimate architecture" for the application, but to target the actual problems in the code base. The ones that cause the code to be riddled with patches and work-arounds because the original design simply didn't meet the challenges of the real world.
I don't doubt that Mr. Spolsky has learned some valuable lessons in his career, but in that article he certainly comes across as if he were saying "I'm a manager now and I know everything there is to know about the development process." When you start phrasing things in absolutes (never, always) it's usually a sign of trouble.
I posted to show my ignorance for all of slashdot to see.
Ok to some extent, yes, but as I read the article I thought to myself "What is he saying in simple terms?"...it's late and I need to go to bed.
Microsoft's "innovation", if you will, was a 2 out of 3 ain't bad scenario that proved ecologists correct "Reduce, Recycle, Reuse".
Only in this case they figured out "Increase (bugs, bloat, features), Recycle, Reuse".
Quite frankly it explains a lot. I had submitted a link at one time called ".asf == Another security flaw?"...because WiMP (win. media player) had {gasp} a security flaw.
The kicker was it was the same flaw that kept showing up time and time again...I think someone at bugtraq called it "sheer idiocy" (don't hold me to that, as I lost the link).
And, I've mentioned to people that the I.E. integration into windows was asked of beta testers: "Do you want IE integrated into the OS".
78% said 'NO'...well, look where we are today, eh?
Whoever said "I felt dirty just reading this" said it very well. It is like thinking about "your grandparents having sex"...you know it probably happens, but it best not to think about it.
Same thing here...we know Microsoft "does it" with code...just try not to think about it.
You'll sleep better at night. Perhaps.
Is there a certain resignation involved?
Yes, because, short of "nuking 1 MS way" off the planet (only way to be sure)...the have "won".
MS has proved "no one ever went poor underestimating the stupidity of the American buying public". (WC Fields?, I forget).
Nite, all.
Moose.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
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.
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
If there were ever a time to make an exception and allow a comment to be moderated up to 6 or 7, the above post would be it. I can't believe how many people here are actually believing the tripe in this article, which basically suggests that Microsoft won so many markets because they actually had better products. SoftwareJanitor's post is spot-on: Microsoft had (and has) enough monopoly ca$h to keep plugging along until they eventually get it right. Most other software companies can't afford that, so they just end up folding.
Come on now, do you really think that a product as awful as Exchange would get very far if it didn't have Microsoft's money behind it?
Give no credit to Microsoft here. They're the bad guys and they will continue to be the bad guys for the foreseeable future. Don't be swayed by this moron.
Tired of FB/Google censorship? Visit UNCENSORED!
Seriously, something that boots from the OS/2 boot sector is surely some form of hacked OS/2. They may have acquired a guy or so who wrote VMS, but the source they worked on is OS/2 1.3 through and through. Not that I am complaining.
You know, for all this alleged VMS stuff, MS is awfully quiet on it in Technet, or in the NT Help files. On the other hand, OS/2 is quite well represented in both of them.
And OS/2 support in NT is a good thing, since their networking runs on OS/2, and looks like something out of the eighties.
And, no, I'm not a MS basher. I just have lived through the reality of NT and OS/2. I am awake to it. My information does not come from MS alone. I do not believe MEGO diagrams.
OS/2 - because choice is a terrible thing to waste.
Normally I don't reply to anonymous idiots, but I'm in a bad mood today, so I'll let you know that one of my programs just happens to be more or less a de facto world standard. And I graduated university two years ago, thank you very much.
What kind of falsafilability is there on this?
This sounds really religious here. Capitalism==good. Greed makes things good. Socialism==bad. Weird. I guess they should teach more _real_ science in schools instead of this pseudo-science.
I think the author has it completely wrong. It's suicide for (most) companies to keep alive ancient code. Indeed, the author makes this case strongly himself, in reference to (what he describes as) the ridiculous Word Perfect people who insisted on coding everything in assembler. At some point (he rightly implies), in order to remain competitive, Word Perfect should have dumped their old assembly-coded model and switched to C or Pascal (in the context of the time period). In other words, code it from scratch.
The author takes the attitude that Microsoft's success was a function of its "correct" thinking vis-a-vis using old code. It doubt it very much. Firstly, there's the obvious example of the continuous replacement of 16-bit DOS code with 32-bit Win95 code. And of course, the completely-written-from-scratch OS, WinNT. At this point, they've completely dumped everything but NT. What percentage of code shipping with XP does the author imagine is more than, say, 5 years old?
The author fails to see that Microsoft's technological success is primarily a function of the amount of money it has at its disposal. Indeed, the author provides an excellent example: where parallel teams developed Word -- one from an old codebase, and one starting from scratch.
How can a company compete with Microsoft? That's the real question. Is success more likely by sticking with old code, or by writing from scratch? Very clearly, the answer must be -- by writing from scratch. Consumers only want the best. Microsoft has the wherewithal to be constantly writing from scratch. In order to even get a shot at them, you must at the very least have a very clean, very well-designed framework. That Netscape didn't have the resources to develop the old Netscape 4 line in parallel with the Netscape 5/6 line is not a failure of Netscape technical management. Indeed, in the long term, the only _possibility_ to continue to compete with Microsoft's deep-pocketed browser effort would be to have a very-well-designed (therefore, mostly-written-from-scratch) framework. The 2-3 year gap between Netscape 4 and a usable Netscape 6 is the unfortunate-but-necessary result of being squeezed by Microsoft's monopoly position.
I think history will judge the rewrite (and, as importantly, the open-sourcing) as a very tough, but correct, decision. At least this way, Netscape is still in the game, rather than going the way of Word Perfect. The foundations are there to build on.
As far as Joel goes, I've been there, done that, got the t-shirt. The problem is, he's wrong. Yes, it costs to rewrite code from scratch. What he misses is that it costs to not rewrite code from scratch too. The question is, which costs more? After a certain point, all those accumulated bug-fixes and patches and kludges to make the code work take longer to work around than it would take to throw it out, take what you learned from it and reimplement it right so it doesn't need all those kludges. At that point, if you refuse to rewrite you end up tying your hands. To borrow one of his cases, yes Netscape sacrificed a lot by throwing out the crap codebase of 4.x. Yes, they couldn't respond to MS's advances while they were rewriting. But if they hadn't rewritten, they wouldn't be able to respond to MS now because it'd take forever to try and turn a tag-soup browser into something that could actually parse XML given a DTD.
I think I'll agree with the analysis I ran across in the IEEE software development magazine, that concluded that software has a lifespan of about 4-6 years, at which point it's cheaper and faster to throw it out and rewrite it based on what you've learned than it is to keep modifying it.
Come to think of it, that applies to lots of things. There's a point where you just have to stop tinkering with a prop-driven aircraft, abandon the whole propeller idea and start building jets if you want to go faster.
Actually, the story is about Rockefeller watching every penny, not cutting corners. And he reduced the number of drops from 40 to 39: http://www.csudh.edu/hux/syllabi/554/one_2.html
That being said, the article had some good points about software engineering.
Is it really MY responsibility that someone coming after me has ease in picking up and reading my code.
It was hard to write, it should be hard to read.
From what I've seen the entire push towards good
Software engineering practices is only aimed at
making engineers irreplacable.
It may be in the company's goal, but speaking as an
individual, MY goals don't always match that of the
greater good for the company.
Call me selfish, but there is some benefit to being
relied upon to know exactly how something works when nobody else does.
Why do certain employees fail? JS didn't quit to spend more time with his b/f. Find that out and you have a real story.
What are you smoking? The OS/2 subsystem doesn't exist in WindowsXP. It was pulled early in the product cycle. So how does its networking run on OS/2?
Silly Rabbit...Sig's are for kids.
URK... 'irreplacable' should have read 'interchangeable'
This article is really about the economics of rewritting software.
The fundamental difference between free software and commercial software is that free software is about the product, commercial software places a higher value on the profit than the product.
The classic engineering design method is to build something, break it, build it again break it again, etc etc.
Ive never heard of good engineering design comming from build it, break it, fix just the bit that failed, break it, fix just the bit that failed, etc
The whole program is one product, patches dont always fit in nicely with the overall program flow, thats when a program becomes ugly.
Ugly code is more costly to free software because it stops people wanting to get involved, if commercial software is ugly they just pay them more money or something, managment doesnt care how much programmers like readign the code, they just care that it works and its on time/budget
This is what we in the industry call a "troll".
[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?
Joel forgot to mention that there are some good times to throw out old code:
* If the existing program is written in some old, obscure programming language (like Forth or INTERCAL), and no one on the existing programming team knows how to read it, rewrite. Unless the program is HUGE, it's probably cheaper to rewrite it than hire a new programmer that knows how to change it.
* If the existing software has more bugs and incompatibilities than features that still work as originally intended, rewrite. Let's face it, some code is SOOO bad that it just isn't worth fixing.
* If the code is poorly commented, or doesn't adhere to the most basic modern programming conventions (I'm thinking GOTO loops, 2 letter variables, and line numbers here), scrap it. You'll drive the programmers nuts trying to figure it out and fix it.
* If using the existing code requires buying thousands of dollars worth of proprietary middleware and conversion software to make it work on a new platform, rewrite. Joel mentioned this one to some extent, but some pointy haired bosses out there just don't realize how much more complex and problematic a system can become once you start adding machines who's sole purpose is to act as a gateway or translate data between formats. Trust me, I have personal experience with this one.
To All,
I believe that ICQ is always in beta so that if AOL decides they want to sell ICQ, they just remove the 'B' and call it a finished product.
ICQs Agreement says it is a Public Beta.
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.
No matter the insinuation - NT 4 and above are *not* C2 (Orange book) certified or compliant.
Yes, Microsoft insinuates they are, yes, the US DoD uses them in places where legally they must have C2, but that doesn't change the fact that only NT 3.5 with 2 x86 and 1 Alpha configurations (and no NIC or floppy drive) EVER has passed C2 certification.
(That's 3.5. Not 3.51).
Addison
Netscape may have been a commodity but IE never was.
In my view, the essence of MS's strategy was to make sure neither IE nor anything else produced by them was a commodity but in fact something exclusive to them.
When I hear distance learning product managers saying they haven't "certified" their application to work with a particular browser I want to throw up my hands. They are idiots but it reflects the general understanding as MS has decreed- their stuff will only work with their stuff and they want your stuff to only work with their stuff too.
MS doesn't want commodities and they will fight to remove any threat of standards impinging upon their exclusive rights to your dollars.
Why, no! Everyone uses RH7.2 on x86, and everyone has the current directory in their PATH. Stop encouraging anarchy!
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
It's just a show, he should really just relax.
Oops wrong show.
Anyway um this message is for *JOEL*, Joel, who the frickin hell cares what *you* think? Just another version of an overinflated ego. Got your own webpage I see *yawn*, "publishing" your own opinions and passing them off as facts, getting interviewed by all the trade rag hacks, spinning yourself into celebritydom... It's punks like you who make me want to get out of software and become a plumber.
Either way I gotta work with shit all day.
Come on now, do you really think that a product as awful as Exchange would get very far if it didn't have Microsoft's money behind it?
Let alone that Exchange wasn't even their first attempt to break into the email server market... Those who remember the horror that was MS-Mail know the revulsion of hearing Microsoft apologists say things like "well, at least Exchange is better than MS-Mail"...
BTW, thanks for the compliments.
Sorry, but if anyone were to implement an entire software project using LISP, it would be sure to fail, and would be gay to boot.
Ease of portability. If you read the concept behind NT, they developed the HAL in order to move it easily to new hardware. This allow them to support Alpha, MIPS, and PowerPC (while they did) with a very similar code base. Should there be another hardware platform that they wish to support, their major task will be to rewrite the HAL. And I don't just mean new processors. Try porting Windows ME to PPC architecture.
How about enterprise-level networking? 9x networking was very primitive. You try to use a 9x machine as a server, and let me know how well you will do.
How about Unicode support? At the file system level? May not be an issue for you, but dealing with japanese characters in filenames from inside english Win 9x is next to impossible, unless you read the disk raw.
How about multi-user support? Try terminal services on 9x. Even without terminal services, remember that apps can run under different security contexts even in 3.51. Think services, for example.
Also, WinNT applications (and drivers especially) are easier and cleaner to write. This does provide development savings. Not all revenue has to be from the marketplace.
Finally, it is very unlikely that a user-mode program will bring down an NT-based OS. That is why my development machine is Windows 2000. If it were 9x, I can easily corrupt the runtime.
Laugh as you want, I was using NT 3.51 when 95 came out, and I wished I had the new explorer, but I wouldn't switch over and give up all the stability.
It's taken them 6 long years to get NT technology to the desktop and all that time there were selling DOS-based, 3.1-based operating systems.
:)
Actually... They're still using their marketing muscle to force *that*. Many places, most I'm aware of have easier times with Win95/98 on the desktop.
Similarly, 95 forced 3.1 off corporate desktops when the *preloads* disappeared. It was making progress, but not a lot.
Amazing how that monopoly works.
Addison
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.
Bloat is fine, just get everybody to buy bigger machines. If it sells, it is good. Sounds like the american auto industry in the 60's before the japanese invasion.
It will be interesting to see what does eventually come along to knock Microsoft off their pedestal. Something will, eventually. Those who say it can't happen don't have a big picture view of history. Sure, it might not happen tomorrow, or next year, but it will happen. And it doesn't mean they will dry up and disappear. GM, Ford and Chrysler didn't, although they were forced to adapt and no longer look very monopolistic. Examples... If you told people in the late 70's and early 80's that IBM would be knocked off as king of the hill of hardware vendors, almost everyone would have told you that you were nuts. Couldn't happen. Sure, IBM is still around, but they are no longer the 800lb gorrilla they once were. If you told people in 1980 that CP/M would be knocked off as the leading business micro OS, most people would have told you that you were nuts. The list goes on and on. But nothing is forever. If nothing else, even if a competitor doesn't come along to knock a dominant leader down, the leader often becomes old, tired and lazy and falls down often drunk on their own power. One of the things I've seen quoted from Gates is that he has a fear of Microsoft becomming (the old) IBM. It is starting to look more and more like it is happening, despite Microsoft's efforts to avoid it.
Wordperfect 5x was written in C. They were caught off guard because the next thing was going to be OS2, then MS came out with win3.0, which took off.
I don't think that it was an accident that Microsoft told IBM and all of the other software development companies that OS/2 was the future while at the same time they were already planning to pull the rug out from under it and go full out with Windows and NT. Microsoft wanted the development tools markets and applications software markets. Getting everyone to go for one platform and then switching to another was a great way to get a huge head start on everyone else. A very dirty trick, but who would expect fair play from Microsoft.
EVERYONE who worked with that code wanted it redone. I was brought on to lead the effort. We rewrote the whole thing except some gui components. We were able to shrink the LOC in most modules by at least half. In one case I reduced a class from 4000 LOC to 200 simply by taking advantage of preexisting APIs. Redevelopment is sometimes the best solution.
"The advanced societies of the future will be driven by competing systems of psychopathology." -JG Ballard
FYI, it's not your fault, but you learned the wrong version of Hungarian Notation, the one deployed in the Windows API by a bunch of morons at Microsoft.
True Hungarian Notation is exactly about layers of abstraction. Hungarian Notation tells you exactly that it's a pointer to a DEVICE and nothing else. Read Charles Simoni's paper about it In fact, if you read the bit about how traditional variable naming mnemonics tend to create ambiguity of reference, you'll see that Hungarian Notation is much more precise about economically distinguishing between different abstractions like files, file pointers, file handles, filenames, etc. (Simoni, BTW, implemented the first WYSIWYG word processor when he was at Xerox PARC)
When I posted the above comment, I had a between "...under NT." and "So, you...." Came out OK in preview mode, but the closing tag was eaten when I submitted. I'm logged in and using the "Post Anonymously" checkbox.
...there is a handful of people that basically doom projects to failure. If they don't think of the idea, the project dies. If the project doesn't greatly involve them, they kill it. If they are involved too much, they cite how incompetent they think you are because they have to be involved so much, claim they're too busy, and kill it. I've found that if they kill something, the rule of 3's applies. 3 minutes, weeks, or months after they kill your project they either a) completely reverse their opinion on it to a superior, b) reinvent it as their own pet project of which they are of course an expert in the field, or c) a combination shot of both to the mid section. Even when you involve the big cheese that oversees all and get his endorsement on something, they somehow manage to later convince him with a, b, or c and cut you from the loop. One person in particular is as incompetent as they come. Literally this person doesn't know Jack®. Still this worthless person manages to get their hands into every single pot and slow things down, fsck the process up, or kill the thing entirely. There really is no reason for this person to be employeed with us. Worthless doesn't begin to describe this person in all honesty. What dooms projects to failure? Incompetent management, staff, and politics IMHO.
To me, boiled down to its essence, what Joel was saying is that you must know what is important to a majority of your customers. If they value features x, y and z delivered in 2 months over having a faster product delivered in 3 months, then you give them the features. That's pretty simple for everyone to understand.
The key element of this, is I said you have to understand what a majority of your customers want. Look around you, the geek sitting to your left or your right are not the majority in the population. Think in terms of your grandmother who may have heard of this internet thing in the last few years. She's part of the majority of Americans who think that Microsoft has added new features to its operating system because they have a different set of backgrounds to choose from. Try explaining the advantages of having a full blown linux operating system on a 1.44 Meg floppy -- it'll be lost on her.
What we're really talking about is how much of the population is composed of software afficianados -- people who can appreciate the subtler distinctions between different pieces of code. Think about how you feel when interacting with a wine snob who's amazed you don't know the difference between an '83 Pinot Noir and a '72 Chateau Lafite - okay I know nothing of wines here so excuse my example. But you get the point. Not having a lot of experience with wine you might not be interested in all the details but may just want to dabble. Your grandmother and others feel the same way about computers and software. They can't appreciate whether you application has a good MVC architecture, but they can tell you if the font is pretty pretty or complain if they can't change the color scheme.
Think about it.
I agree that doesn't help. They're just restating code. If, however, the author of this code snippet had said something like
i += 1;
This gives semantic context to the action being performed and THIS is the point of comments; it's not about the restatement of code.
And then when your wunderkind has left the company because someone else offered a raise that you can't match, or the star decides to go into business for himself/herself, or dies from a caffeine overdose, and you are left with no documentation, no comments, no variables longer than four letters, and the "talent" isn't returning phone calls, then what? In your scenario you either lose a year going through the code one line at a time to find the off-by-one bug buried somewhere, your company goes bust making the attempt, or someone rewrites it (also wasting time). You're point would have merit if programmers were know for staying at a company for ten or twenty years. But in "the real development world" two years is the average.
So everyone should be screwed because some hotshot thought that LISP was a good idea for the problem at hand even though no one else at the company knows LISP? Sure the program is efficient and runs like a dream right now. Fat load of good that does you if it breaks or needs to be extended. And it will break. And it will need to be extended. All code has bugs. A large codebase has more bugs. And new requirements are a fact of life.
Egos don't keep companies in business and they certainly don't put food on the table.
If you can throw letters down in Emacs so quickly, why can't you seem to find time to have one line out of 15 be in English. It's not like you really have to switch tasks. You're supposed to be writing about the task at hand. I assume that you can program in more than one language; why isn't English one of them?
(Apologies in advance to those programmers who are in non-English-speaking development environments)
- I don't need to go outside, my CRT tan'll do me just fine.
to make a long reply short, I don't write code for non-programmers, especially when dealing with personal projects. I think it's reasonable to expect a certain level of skill out of anyone who intends to work on my code (or any code, for that matter), and I design and code with that in mind. You can call it laziness if you like; I call it "efficient use of limited time". I write documentation for non-programmers.
And yes, when I'm doing something at work I put in more comments than usual--among other reasons, because the other folks in my group don't have that much programming skill--but I also don't consider comments a substitute for documentation, as you (and the original poster) seem to. Documentation is absolutely good; just let me push it aside when I've got a handle on it and want to work on the code.
Oh, and here's a little question... I've been speaking English for 24 years, and Japanese for only a little over 5; why is it, then, that I have trouble expressing some concepts in English that I have no trouble with in Japanese? Hm? Maybe it's because some languages are better at expressing certain concepts than others.
One thing I can't stand is when people check in some code, and the comment they associate with the check-in is "fixing some things" or "updating" or just "."
WTF?! Put something meaningful, damn it. Comments are not for YOU, they're for others; be considerate.
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Basically, he's right about everything he said. I'm not all that happy that he's correct, but I can't take that away from him.
.02....
Generally, innovators don't win...they just provide fodder (read: ideas) for the copycats to do it better/faster/cheaper.
Also, his examples were right on point...especially the one about Novell.
Frankly, the same lessons could/should be learned by Linux.....a GUI (that's easy for the masses to use) is absolutely ESSENTIAL for Linux to be anything other then a niche OS!
Anyway...that's my
No, no, no. You've got it all wrong. The key to successful trolling is bizarre gay porn. Not just any gaping orifice will do.
In the late 1980's platforms from Apple and Commodore(and even Atari to some extent) were very viable
The Apple II Plus and later II models had Applesoft BASIC, written by Microsoft, in ROM.
Will I retire or break 10K?
Well considering I see lots comments from 1991 in the nt source code I would have to say alot of the code is 5-10 years old.
Silly Rabbit...Sig's are for kids.
If the minimum wage had gone up at the same rate as CEO salaries since 1990, the minimum wage today would be $25.50/hr.
Or is it that CEOs work that much harder than they did ten or twenty years ago?
The guys at the top did NOT pull themselves up by the bootstraps. They were hoisted up on the backs of others. Don't get me wrong. I have met some truly brilliant minds that were in charge of some companies. But I've also met some true boneheads who still gleefully pulled in $500K/yr+. We're moving headlong back into the days of the robber baron who rules over his fiefdom with an iron fist. Yeah, those were good times. Well, of course! When was the last time you took a pay cut for some peon...er...someone else's job?
- I don't need to go outside, my CRT tan'll do me just fine.
Yes, it's true. If you make a major mistake, you get killed, often by Microsoft. Some people think it's a pretty sad state. I just think it's capitalism and evolution. Dodo birds are extinct, and so is Visicalc. I don't want to be extinct, so I try to learn from the mistakes of the companies that have tried to go up against Microsoft. It's easy for me because I was inside and I know something about the way R&D worked at Microsoft. I've tried to share many of these lessons on my site.
To succeed in commercial software you have to get beyond being shrill and angry about Microsoft. You have to be cool headed and smart and study the past and make the right decisions for your company, not the right decisions for some arbitrary sense of aesthetics (although of course I am as big a fan of clean documented code as anyone.)
Production code is not so pretty. Open source code is not so pretty. No real code is all that pretty. It takes time to study it, understand it, and read it, to understand how it got the way it is. The more widely the code is used, the more true that is. For Fog Creek's latest software product, CityDesk, we stayed up one night tracking down a bug that only happened on Chinese Windows, where asc(chr(x)) turned out not to be equal to x, an assumption we had been making. How many of you ever thought about getting your code to work on Chinese Windows? No matter how well that piece of code was designed, I'm sorry, I've been programming for 20 years and I never realized that asc(chr(x)) was not always equal to x on some platforms, and I designed it wrong, and until someone tried it on Chinese Windows, I never would have known. Now the code uses byte arrays instead of strings and doesn't have that problem. There's a nice comment in the code saying "use byte arrays instead of strings because of MBCS versions of Windows." The code now works perfectly, but the byte arrays are a little bit uglier than strings. If ten years from now somebody rewrites CityDesk from scratch, I'll guarantee you that 95% of the Windows programmers working today would make the same mistake again, and stay up all night again.
If a piece of your code is ugly and doesn't work, by all means, rewrite that piece. If it's ugly and works perfectly, you're wasting valuable hours rewriting it, time that could be spent doing something that will gain you market share. If you really have an undecipherable mess of spaghetti, 9 times out of 10 you're just being lazy about deciphering it because it seems like more fun to create it from scratch, but it's the ultimate in arrogance to think that your newly created from-scratch version is going to be all that great.
Joel Spolsky
spolsky@panix.com
Joel On Software
From what I've seen, a complete code rewrite is what happens when requirements were failed to be met. Usually some novice designer comes in and fails to capture the requirements. They either blindly implement it leaving lots of holes or keep going back to marketing so often finding so many uttlery useless boundary conditions that the thing takes forever to write.
A code rewrite is what a novice will do when they've insufficiently captured requirements.
You can get one step closer to marketing by quick prototyping. A professional will do a quick prototype in Perl, cut so many conditions out of the requirements that the excuse for a code rewrite is merely adding a CPAN module or rewriting a portion in C.
"And then when your wunderkind has left the company ... then what?"
This reminds me of the old saying "If one of your programmers is irreplaceable, fire him".
In my experience, many of these "superprogrammers" leave the company just as a product is being transitioned from a demo to a real product. They know their code is not going to hold up in the real world, so they move on to the next gullible company.
At the Joel on Software site he writes about his own product, CityDesk: "Porting *Joel on Software* to CityDesk involved a lot of manual copying-and-pasting -- something I never would have had the patience for if it wasn't for the opportunity to thoroughly test CityDesk."
The game of Go (Igo, Weiqi, Baduk) has the simplest concept and the deepest play.
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.
The balance of salary may be in managements court, out of your hands, but that's your fault - if you wanted the money game, why did you get into the code game?
Many programmers complain and complain about how their salesmen and managers know nothing about computers.
I ask how many programmers know the first real thing about management, about finance, about running a company.
It's right there in the language that's used: "who maintains the code" - who cares? We don't make code, we make products.
Anyhoo, that's my piece. If you knew your job as well as everyone elses, you'd be running your own company now. Not complaining about being a peon in someone else's.
The first line should have read:
Step 1: Take my boss... please.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The networking was ported over from OS/2 (NT 3.1 documentation proudly proclaimed this), but it never ran on the OS/2 subsystem.
Besides Windows/OS2 networking is crap.
A lot of the .coms that I've worked with were clueless, period. Engineers who thought they could write code; marketers who thought they knew marketing; CEO's who thought they could motivate people. Total BS.
> Seriously, something that boots from the OS/2 boot sector is surely some form of hacked OS/2.
Of course.
Just as Linux is obviously some form of Windows since I boot it via BootMagic on one machine, and Win98 is some form of Linux since I boot it from LILO on another.
..and both of these boot from the same boot sector as DOS, so they're obviously both DOS variants.
Biggest ever seen,
GOD this program's BIG,
MS Word XP!
Comes on ten CDs,
It requires... damn!
Word is fine, but jeez,
200 Megs of RAM?
Oh, Microsoft! Microsoft!
Bloatware all the way,
I've sat here installing Word,
Since breakfast yesterday!
Oh Microsoft, Microsoft,
Moderation, please!
Guess you haven't noticed,
4 Gig drives don't grow on treeeees!
Nope.
The right solution, which many would take if doing it again today, is to do it all in Unicode.
My Karma: ran over your Dogma
StrawberryFrog
Writing stuff on the whiteboard for design is fine, but guess what? If you don't write it down, and if you don't create the corresponding Visio class hierarchy diagrams, etc., half of the ideas from the whiteboard get lost when the next design meeting wipes the board clean.
I've seen it happen over and over and over again to developers I've worked with. Problems that were "solved" during a design meeting come back again because the developer didn't document the proposed solution. What's worse is that some great ideas get lost forever this way.
If you don't document your design, you are nothing but a wannabe "h4x0r".
for recording an mp3 for slashdot, at least!
It's "a lot", not "alot". Note the SPACE between the words.
</petpeeve>
that was kind of funny, actually...
Mozilla.org is a front organization for AOL. It only exists so that open source dupes can convince themselves that they are helping "the cause" and not Steve Case's wallet.
Go read Mozillazine and see these clowns live in OSS fantasy land where there are no deadlines and the users drive the features. Even mention Netscape and they go through the roof. Nooo, they cry, Netscape is just one of many "contributors" to Mozilla.org (ignoring the fact that most 3rd parties quit after continually being lied to about shipdates).
Mozilla.org will never mention Netscape. That would destroy the illusion.
I'm an IT consultant, making a living by developing applications for large companies. This is a totally different environment than the one described in this interview. My programs have one buyer, and typically run on a single machine.
I have been through a couple of code rewrites. In one project, we simply started from scratch. New database (Oracle 7 -> 8), new data model, new OS (UNIX -> NT) and a new programming language (C -> Java). I had the system requirements and the new data model as input, and I designed all the rest. I never looked at the original code, except to check the semantics of a few queries. (Joel's "hidden knowledge" doesn't apply here, since we were going to a new platform anyway.)
On another project, I redesigned and rewrote parts of the system. Each of those conversions have cost me dearly, and I wasn't really satisfied with the results. (In a partial rewrite, the new code needs to fit in with the existing system, and things get messy very quickly.) I wouldn't have done any of thos rewrites if the old architecture had been able to handle the new requirements.
Finally, I have one remark about aged code: comments are your friends. If you need to look at a piece of code twice before understanding it, you should add comments. If a particular construction is not obvious, explain why you do it that way.
I've only seen it done properly once. Literally half of the screen width was reserved for comments. (Yes, that is excessive, but it encourages people to write things there.) Every change to the code was tagged with the change request it belonged to. In many cases, the old code was still there, but commented out.
I'd argue that program code is not "hard to read" by itself. It is written that way. Programmers never consider the fact that their work will be read by humans (including themselves). Once you step out of that mindset, you will write readable code.
WWTTD?
He is correct that a rewrite is expensive, and can (and usually does) take a long time.
However, the mistake is not in doing the rewrite, but in not managing the process well.
The number one reason for doing a rewrite is for a cleaner, more stable architecture for writing new features against. The need for a new architecture is discovered in the process of adding new code to the old, and discovering issues that were not adequately addressed in the older version, or in learning better methodologies, or in the existence of better tools and programming processes.
Programs that have been improved by a total rewrite...
Windows NT/XP over DOS (and DOS windows)
Excel over Multimate
Word For Windows over Word for DOS.
Adobe Indesign over PageMaker
Quake over Doom
Quake II over Quake
That is off the top of my head...
ALL real successful software was origninally generated by extremely small teams of EXCELLENT *STAR* quality programmers. (There are not very many of them. If you don't believe that programming is a talent industry, you don't really understand what it takes to make successful commercial software).
The only real other option is unlimited resources (time and money) and it seems that where this exists is at Microsoft, and in some open-source projects.
The biggest problem comes from management believing that random team of programmers can create a new platform from scratch and that it can be done in a schedule that permits dropping the old code base.
ID does it by continuing to build new platforms with very small extremely talented teams.
ADOBE and Microsoft did it, with lots of time energy and effort, with parallel development against the old code base.
But this does not mean that it shouldn't be done. Those that do not rewrite eventually lose, because they are not able to respond to the market on the old code base, and are not able to make the kind of advances that a required by the customer base to upgrade if they use thier product already, or to switch or begin using their product if they hadn't already been convinced.
Managers are going to be disserved in the long term by reading Joels thoughts on the process, and ultimately the companies they work for will be eaten for lunch by new competitors that are not burdened by legacy code, but also really understand well the problem space they are trying to solve.
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.
Liberty.
Software projects fail because they fail to innovate in the places that matter:
1. Software architecture - sorry, but a browser written using monolithic C++ isn't going to be as maintainable as MS's COM-based architecture.
2. Features - new features have to actually be useful and work. Without this, no level of marketing is going to sell a piece of crap (Mozilla comes to mind).
3. Tools and languages - new tools and langs often hold the potential to simplify development drastically, but many managers deliberately avoid new tech because they think they are being competent by playing it safe. In reality, it's actually safer to move to newer tech than to let your code decay.
Engineering managers suck in general. The only good ones I ever knew were ones who knew how to make ballsy decisions that buck the trend of convenience and political correctness.
Yes folks, this method is absolutely tried and true. It has worked for the venerable software industry for years! There really is no other way to develop your software!
1.) A good piece of software starts by scratching where's there's no itch. But that doesn't matter, because with the right marketing, you can create an itch where one previously did not exist. Your software should be covered by as many US patents as possible to prevent other software developers from trying to scratch the same itch.
2.) Write everything yourself. Never reuse your own code or that of others. Modular code is your enemy. Avoid it like the plague.
3.) If your first implementation doesn't work, kludge it until it does.
4.) Interesting problems should be handed off to somebody else, or better yet, developed by a third party as an undocumented module with highly restrictive licensing. Your users will never know the difference.
5.) If you lose interest in a program, your last duty is to make it disappear from the face of the earth as quickly and quietly as possible. (this includes discontinuing all tech support and preferably changing your 800 number) Turning the software over to public domain or releasing the source code might somehow help a competitor.
6.) Treat your users as scum. You know far better than them how to develop the software and what features they need. If the complexity of the code base becomes overwhelming, you clearly need more middle managers to increase your programmers' productivity. Now is also a good time to double the price of the software to meet increased development costs.
7.) Never, ever release source code to any of your software. Your customers don't have any use for it anyhow and you might somehow help your competitors. If customers complain about a bug, wait 6 months before fixing it and charge a nominal fee plus shipping for the update. Requests for features should be written on small slips of paper, placed in a hat, and drawn at random no less than one year after a major version release.
8.) Your customers should have no part in the debugging effort. Beta-testers, if allowed, should be registered and be given time-expiring binaries only.
9.) Choice of data structures is of lower priority than rapid code development. Your users can always buy faster hardware.
10.) Do not attempt to foster an online community of your users. They'll just complain, flood your support resources, and worst, they might even band together and develop free software to replace their need for yours!
11.) The next best thing to having good ideas is stealing them from others and then claiming them as yours. (preferably with broad patents) The latter is always better as it saves you R&D costs.
12.) Often, the most striking and innovating solutions come from realizing that it's your users' needs that are wrong, not your software.
13.) Perfection (in design) is achieved when your software has enough features to run untolerably slow on anything but the fastest currently available hardware. Some hardware vendors may offer kickbacks for this service.
14.) As a tool, truly great software should have only one use. Your software should have safeguards to prevent customers from using it in ways you did not intend. Anyone who successfully finds new uses for your software should be sued immediately under the Digital Millenium Copyright Act.
15.) Don't be afraid to mangle data in any way you see fit. After all, yours is the only software that needs to access it anyhow. Leaving it intact may allow competing software to operate on the same data or encourage users to request new ways for your software to process the data.
16.) If your software requires its own language or command set, it should be as convoluted as possible to discourage users from using anything but the GUI you've designed. Syntax of the language should be based on an innovative combination of Old English, Arabic, Hiragana, and Swahili.
17.) Any secret encoding schemes or passwords critical to your software's security should be stored in a file called 'no_secrets_here.dat' to confuse would-be hackers. The contents should be ascii-armored and successively encrypted an even number of times using ROT-13. Anyone who dares break your security scheme can be sued under the Digital Millenium Copyright Act.
18.) Give your programmers the problems they are least interrested in. Otherwise, they might get excited and try to change the program specifications without first consulting middle management.
19.) Provided your lead software development manager has a medium at least as good as an overhead slide projector and knows how to increase productivity with threats of downsizing, you can always let go of a programmer or two.
This satire made possible by Eric Raymond, author of The Cathedral and the Bazaar. Read his works if you want your software to succeed instead. (-:
Too many MBAs at all levels and not enough people with a technical understanding of what could and needed to be built.
That pretty much says it all, doesn't it.
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
Commenting the code may be unimportant for many pieces of code, but there are many algorithms that you simply won't understand if they are written in C/C++/Java without comments in the code.
Sure, if you pack it in a module and say what it does, this should be sufficient, but unfortunately there is no code that is bug-free (except perhaps TeX:-) ), so it is always necessary to fix bugs. You cannot fix a bug if you don't understand how the algorithm works.
Sebastian
..Bob Abooey to you!
No, they produce much, much more. I wrote about 4000 lines of C++ in 2 months for the networking component of a Racing Game. It worked great when it was demoed in front of the Company Board. It was well commented. And then I spent three days typing up 47 pages of documentation on my work before adding and improving on the project.
So to reiterate, 2 months, at about 50 hours a week, writing 4000 lines of well commented, well formatted code, and writing complete system documentation for that component. Design Time included. And I am not an Uber-Programmer.
This is not hard. It's highly doable. Only the people who think it can't be done are the people who won't be able to do it.
"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, 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.
0 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).
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/fog00000
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.
What kind of 'solution' is this? This solution precludes running on Windows 95, which represents a good chunk of the user base.
I've read a number of "joel on software" rants in the past and in almost every case I've come to the conclusion that this guy is just a prat who's trading on a couple of years work at MS (which impresses some people).
A *fair* amount of what he has to say is valid (in other articles too), but generally he's just a bit clueless and one of those people you really want to avoid working for.
As long as the joels of the world keep mismanaging big software companies (I work for one, and believe me, they're full of them), software will continue to be buggy, delievered too early, never do what users want and be written by miserable people who don't love the product.
Thank god for open source...
One of the things that they go over in psych 101 is that good people(like 63%+) can do evil things (willingly shock people w/ 200+ volts) if the person that gives the order (doesn't have to even threaten) is the one that seams to have authority and there're no examples of rebellion...
Kinda intersting - the person giving the orders can morally justify that they did not (kill someone)/whatever and the person doing the killing/whatever can justify their actions by saying they had no choice - and everyone's happy.
But, frankly, I don't care. I loathe the kind of incrementalism that the software industry practices and that results in the kind of commercial software we are getting. If it takes 9 failures to produce something great on the 10th try, great, so be it. The alternative, decades of slowly evolving, uninspired, tedious, bloated, market dominant software is much worse for anybody other than the software publisher. Software needs competition and failure, just like biology and economics.
Of course, failures are painful. Investors and managers don't like them and will anything to avoid them. But, hey, that's probably one of the reasons I prefer open source software. On a project that has no commercial aspirations, you can afford to fail and start over.
"...I try to be as rational, logical, and non-religious about every decision I make because it's the only chance I have of succeeding..."
But many religions are very successful without worrying about being rational... or logical. How do you explain that!? Ha!
Interactive Visual Medical Dictionary
I'm not a Windows programmer, but don't you use API specs? It strikes me as a very risky way of programming to assume anything about the API not in the spec.
Sorry, but I disagree. Unless it can be deduced from the API spec that asc(chr(x)) equals x (which would be a bug in either the API or the spec if it doesn't hold unconditionally), I wouldn't call a piece of code which makes this mistake "well designed."
and arguably it still isn't today. AmiPro 3.0 beat Word in 1993 by a long way. The only reason it became No. 1 was by bundling it with Windows... Basically MS gave Word away as a gift.
If you have never used another Word processor (like e.g. StarOffice) you don't know what you are talking about.
I could cry if I look at the problems my colleagues have with their MS Word programs.
Moritz
The dodo died because man hunted them to extinction for pleasure (because "they looked funny"). Nothing to do with evolution.
It's all about compromise.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
That's what evolution is all about: survival of the fittest (and mankind is obviously part of the environment).
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.
...
IE does make money, in precisely the same way that the Windows Eplorer file manager makes money, and COMMAND.EXE makes money, and the CD Player makes money. It's cost is recouped on the sale of the OS into which it is packaged.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
"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."
So folks
OK, so that was partially tongue in cheek, but seriously, there are lots of times when such a drastic measure is just what the doctor ordered. You see, the biggest sin a company can make is not ensuring consistent variable naming, copious - quality - commenting, and solid and thorough documentation. This means, among other things
Maybe he should have a sister sight
JoelonSeriousHallucinogensMixedwithPshychtropics.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Not as often as I've seen
i++;
I'll admit
-- Oh Well
First, the question remains whether Java won't be a Microsoft killer. As applet it has not delivered what was expected (though it isn't dead yet), but at the server (servlets, EJB's etc) and in embedded devices (soon there is a JVM in all cell phones, and cell phones are predicted to at least partially replace the desktop computer) Java is very alive an a big threat to Microsoft.
He claims that Java is bulky and slow still, after 5 years, and C# is supposed to be winning because it "feels better" and is "snappier"? Where on earth did this guy get such benchmarks from to prove this? It simply is NOT TRUE. Java performance has come a long way, and I haven't seen any evidence to date that C# is faster nor a better language. In fact C# is lacking in one major area, checked exceptions (meaning you are not obliged to catch or explicitly throw exceptions, which will lead to massively unreliable C# code bombing out all over the place).
MSFT once more is pushing an unproven and less superior alternative, just and only because it wasn't able to apply it's embrace and extend strategy to Java, that is the ONLY reason MSFT rejected Java.
Exactly the Java/C# example shows that Microsoft may drive other companies or technologies out of business, not because it makes less mistakes or has more technical excellence, but just be unethical tactics, misleading, false promises and massive marketing, leveraging its OS monopoly to kill off competitors.
Real story.
...and I'm sure, these comments will be mostly slammed by the lame self-centered idiocy that is slashdot as its myopic best.
,very accurate - what about the programmer who comes back to his own code several weeks, months, or years later and has to figure out again from scratch what the hell he was thinking when he wrote this crap... and then realizes he wrote it... Code is completely useless if it can't be maintained and have clarity - cleverness is unnecessary and there is an elegance in clarity.
Very good
...management. Where else ? and corporate morality (doesn't really exist, always justified in terms of creating shareholder value, a slippery term, justifying things like Nestle sending baby food to Africa in the 1980s)
One of the things in particular that striked me as suprisingly simple but yet powerful is the Zero Defect concept : in theory, you try to eliminate all bugs before adding any new code to a product. The reasons being
All in all, I think this concept makes a good argument for refactoring, redesigning, partial rewrites maybe. He's just saying that it often does not make sense to fix one bug by rewriting a piece of code, in the process undoing the fixes to ten earlier bugs. So before you go trashing this guy for being a total moron, check out his site...
The right solution is not Unicode either.
How would you get a single code point for a character which is in the surrogate pair region?
Since CityDesk is written in VB6 (rigorous documentation has never been it's strong point), then one wonders why FogCreek didn't use the Unicode-aware AscW function, rather than the ASCII Asc function.
This leads us nicely to the people who wrote the documentation for VB6. Well, VB6 is based originally on VBA1, from around 1992. This originated from the MS Excel team, of which the program manager responsible for VBA was.....yes...jspolsky who wrote the original VBA spec from which the documentation was produced.
"The right solution, which many would take if doing it again today, is to do it all in Unicode."
Isn't there several way to encode a given char in Unicode?
Other problem is unrealistic goals for profits. Big companies don't even think of single-payment licenses anymore, they're after continuous cash flows from users. Until then they're shortening their release cycles from years to months and selling once free updates now as new versions, hoping their customers to get used to the idea of constant upgradings.
"Think constant learning. That's what todays people need to stay productive. Same goes for our software!" They're hoping we begin to think that all software is like antivirus scanners: update update update! "World changes every day, keep up and hang on! We help you!"
It's just the way business works: predictability means everything and steady income flow is predictable. Marketing new stuff is not.
Preserve old classics: copy your collection onto all hard drives.
Even with the huge DaimlerChrysler merger, GM and Ford still have revenues that dwarf the competition. Ford has 1.5 times the revenue of Toyota, 2.5 times the revenue of Volkwagen, 3.5 times the revenue of Honda or Nissan, and 5 times BMW or Mitsubishi.
Ford also owns Aston Martin, Jaguar, Volvo, Land Rover, 1/3 of Mazda, and 10% of Kia. GM owns Opel, Vauxhall, 20% of Fiat, half of Saab, half of Isuzu, 20% of Suzuki, and one-quarter of Subaru.
The American auto industry made horrible mistakes from 1967 straight through 1978. Yet they still dwarf the competition. If you call that not working out, I'd love to see what you actually consider success!
Current shipping home-user version ofWindows: WinXP. Versions before that: WinMe, Win98, Win95. It is normal good practice to ensure that your software runs on the latest and previous version of it's platform.
Conclusion: Anyone targeting the version of an OS four revisions back, in a new software project deserves all the pain & suffering that they get.
Everybody so far seems to be saying that netscape 5/mozilla was a complete rewrite. Which is true, but its missing the point that netscape 4 was a complete rewrite of version 3. And that's where things started to go badly wrong...
-Dom
the evil comes from the monopoly. "...absolute power corrupts absolutely"
It doesn't matter what technology you pick, the user doesn't care, just so long as it works. It matters in how quickly it allows you to get a product out the door that people are going to buy....
take the unicode example offered...
Let's be realistic, the bulk of your sales are likely going to be in the US, Canada, and the EU. All places you can get by with 8 bit ascii. By the time your package gets to the point where you need Arabic, and Chinese, and Japansese versions, you're likely going to be long gone from the project and stiffs who specialize in that conversion will be making it.
So unless using Unicode reduces your time to market significantly, it doesn't make the company any money, and you should save it for your recreational programming.
> 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).
Actually paining drawing and whiteboards are good tools in discssing problems with other programers. Before juming into around 30000 or 300000 rows of code a good drawing in maybe Visio is realy nice. You know a picture sais more that 1000 words.
Technically the dont sell MSIE - it can take up the 500M cause its given away... HOWEVER what they lurn on IE that they give away - can quickly go into their other products (which they charge for) thus while IE is free and costs the company money to produce, the goal of haveing the development flaws show up on an overly tested program before the code is moved to some program they want to charge for is actually quite smart, whos going to take them to court for fuxing up IE? you probably cant cause its free... but if they fuxed up in your precious MSOffice you would go mad, so its actually quite smart they make IE in this way, and we all get the benefits of IE while waiting for the next version of office (unless your smart enough to use Star Office)...
Theres one sure fire way to get your software project to fail.....
;)
Get EA to buy your company
Well it worked for Lord British.....
1. You are a moron.
2. Open source programmers simply don't care if AOL will make more or less money off their work. Their problem is completely different -- they have to have a standards-compliant browser on non-Microsoft platforms that they happen to use, and the only viable project is still Mozilla -- Opera and Konqueror have their inherent limitations precisely because they became faster by ignoring or breaking cumbersone standards, and there is no reasonable way to fix the standard in the situation where W3C has basically idiots+Microsoft at the helm. Mozilla, by following W3C madness such as DOM and countless stylesheets models, allows people such as myself to keep Microsoft products away from their desktops, and that goal has nothing to do with AOL or any other company's money.
Contrary to the popular belief, there indeed is no God.
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.
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.
Oh great - all that talk about Microsoft eating so-and-so's lunch made me get hungry...
You confuse redesign with rewrite. Moving wordperfect from assembler to C would be a redesign; a major undertaking. Taking the WordPerfect, say, 6.0 codebase, throwing it out, and rewriting it, in the same language, with your end goal being not to have to reprint the user docs (i.e. nothing changes) just because 'the old code looked poor' would be a rewrite.
Vintage computer games and RPG books available. Email me if you're interested.
The modern software project is run by liberal arts majors who are not software architects.
The people who make the decisions are not engineers but marketting people.
Interfaces are not designed with reuse and ease of understandability, but as ways to cripple potential competitors.
If you are an American White male with an engineering degree you probably don't have a job if you have been a software architect for more than five years.
So. . . the software as designed by corporations and money mongering shrink wrap software companies is CRAP.
I am a seasoned hard-core C/C++ guy who is an AMERICAN. There are no jobs for me.
I think I'll say I'm from Bangalore. Then I can get a job even if I am just faking.
Or, if I had a two year degree, I would be writing a TCP/IP stack for my last company. You can't have someone who you have to pay the real coin.
Companies who think that engineers are generic and that one is the same as another are IDIOTS. Engineers are like athletes. Some are MUCH better than others. But modern money monger companies think with their wallet.
Methodology? They don't know or care. Fugde it and ship it. If there are 'bugs' then tell the clients that the software was not installed properly.
Hey, if all American's are out of jobs, it doesn't matter what we do in Afghanastan. We have already lost the war.
I say send them all back to India and China. Oh, I am a racist because I want a job in my home town.
Do you think that if I moved to India that I could get a job? Or China? I doubt it.
So let's send these people back to where they are from so that they can improve things there. Oh, but they want my house and my job. Oh, I'm sorry I don't have a job.
Are there any American Engineers left working?
I haven't had an interview with an American hiring manager in months.
If I pretend I am Indian, I could get a bunch of interviews.
Holy crap! That's the exact situation that I'm in! My boss in an army computer unit is a former artillary commander! Doesn't know shit about computers and drives all the admins and programmers out of their minds!
Wow, I did not know this. Why didn't someone tell me. I better stop using their compilers. Damn.
That's exactly why Wordperfect never standed a change in Europe in front of MS Word.
You cant just keep fixing something. Your clients wanted an airplane. They couldnt afford one. they bought a car. Theve been paying you for years to slowly graft propellers and wings to the car. Now, they realize they really need a boat. But, being cheap, and following this guys idea, they dont want to just redoit, they want you do tie pontoons to the car.
Never did anyone ever ask if you could actually convert a car to an airplane, or the result to a boat. What you end up with is a car that cant turn, a plane that cant fly, and a boat that will sink faster than a brick.
Fix bugs, sure, add a few features, sure. but when what you want to do ceases to be possible with the base yove got, youve got to leave it behind.
Also, this model of never rewrite, assumes that you always have the best people working on it, and that they all know everything, and that the world of software development never changes. Sure, I could fix the code that the inexperienced co-op down the hall wrote, and make it do something else, but I know much more than him, know better tools, better designs, better implemetataion strategies. So I could either spend a week fixing this crap, or I could just redoit with the right design, the right tools, and the right implementation, and not only be done sooner, but have a much better product.
As another poster said, there is often good information in a piece of code thats been worked on for years. There are also crumbs of attempts in the past that went no where. And stuff that doesnt work, but you dont know it, cause its never been used until you made that last little fix. It can also be full of dumb ideas, bad implementations, and simple old ideas that dont work anymore.
So, if your a wank that doesnt know anything, and your given code written by someone that knows what they are doing, read it. youll learn something. If in stead, your a good programer, and given something written by someone with exactly 3 hours of experience programming, it may be much easier to just rewrite it, rather than try to fix it.
or even if not easier, much better, and in the long run, more supportable. much small, tight, well thought out unix code is still being run, because it was done well first, with out regards to getting it out the door. Old dos and win31 code that was pounded out the door as quick as possible was thrown away years ago.
-sbos
-glo
I'm not weighing in at all on the question of which is faster, because I honestly don't know. But I do feel obligated to point out that very limited benchmarks on a site that is clearly focused on promoting .Net development are barely worth reading much less citing as an example of something. The chances of these benchmarks representing anything like actual facts are so slim they aren't worth considering.
As a programmer, and a user I am sick to death of feature rich software that doesn't work. I don't care if you have to re-write the whole thing or just part of it, but market driven software development does not make me productive in my daily work.
When software vendors throw basic funtionality to the wind and rush to market with new features and new versions and the new software STILL doesn't work, I get very frustrated.
I just want software that works. All the time. 100% as advertised and according to the documentation. I don't need features. I need basic functionality.. bedrock. More and more I am finding that I have to write things myself to get that. The commercial software quality just isn't there... and how can it be?
The quality isn't there in the development tools or the operating system or the firmware. I frequently come across situations where documented functionality simply does not work as documented or doesn't work at all or locks up something else. This is a case where, in my opinion, business interests (e.g. making a profit) have occluded the central purpose of writing software: to make information systems into useful, reliable tools.
Please.. just give me software that WORKS. I'll gladly pay top dollar. We can worry about the "features" later.
Knowledge is like ignorance.. too much can be just as bad as not enough.
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.
Believe in things of which no person has ever learned
Cat got your tongue? (something important seems to be missing from your comment ... like the body or the subject!)
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.
That isn't creative and innovative, that is wasteful. I would hate to see how much money and resources M$ wastes on failed projects that we never hear about.
My beliefs do not require that you agree with them.
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.
The simple answer to this solution is to ask about what the executive staff is like before going to work at a place. Your interview should be as much about them as it is you..
-jj-
"As a Technical Manager at Juno Online Services, Joel designed and implemented many of the Internet features of Juno."
'Nuf said.
~REZ~ #43301. Who'd fake being me anyway?
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
but he falls victim to th edesire to overstate something and make it into an absoute.
Very few places where a total re-write is justified is one. While IMHO, this should be very carefully decided upon, all those little hairs and bug fixes add up. Eventually the code loses it's maintainability because it's so hard to read. What's the point of going through and maintaining code that's held together with duct tape (if you're lucky) or bubble-gum.
Further, what about improvements in HW and SW development tools/languages/methods? I think each has a viable arguement for re-writing code. If your code isn't too tightly coupled you can do the re-write piecemeal, module at a time. This is obvoiusly better than trying to re-write an entire project.
The other argument against his theory IS MS. I mean this seriously, not in the traditional screw-MS mentality. Do people REALLY think folks are getting the VALUE they should out of Windows, esp given its SIZE?
Let's not forget that NT was originally written by the same guy who led the VMS effort. VMS - dead or not - was an excellent OS - stable and multitasking. I don't really believe that MS has taken advantage of the skill of this gentleman (forget his name) and worked to make Windows have those same qualities...
Computer Science is Applied Philosophy
For what it's worth... I agree with the guy that re-writes shouldn't be done all the time. If your a manager and a programmer insists on starting from scratch it's a good idea to get cost evaluations and time lines for the work. However thinking you never have to re-write is going to the other extreme.
It's a judgement call. I have passed on code and programs to my boss that I know was messy but let it go because to start from scratch would take too long and wasn't worth the expenditure. Other times I did do the re-write and it save us time and headaches.
The website doesn't look like a news reporting organization. They may be more concerned with promotion that news based on a quick search around the site. It also seems more business oriented than programming centric. From a business perspective and everything Joel talked about was more around quick turn around and generating quick revenue. Making due gets your product out the door quicker and money from customers faster but it doesn't guarantee you'll still be around 20 years from now.
Of course you don't hire one wunderkind, you hire five or six, and team them up in pairs (a good Extreme Programming tip). But you don't hire 20 average joes. Let the competition hire them and suffer.
Sure the program is efficient and runs like a dream right now. Fat load of good that does you if it breaks or needs to be extended,
If it runs like a dream, you get to sell it right? And make money, right? Out the door, fast, right, make the window of opportunity.
Contrary to popular belief design for extensibility is not hard -- it comes naturally to experienced coders.
If you can throw letters down in Emacs so quickly, why can't you seem to find time to have one line out of 15 be in English?
Perhaps the English would not be as descriptive or useful as the 15 lines of code, and very distracting. The kinds of docs you want are along the lines of "this rebalances a 2-3 tree". You don't want an essay explaining 2-3 trees, but that's what many call for.
You could've hired me.
His site's FAQ ("What's going on here?") includes unsolicited praise for the discussion group: "The forum is great because you attracted a group of thoughtful people who can write clearly. No flames. No all caps. No crap. Little HTML showing where it shouldn't. No one replying just to be the first to reply."
And then he gets featured on Slashdot. Poor Joel. Poor discussion group.
"Joel takes particular pride in the fact that on the day Bill Gates asked if date math functions were compatible across the company's different procedure and function libraries, he, Joel Spolsky, was able to reassure the great man himself that with the exception of January and February 1900, all Microsoft application libraries counted dates the same way."
This is a joke, right? Like "a little bit pregnant" or "extended subset of?"
Besides, I personally encountered 4-year shift issues moving Excel spreadsheets between Windows and the Mac (1904 became 1900), so what was he talking about? Is this more doublespeak, like "you'll never see any UAE errors under Windows 3.1" because the name of the error was changed from UAE to GPF? "Sure, end-users may encounter all sorts of date problems but you can rest assured none of them are the result of anything in our 'applications libraries'?"
"How to Do Nothing," kids activities, back in print!
Which is all the more reason that if you're going to take on Microsoft, you *have* to be smart about your approach. Because Microsoft is so powerful, it raises the level of software engineering.
If the little guy is getting squashed, then the little guy has no reason stepping into the ring in the first place.
ID Software is an example of how to do things right. ID releases a major product once every two years, and a majority of their revenue is based on this product. If they release a sub-par product, they will not have another chance to recoup their losses for another two years.
But the fact of the matter is, ID's sales have always outpaced Microsoft(maybe with the exception of AOE).
Even though ID Software is a company of only a handful of employees, because they consistantly make smart decisions they are competitve. ID knows it place, knows the stakes, and knows the consequences of it not releasing a good product. And *that* is why they compete and beat giants like Microsoft. Consistently good business and design decisions. There's no room for anything less.
"Shake yur bon bon"
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.
healyourchurchwebsite.com - WWJB?
I found the following references to be excellent references on the success/failure of software projects:
Anti Patterns
Refactoring Software, Architectures, and Projects in Crisis
William J. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick III, Thomas J. Mowbray
ISBN 0-471-19713-0 [1998]
John Wiley & Sons Inc.
Death March
The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects
Edward Yourdon
ISBN 0-13-748310-4 [1997]
Prentice Hall PTR
I highly recommend the above two references.
I have had the misfortune to work at my last two jobs at companies that fit the profiles as described in the above two references.
Politics is the Great Equalizer for People of Lesser Abilities.
The second fatal assumption is believing that Sun actually cares about Java being run on desktop PCs. Sun in more concerned about future devices such as cell phones, media, storage, entertainment systems, etc.. If microsoft focuses its efforts on the desktop, all the better for them. Sun has a better shot with consumer goods manufacturers because they don't want microsoft eating into their businesses although the competition is more intense... as it should be. Cringley does alot better when he talks about things he knows about.
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.
--
The Bailiwick - DESIGNHUB2005
Heya Bob, from your old pal FDR. (Yeah, I'm still around, just in a different name.)
Bite my yammer.
-- the most controversial site on the Web
But many religions are very successful without worrying about being rational... or logical.
How do you explain that!?
Simple. The above statement about religions is false.
To understand why, try substituting the words "relying exclusively upon" for your words, "worrying" and examine the semantic difference. Or similarly remove the words "worrying about" and the difference between your false statement, and a more rational one.
Nevertheless, your post conveyed a point pretty well, without being particularly rational. Perhaps religions work the same way, eh?
Why would a religion attempting to communicate with and to people, whether made by man or by god, adhere to the formalism you seek and find in science?
If you have the luxery of time when such protocols stablilize, then, by all means, embelish.
The correct code production rates that you need are on the order of 1000-5000 lines of correct code a week, or at least with defect rates over the life of use down to 0.1 line per kloc.
The bottom line is that I've seen people apply best practices and get a correct code production rate of around 6-8 LOC/hour. I've seen (and apply) extreme programming techniques, and routinely beat that by a factor of five, sometimes much more (when the code is routine, like the umpteenth generic marshalling/serialization package you've written, or recursive-descent parser).
You could've hired me.
I just thought it was funny that an article on "How to make software projects fail" followed immediately after an article related to OS/2.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
The one thing that really gets ME about java (which I like, btw)..... is how damn confusing it is to figure out what Sun is talking about most of the time.
Now.. I'm not a software engineer... I'm not a professional programmer.. though I do code quite a bit. But I'm very computer savvy... and I find it *very* difficult, in reading through sun's Java stuff, to figure out what the hell they are talking about. I know there is something there... I know they have some really nice ideas and stuff.. but.. it's very, very confusing.
And I just have to wonder.. if I can't figure it out.. who can?
You see. that's where MS comes in... even if they sacrifice technical superiority.... It seems to me that Sun's stuff is just aimed at too high a level. You need some serious software engineering people to figure out how to use some of Sun's stuff.. with MS.. it's a level or two lower (and yes, less sophisticated)
So problem engineering destroyed these companies according to Joel, the engineer? That's odd because marketing was the problem from a marketer's point of view.
Every geek should probably read "Crossing the Chasm" by Geoffrey Moore, the marketer. All of the same companies appear in his books. Overall, "Crossing the Chasm" and "Inside the Tornado" make insightful reads.
For example, a novice C programmer tends to go into excessive detail about the use of null chars to terminate strings.
This is a way of taking notes inline the code ,instead of somewhere else, on the aspects of the language you are using until you memorize that feature/requirement by default. Maybe we need an editor that hides the comments under some pre-given grade by the author (if I can judge the grade of the comment I wrote properly). Everybody would adjust their viewing preferences just as in /. here.
Do programming classes still make you put a comment on each line of code? E.g.: /* set x to y plus offset of 3 */
x = y + 3;
Come out of that sort of training, and it takes a while to realize that comments aren't stupid, your teacher was. Comments should NOT say what a line of code does. Except in obfuscated code contests, if what one line does isn't obvious, either the writer or the reader is incompetent.
Every module and function should have a block of comments to say what the module or function does, what the function arguments are, and especially give the specs, and tell what assumptions are hidden in the interface If possible, go back after software testing is done and note the conditions in which the module was tested -- this is invaluable for re-use, since it avoids the assumption that "this part was thoroughly tested", when it wasn't actually tested for what is now being done with it. Every time someone has to update the program, it's a "code re-use" for the modules that weren't touched...
In large functions, you might want to put in comments for each major block of code, but first think about whether the function ought to be split up... Line by line comments are needed only when you are doing something that is unusual, not straightforward, or handling an issue not stated in the specs; say WHY you are doing it that way, or why you have to do it at all.
and the backwards compatibility with DOS was also part of the design goals.
So there is no direct link between code reuse and compatibility. The is such a strong link only when the specs are inexistant or screwed up, which leads to the necessity to support bugs and arbitrary interpretations for 100% compatibility.
But those are all pretty broad and vague generalities. It is better to judge each individual on their own merits.
Uhh... Okay. Share the roads of your city with Asian drivers, and you'll start to draw your own broad conclusions: they're dangerous.
It's probably cultural, but there's also the possibility that the shape of Asian eyes reduces their peripheral vision, making the silly little Acura in the next lane veer in front of your Dodge Ram, a vehicle more than twice the size and mass of his tinfoil shitbox, because he allegedly didn't see you.
Evidently, I won. But I digress.
I'm not sure why one can't use the more meaningful baDest or baSource, rather than the baBuff. The adoption of hungarian notation does not force the creation of stupid names (like baBuff).
Hungarian like notation is useful because it allows information that commonly is embedded in names anyway to be done in a consistent manner.
I personally find "strict" hungarian notation confusing.
The LPCSTR stuff was only necessary for mixed-memory model Windows. There's no real reason for it in a pure 32bit world.
I'm surprised to see such a programmer-bashing article linked from Slashdot. I'm glad it was, though; it was interesting. It bashed users pretty badly too, and had a very silly outlook on bloat.
The real cost of bloat isn't disk space or even memory, Joel; it's bugs.
This "SoftwareMarketSolution" site seems to be by and for marketroids. There's a lot of the testosterone-filled jargon of marketing in there. Joel refers to a "great book" called _High St@kes, No Prisoners_, a title which puts my back up pretty badly. The focus all throughout is not on how to deliver value to customers but rather how to beat the competition.
I see little merit here.
Ben "You have your mind on computers, it seems."
Their minds don't work like that
This could easily be construed as racism (before anyone marks me down for being a troll, no I am not necessarily accusing the poster of being racist).
Asian culture, and Indian culture particularly (the only one I know much about) places very high emphasis upon respect for authority, especially with respect to knowledge. This has many important consequences, of which a couple are:
1) The education system emphasises learning by rote over learning problem-solving skills. It is not unusual to see people reciting books in order to learn them by heart who do not understand much of what they read. These people go on to do very well in Indian exams.
2) There are a lot of exceptionally good Indian mathematicians and theoretical physicists. This is probably because mathematics is a deductive system rather than a hypotheco-inductive system like experimental physics, and hence is easier for people who have studied under the education system.
The most important thing to remember though is that there are many many Indians (some of whom I am lucky enough to know) who are extremely creative and intelligent people, despite their flawed education system.
Brain structure displays a disappearingly small variance across race. The vast majority of genetic differences between races are, unsurprisingly, concerned with external body morphology. If you understand "how your mind works" to be a combination of (racially independent) genetic brain structure plus, more importantly, very powerful cultural influence, then yes, the poster is to some extent correct, except that of course this is a massive generalisation and the number of Asians for whom it is *not* true is probably comparable in size to the population of the US.
Recently, I've stumbled upon (read: been forced to use) a nifty notation for OO stuff. For variables, the first letter gives the scope of the variable:
p_foo means variable foo is a parameter (passed in to the method)
m_foo means variable foo is a member variable.
l_foo means variable foo is a local variable, created in this method.
> 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.
Don't be fooled. The money for developing IE is hidden in the price you pay for M$ Windows(and other M$ products). There is no such thing as free beer. The free IE just made the price for other M$ products increase, thats where they get the money back from...
I'd say not being able to fly and a lack of resistance to diseases and being outcompeted by newly introduced European animals (and vermin) is a severe Evolutionary disadvantage.
Its More important what he was saying than how exactly he said it.
That even got a chuckle out of my frosty girlfriend.
Did they actually talk to him, or just read his articles and construct what they think would be Joel's responses? If you read his articles (I don't agree with all of them, but they do make you think) you'll notice a lot of similarities, even in wording. Or maybe Joel read all his stuff the night before for background notes.
I'm paraphrasing what the Resource Kit says, not what has passed C2 classifications. I have seen elsewhere that Windows is C2 complient when turned into a standalone box with no external access.
Which is why I commented.
Its a form of the Big Lie - that "common thought" spreads, and soon its the "truth". Just like you said "I've seen.."
Right.
But it was 3.5, with a certain service pack, and on 2 Pentiums from Compaq and 1 Alpha from DEC. That's the *only* C2 certified NT that there ever has been.
NT 4 was submitted and failed. So they insinuate that its "C2" with a program, with comments - and in Official Training they don't make the distinction.
So I felt the need to point that out when you made the comment - NT 3.51 and above is not, (nor likely ever will be) C2 certified.
Addison
Normally, i don't respond to AC posters, but you weren't obnoxious and you seemed to be actually trying to deal with my points, so, out of courtesy (can i say that on /.?), here's a rather abbreviated response (prob still 2 long for lameness)
/. kinda way, but actually i did, i appreciate your literalism, but, i've been dealing with these kind of coders for a long time (and in large teams), so my reaction is about 70% to Joel's words and about 30% to what i've SEEN when you design/code his way:
....and each of them getting bloatier, your hardware vendor has lost his ability to do any major redesign of the h/w without either breaking his h/w or your computer. As someone pointed out earlier in this thread, that leads, for example, to the microcode solution (and in devices, shimware). The best example of this is both Transmeta and Intel, both of whom have to mask more efficent cpu designs under an inefficient microcode layer in order not to break the installed base. Transmeta (bless them) is at least doing it by design.
"I don't think you read it very closely. "
Not to be pissy in that
eliminating our agreements, here's my response
1. More features are always better features
Ok, but
2. Coders are not responsible for optimization
YOU: "He didn't say that. He said that most memory "optimization" doesn't actually help much, which is true."
I wasn't referring to his quote about memory optimization, I was referring to his repeated statements about "bloatware" and "features". Optimization is not merely about reducing run times or footprint, it also is about choosing the right design and architecture. If you have a program where a given feature is used >1% of the time by >1% of the users and you keep it in new version, you have "non-optimized" code. Giving marketing droids free reign to include features leads to bloatware products like Word and Excel, where even MS acknowledges that most users NEVER use most features. I think Joel makes it pretty clear right here with "For one, if programmers don't have to worry about how large their code is, they can ship it sooner". That's a defintion of the ESSENCE of non-optimized software design.
3. Hardware vendors must not change h/w designs that would break installed base, even to improve their architecture
YOU: "He didn't say that at all."
No, he sure didn't SAY it. Because essential to Joel's thinking on code/design is that you "fix it in the next version". He makes that perfectly clear in numerous places in the interview. Well, if you have version after version
4. Your s/w is SOOOO... important that shipping delays for optimization/tuning/additional debugging are not to be accepted
YOU: "You threw in that "additional debugging". He never advocated shipping bugs. As for optimization and tuning... he didn't say that there are no circumstances under which you can delay the software for optimization. He did say that it's not generally a good idea... and he's right. Generally, it's better to ship something correct but slow on time, and release updates, so that you at least have something on the market, unless the thing is so unbearably slow that it's unusable. "
WHOA! "Generally, it's better to ship something correct but slow on time", REALLY? better for WHO? Certainly NOT the user (Wordperfect Windows 6, dBase Windows 1, Access 1.0 and the 1.1 release are perfect examples of this) who ends up paying $$$$$ for crap and then hope the vendor is going to get around to fixing it. And on your/his point about "it's not generally a good idea.." to delay RTM/ship for additional optimization, if you've lead a commericial software team (even a small one) you know "it's not a good idea..." from managment, will turn into "Don't". by the time it gets to your coders.
6. There's never a reason to rewrite extent code, EVER...(here's my nominee for that reason -- Microsoft Outlook)
YOU: "No, he said there's never a reason for a ground-up rewrite --- and he's right. Refactoring, on the other hand, is great: rewriting extant code a bit at a time."
Now, it's YOU who are taking him out of context (as you have accused me of doing). NOT ONCE does he mention "refactoring" code. The closest he comes to it is suggesting that if something is really broken, you can rewrite it a little bit at a time.
There are actually LOTS of reasons to do a ground up rewrite. I wasn't being sarcastic when i mentioned Outlook, nor was i bashing MS, i know and like a lot of them and respect many of their products. Many Softies are terminally embarassed by Outlook and all the problems it has caused.
The architectural design of Outlook is so poor that it has led to billions of dollars of lost data and systems damage. Yet, because of all of the things that Joel has promoted (and MS' ego), they keep recreating that program, version after version. The mistakes of the earlier versions are retained and the new version have new exploits created as a consequence of the old architecture
7. Architecture is secondary to UI, maintanence of the UI experience is the MOST important standard
YOU:"I don't recall him saying that either, but maybe I missed it."
I can see how, if you don't do a lot of design or architecture, how that would be non-obivous.
Simply put, if you can't ever change the base code, you can't ever effectively change the UI, as the integration between the UI and base code is (or should be) the tightest of all the design bindings in the entire OS or App. Witness "Windows Explorer", it's a clunky, ugly, non-effective piece of crap because it is bound to the files systems design and the UI. Everyone hates it (incl many Softies), but you can't do much, if anything, about it.
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.
YOU: "Yeah, that is redesign, regardless of whether you want to use some derogatory term like "patching" or not."
NOPE, sorry, these are both very clear "terms of art" with five decades of clear definition and usage behind them. You don't "design" a patch they way you "redesign" a app, system or even a feature.
Patches fix things that are broken. Usu with a "one patch" to "one problem" ratio, unless you really messed up your design and QC (if you want to see what happens when you attempt to "redesign" by "patch" -- see the NT4 "Service Pack of Death").
"Redesign" is not done at the "support" or "QC" level, but at the "architectural" level, redesign consists of stepping back from the extent product and saying "how can we do this better next time?" NOT "How can we save ourselves some future design time by using this patch to throw in additional features?"
........
Ten quid, she's so easy to blind. And not a word is spoken...
So let me get this straight..... The .NET programming model is basically designed to object-orient the Win32 API which until now has been split into many different object frameworks (MFC, VCL , Visual Basic etc)
How is this _not_ a rewrite of the Windows API? Sure, you could argue it's just a wrapper around it, but as the idea is that developers should never use the API themselves, it's basically as if they are rewriting it.
I have to say that although Joel is obviously a talented guy, I disagree with him on many things. Especially his ideas about rewriting code.
Yeah, sometimes rewrites aren't needed, and it makes more financial sense to carry on the old code. But look at Netscape - no matter how much he slags it off, he can't avoid the fact that Mozilla is now light-years ahead of IE in terms of, ooh, I don't know, let's pick XML support. IE6 proudly trumpets support for DOM/CSS Level 1, while the Moz crew are starting on Level 3.
IE may be the browser most used today, because Netscape did a rewrite. But there's another round of browser wars coming, and this time, Netscape has fundamentally better product. It's taken a long time, but Mozilla will last for many years. How long with the IE rendering engine last, before people realise it's hopelessly clunky, out of date, and well.... hairy? Not long I'd bet
Sorry Joel, but the view that rewrites are never good is too simple. Sometimes, they're the only true way forward.
Joel seems to be a strong advocate of code reuse and understands the stalwart value of "old code". Why then, does his comany, Fog Creek Software implement their own proprietary bug tracking system, "FogBugz" when there are perfectly awesome bug tracking systems out there, like Bugzilla?
Share the roads of your city with Asian drivers
Uhh. I live in Austin, TX. We've got lots of asian drivers. I don't think they are any worse than the hispanic drivers, black drivers or rednecks driving their red F150's. Everyone around here drives like fscking maniacs. Either way too fast or way too slow and changing lanes without looking seems like standard proceedure regardless of racial background.
Y'all seem to be missing the point here.
Engineering practices do come into play, I'm sure. Commenting code, etc. yadda yadda, all very important.
Let's just assume you have competent engineers (and managers) who know how to do their jobs.
Then, how do you make a software project fail?
Turn over engineering decisions to marketing and sales people so that the engineers CAN'T do their jobs.
I've been in this business for 10 years, and I work for a fairly large software company, and I'm telling you, this is the #1 problem we all face.
If you have a sales guy who's the golfing buddy of the CEO - you'll get features, MAJOR features, added to a project 2 weeks from the ship date.
And if the CEO's OTHER golfing buddy is the head of marketing, that ship date WILL NOT SLIP, because hell, you don't want to piss off the trade rags who are all lined up to do reviews on your product and publish on that date. Otherwise the next trade show will be awkward.
These are pretty simple examples of what goes on - and the fallout from this is, code changes happen - after beta testing is finished, features are slapped in without code review. Testing suffers - if you do a complete regression pass prior to actually shipping.
Then you end up either shipping late (which most companies do anyway) - or shipping on time, and in both cases, you end up with a buttload of field issues that didn't appear in your abbreviated beta testing, or in your QA lab.
Buggy software makes for poor sales (unless there's no competition). In addition, 9 times out of 10, the feature that the sales guy asked for gets in, but it doesn't work the way he imagined it worked, so this absolute drop-dead feature he needed to make that $10million deal isn't what the customer wanted, and so that sale falls through.
I've seen this happen again and again. When you throw out careful engineering practices, and let the marketing and sales guys design a product that should be designed by engineers - the end result is - just what you'd expect.
Sure - you MUST give a product a certain feature set in order to have market appeal. You MUST make target dates in order to synch with the marketing strategy.
But these non-engineering influences need to adopt some better practices.
1) Do REAL market research. Study the feasibility, keep engineering in the loop from day one.
2) Make REAL detailed descriptions of new, requested features. (including "performance enhancements") Figure out what problem the customer is trying to solve with this feature, and why. See if alternate approaches can solve the same problem more elegantly. (this is how GREAT software is written, as opposed to the hobbled-together crap that's being sold by most companies today).
3) Write the engineering spec for the product IN STONE - set a date. From this point on, unless there is a technical problem - NOTHING about this product changes. Any new features have to go into the next version. Sorry charly. That last great whizbang idea missed the boat. Trying to get engineering to put it into your product at the last minute to save your ass in that ONE big deal that's going to get you that christmas bonus.
4) provide adequate time for testing. I can't stress this enough. If you're hitting problems in the field due to diverse customer environments, then expand your beta testing.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Aye. Joel attributes sees the impulse to rewrite as a result of programmers' laziness about supporting existing systems. But I think many programmers who were present at the original creation of software recall the compromises and mistakes that came as a result of deadline pressure. Many suits say "we have to make deadline; we can clean that stuff up later." We all know that organizations rarely have the discipline to actually do that, and Joel makes it clear that it's not such a good thing even when they do.
Foxpro was not a rewrite of DBase, but a different product. It was a longtime competitor to DBase, and was itself an update from Foxbase. It was an excellent product -- outstanding performance, efficient memory usage, modern WIMP environment in text mode, event-driven programming -- even if not completely compatible with its DBase competitor. To their credit, Microsoft did not mandate a rewrite of Foxpro: the Dos product continued to evolve, and the Windows product was already in development before Fox Software got purchased. So, no: MS did not rewrite Foxpro, but paid $$ for the privilege of using existing code to compete.
It goes beyond making the job unpleasant - the same cluelessness means that products don't get the innovations they need, and the entire business direction is defined by "don't go there, that's hard". Then they pack the ranks with VP's of this or that, and they might as well bury the engineers and forget about them. I call it the compost pile model - they keep adding fresh layers on the top, hoping something useful will form at the bottom.
:-)
My last employer was (at one point) an internet search engine, but in the three years that I was there, they made absolutely no technological improvements to the search code (I know, I read it), but they doubled the layers of management, made hundreds of changes of priorities, etc. Then they decided that search was unprofitable, so they formed a bunch of distribution partnerships with other portals - except Google. Now Google is eating up the market and everyone else is chapter 11. So what do they do? They lay off all their R and D people
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
Hi,
:-
I'm astounded at most of the arguments made here. Let's talk REALITY for a second - not just "politically correct" answers...
Fallacy #1
==========
"We write over 1000 lines of code for a function - so we need to comment our code" - Please tell me the name of the company you work for - because you obviously have NO idea how to write code. I'll avoid your company like the plage. You also obviously don't understand that a function should encapsulate a single concept - and in my 15 years of commercial software development i've *NEVER* required a 1000 line function.
Fallacy #2
==========
"I left the comment in there so some sucker won't make the same mistake". Have you EVER heard of version control, configuration management, baselines etc.? Can't afford it? (yeah right) - try TkCVS or WinCVS. It's not perfect but it will do all you need for free. It allows you to "compare versions" and "write comments of what was fixed and why" - and more importantly, control change (mind you, you can't rely on the tool alone. You must have a thing called process...)
Fallacy #3
==========
"Don't design your code, just write it". Sort of goes along the lines of "well, things change - so you only document after the project is finished". Rubbish. Often commercial products have a thing called a "requirement specification" (Microsoft don't need one - they have a monopoloy. Therefore, they 'dictate'). A "requirement specification" says "you SHALL" and "you WILL". If something is not designed properly it will not work. If you want to know "what something does" or "why it was done that way", you read the "design" (NOTE: design is not a copy of comments in the code).
Fallacy #4
==========
"Code should have lots of comments through it". Someone else here summed this up beautifully... If your code is encapsulated correctly (basically, functions associated logically), written consistently with meaningful names then code will be much easier to read and maintain.
You ONLY comment code where the code is complex or non-obvious from the design. If you need to understand why, read your design or the requirements (or maybe even a statement of work).
From what i've seen here - MOST responses clearly indicate a clear lack of experience in software development.
Oh yes, in response to the "blatant propaganda re: hungarian notation" - there are big problems with hungarian notation - but your examples were weak. Let me (slightly) exaggerate what you wrote
Unix C (???)
============
char message[1024]
Hungarian notation
==================
char strSomeBytes[1024]
hahaha... you make me laugh. If you "really" knew about hungarian notation, you would have pointed out more obvious flaws, like "how do you name variable based on a class - when typically, people deal with many different class types"???
How to be not a moron according to Alex Belits:
1) Believe that anyone opposing Microsoft is good.
2) Put up with lies that meet your ends.
3) Insult anyone who disagrees with your stance.
4) Look the gifthorses in their mouths.
Don't you have some carbombs to set off down at MS HQ?
I'm glad someone commented on this, I was reading the artical and had the same thought. I'm not sure were he got his version but at my school it was 80 percent of your income comes from 20% of your customers.
It's actually an interesting concept because it allows a buisness to address issues like the choice to continue to stop a product line, and if this is going to save money, or rob the company of it's best income source, it is also used when making other strategic buisness decisions.
That java will die guy was pretty free of any technical content.
This has been an issue that has puzzled me for the longest time: if your company has a program that runs on -- say -- DOS 5.0, & you can't afford to pay someone to port it to Win98/Win2000/Linux/BSD/whatever, why not leave the aging 486 running this ancient program alone?
Either you have an idiot in charge of IT who wants every computer at the same iteration of hardware & OS for ``simplicity" reasons, or you have a bunch of lazy users who don't want to leave their cube to walk over to the old computer to run this legacy application, then move the data to a shared directory from whence they can work on it at their cube.
And if a case can be made that it has to run on several current-generation computers, then it's justification to be rewritten & migrated to the office standard.
Something just doesn't compute here. Unless this is MS's way of hiding the fact they have to leave a butt-load of legacy function calls because no one in Redmond is sure they aren't being called in some dusty corner of Word or Excell that no one still working there understands.
Geoff
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
I couldn't even make it through all of these posts. Lost somewhere down the thread about the Cringley article.
The Microsoft issue seems pretty divisive. On one hand, you have the people who think that they are the evil incarnate and a relentless death machine for anybody who stands in the way of "where they want to go today." On the other, you have the market-types who see them as an Adam Smith wet dream. Either side seems pretty fatalistic to me.
We need more optimism here. I'd guess that a good amount of the readership on this site are programmers, as well as open source enthusiasts. Lets start using this for something!
Monopolies do not last forever, a fact that has been well established over the years. The fact is, nobody has tried to strike Microsoft at their heart: the consumer. I mean this quite literally. Many have flitted around the edges, talked about technical superiority, showed this great new feature, and then stood dumbfounded as MS came and ate up their market share.
While the anti-trust settlement struck many of us (myself included) as a little lenient, it did open up several new points of attack for those of us looking to take the fight to MS' home turf. 1) they can't discriminate in pricing based on how they feel their OEMs are treating them. 2) they cannat control every aspect of what goes where on the desktop. 3) they have to open up some of the APIs they use to integrate their apps.
Between us, I propose we go on a lowest-common-denominator programming binge for Windows. Write plug-in replacements for MS products on the MS Platform. Lets start with the databases, mail servers, web servers, and other "enterprise" packages which use commoditized protocols. While many of these are available in several forms, this new court mandated "openess" and OEM freedom could be just the ticket we need to push our things into the mainstream. The marketing will come if the software gets there. Quite frankly, I believe that open-source has failed in the marketplace because companies have come to the realization too late that they cannot dictate to customers the terms of sale. ("sure you can use our database package, but you need to run linux. No, it doesn't have such-and-such extensions") As bad as NT and Win2k are (and I'm not even talking about XP) the fact is people buy them and will keep on buying them. Are we going to forsake all those poor lemmings to using exchange and SQL server when we have sendmail and postgresql just sitting around? NO!! If our community can get the software together, there are plenty of players out there to push it for us. IBM would be glad to try to talk people into using open-source packages when a customer chooses NT; it gives them a clear migration path to their AIX and linux servers. WE JUST NEED TO MAKE THE SOFTWARE A PLUG-IN REPLACEMENT! Its not about who's technology is cooler, its about simplicity and convenience, and giving people solutions that fit with what they know.
I just hope we learn this before IBM, Sun and Oracle aren't around to help us out anymore.
I have programmed for TOPS-10, OS-360, RT-11, DOS, and Windows 32, but not my VCR. If you have too many features, it becomes hard to do simple things.
I read the article a while back, and for the most part agree. The aphorism "Perfect is the enemy of good enough" expresses the fundamental idea pretty well, I think.
I've worked with many programmers who were more focused on a theoretical, ivory-tower sort of idea of what software "should be", and forget that the object of the game is to DELIVER software that is USEFUL or HELPFUL, but not necessarily PERFECT.
They can never seem to complete a task, because there is always something more to do. In many cases, the programmers take it upon themselves to redefine the requirements to make their job more interesting. This does not necessarily accomplish what the business needs.
In many cases, programmers "gild the lily" because it is something they want to do, not because it contributes to the above goals.
In my own case, a client once hired me to rewrite a trading application for NT which had been implemented on Unix. At first glance, it did look like "spaghetti code", but after spending a couple of weeks understanding it, I convinced them that a rewrite was not needed. I managed to port the code without a whole lot of trouble, and this ended up saving the client at least six months in time to market.
Sadly, many programmers (esp. consultants) do the opposite -- they encourage their clients to throw away code which is OK, because it lines their pockets. What is missed here is that once the new code has made it through QA, system testing and user acceptance, it may not be all that pretty anymore either.
A lot of this has to do with self-marketing. The marketing department has lots of talented marketing minds who are quite capable of convincing folks of their importance to the company.
The IT department, on the other hand, is made up of (hopefully) intelligent computer programmers. If the IT department could hire one or two of those marketing guys to get the message out within the company of what IT does for that company and what it needs to do that job better, they just might be able to swing the higher salaries, catered lunches, etc.
IT needs to be more aggressive. They need to show the C?Os and others how the company will save money and/or be more profitable with better hardware and dedicated staff.
Coding Blog
For it is you who require a clue by four.
The file you mention is used by the OS/2 subsystem. You won't see those error messages unless you run an OS/2 program under NT.
Of course, its always easier to ignore history. Yes, there's a OS/2 subsystem. If you go do a strings on the NT 3.51 DLLs - and even some 4.0 ones , you'll find IBM's OS/2 copyrights. (Novell made a big deal out of that at one point in sales presentations, and I think the next service pack replaced those that had been pointed out).
Because NT and OS/2, at one point, were the same project. It seperated for a number of reasons, but primarily because Microsoft had the "damn the customers, make 'em buy new hardware". THe OS/2 layer is part of the seperation agreements, and it was disabled/junked as soon as possible (as well as not well done, on purpose).
But your disbelief of history doesn't in the slightest change it.
Addison
It can be done - I think - IF the boss realises the technical stuff is important, and listens to the techies.
My last boss didn't - she* seemed to assume that the business side was the only important thing, and that the techie stuff `just happened'. Okay, that's how it should appear to the higher-ups, but she was an IT project manager!
(* Before I get flamed, I'm not suggesting that her sex had anything to do with it. I don't think I've had any male bosses with quite this problem, but that's just the luck of the draw. And they had other problems instead!)
When she told me my contract was being ended early, she asked me about what I'd been doing over the last six months, and I think a lot of it came as a surprise to her...
Mind you, my worst gripe is with managers who ask you for an estimate for something you've never done, and expect the times to be accurate to within 5%. After they've talked you through it in detail halving all your times, of course... [fx: scream]
And don't underestimate programmer time. It's hard to quantify the time you'll save in future by having a neat, concise system instead of a mass of gunk, but just coz it won't fit into a neat box in a business case doesn't mean it's not worth doing.
Some of the best bits of redesign have been done in people's spare time... Programmers often know the most efficient way to work even if the higher-ups don't.
Ceterum censeo subscriptionem esse delendam.
You raise an excellent point.
I have a theory; it's only a theory, mind.
I think the reason why M$ produces IE5 for the Mac (which I think is a better browser than Windows IE5 or 5.5; haven't used IE6 yet) is because of tradition.
M$ historically has had a fairly strong presence in the Mac market; for a long time, for example, MS Word was mainly a Mac product. (At the time, Serious PC Owners used WordPerfect exclusively for word processing.) Many Mac users have a generally positive attitude towards M$.
Even Mac users like me (an admitted /. reader :) have something of a fondness for some M$ programs, especially MS Office (I own Office 2001).
I think they're doing it to keep Macheads happy, and thus to keep sales of Office fairly brisk.
my old sig used to be funny, but then slashcode ate it and now it's not funny anymore
While you may be able to tell yourself that you don't have any obligation to support Win95, you're going to lose more customers (likely) by not supporting it than you would by supporting the Chinese language.
Now, if you were writing an app with a lot of Chinese appeal this might not be the case.
Or, if your app likely wouldn't work on old computers. (Doom 3, etc).
In business, it's not necessary to tell yourself that you will be losing customers by not supporting Win95. In fact, making the decision NOT to support Win95 will save you money in the long run, because you are not dealing with the support issues dredged up by these anachronistic idiots and the ridiculous incompatibilities of old ass Winblows operating systems. Meaning, you don't have to develop with an eye to how your code will work (or not work) on Win95, because you have made it a policy to ridicule the dumbasses that still run it.
Comments should explain WHY, not HOW.
...
// first I try and connect to the server
// then if I can't connect, I ping to check if the server is up
// if the server is down, I write an error log and get out of here
// otherwise .... etc etc
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.
If you weren't so emphatic about that, I probably wouldn't take exception, because I agree with you to certain extent, however
It is rare that you will need to explain 'WHY' you did something, because these cases are exceptions rather than the rule. Most of the time in programming, you are doing fairly straightforward stuff.
Even the unusual, innovative or 'cutting-edge' stuff is usually supported by lots of vanilla functions, that interact with the OS in the usual ways.
So I believe that you should also comment the 'WHAT' of a function/method in plain english for one very simple reason. Those with able minds pick up and start coding on projects much faster when they have an 'overview' of how the pieces fit together.
And sure, documentation is usefull, but when I am looking at one function, that calls many other functions that work fine, I very quickly pick up the project and start coding when the code has been commented in the following manner.
[some code]
[some code]
[some code]
Sure there is some redundancy there, but believe me, the next guy who takes up your project regardless of his level of skill will thank-you from the bottom of his heart when he can concentrate on doing what needs to be done, rather than going through every freeking line of every freeking function, like some anal-retentive accountant, just to find out what the programme is trying to do.
TR
There are several ways to encode a given glyph, for example eacute, as in "cafe". This can be encoded either as the latin-1 compatible eacute character, or more properly as the character e followed by the non-spacing combining diacritic acute symbol. Also, Angstrom has three encodings IIRC, 'A' with 'o' above, 'Angstrom' symbol and 'A' followed by a combining 'o'.
After wading through everything that's been posted, I think that's the conclusion -- it doesn't matter how good your code is beyond a certain point. It just has to be 'pretty good', because that's where most consumers will make the buy decision.
Argue the point all you want, but the people buying stuff don't really give a damn about all this software engineering stuff. They just want something that will write letters and balance the books and help distract them a little from their lives, and they don't care if it's particularly efficient or fast, or uses a cute new optimizing algorithm, just as long as it gets the job done. There are exceptions, but not enough to make a real difference.
That's how Microsoft succeeded -- not by engineering, but by business practices. Whether that's moral or not is left as an exercise to the reader. The level of success can be explained by the billions of dollars that Bill Gates has. To challenge this, you must either a) be better than Microsoft in business, or b) you must educate the public that 'Pretty Good' isn't good enough.
To quote Charles Osgood from 'Pretty Good':
...
There once was a pretty good nation,
Pretty proud of the greatness it had,
But which learned much too late,
If you want to be great,
Pretty good is, in fact, pretty bad.
"The competent programmer...approaches the programming task in full humility. -- Edsger Dijkstra
"I've seen plenty of companies with prima donna programmers who literally drive their companies into the ground. If the management of the company is technical (think Bill Gates), management isn't afraid to argue with them and win -- or fire the programmer and get someone new in."
<snip>
... because Most Upper Management believe they are technical, so now you give them great ammunition to get rid of you if you try to bring along some "yesman" lacky who will continue to maintain your companies brutal Hack of code which was written by some High School Student...
Let's get serious, in any Client Server environment You can try putting a rocket on rollerskates, but if stuf was written bad from the beginning, it wont scale, and youll be paying the price tracking down memory leaks and badness... Stop the madness! Yeah it might function if 5 or 10 people use it, but when you need stuff which works for 100's, good luck maintaining that nightmare!
I agree sometimes programmers go overboard with "ReArchitect" ideas, but, I still maintain the problem is Managers who force programmers to spend 90% of thier time on functionality used 10% of the time... While the entire project suffers
"They think they have a good union but they don't, they're practically slaves."
I guess you didn't actually read the rest of Joel's comment. He's interesting in writing commercially successful software. Lots of people still use Win95.
Who the #@%#@ has been moderating this discussion? People from Microsoft???
/. is keeping stats of the number of moderators from microsoft.com that are biasing this discussion.
I started reading this discussion the day it was posted, and the moderation was pretty good. When I checked back today, I found that a bunch of good comments were now rated 3, and were listed as Troll, Flamebait, Redundant, and even Off-topic.
WTF!?
I hope
Would you care to revise that statement in in light of the later slashdot article
Win95 Lifecycle Draws to a Close" - Microsoft has picked November 30th, 2001 as the date that Win95 moves into the unsupported phase of it's career
I may not have communicated my intent clearly. The examples of comments you gave *are* the sorts of comments I like to see. They summarize at a level much more vague than the code. They explain why you wrote the code, not what it is doing in a detailed fashion. ("I wrote these next few lines in order to make it do foo.")
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
However, I have to take issue with your position that rewriting code is bad because it throws out all the bug fixes that past programmers spent time and effort finding and fixing. I suggest reading an article in IEEE Transactions on Software Engineering 1/2001 issue. "Does Code Decay?" I would like to post a URL to that article .. but unfortunately it requires payment.
Eick, et al's conclusion was that indeed code does decay. Their definition of decay was "A unit of code is decayed if it is harder to change than it should be, measured in terms of effort, interval, and quality." (italics theirs) The source of their data was the entire change history of a 15-year old real-time software system for telephone switches with over 100 million lines of code. What they did is measure the number of files that a single change had to modify. What Eick found was that once the initial development flurry of activity died off the probability of a change needing to result in modifying more than one file was less than 2%. Within five years the probability had increased to greater than 5%. It is Eick's contention that this is a sign of code decay because the number of "simple" changes was dropping and the number of complex, involved changes was increasing.
Furthermore, they found that modules began to exert "gravitional" effects on nearby modules. This resulted in blending and stronger and stronger coupling of the modules.
They listed a number of causes of decay:
- Inappropriate Architecture
- Violations of the original design principles (The program is required to do something that was not anticipated at design time)
- Imprecise requirements
- Time pressure
- Inadequate programming tools
- Organizational Environment (low morale, high turnover, poor inter-developer communication)
- Programmer variability (some code that should only be touched by experts is mucked up by novices.)
- Inadeqate change process
Bad management of course will magnify the issue.To that list I would also add that as the field matures we learn better and better techniques. A very good example of this was the seachange that I saw when the use of exceptions were first introduced. I remember all the effort of trying to communicate an low-level error condition up to the calling chain. Error codes return values -- what a nightmare! Once I saw exceptions and understood them -- It made the quality of my code much, much better.
So to Eick's list I would add general advances in the field result in the realization that what was previously considered "best" practice is no longer the case. This happens in every scientific field and computer coding is no different.
Uh, ASCII is 7-bit.
But WinME and Win98 don't support UNICODE either. Only NT/2000/XP support UNICODE.
Part II of the Interview with Joel Spolsky is now up for your perusal.