Slashdot Mirror
How To Make Software Projects Fail
Bob Abooey writes: "SoftwareMarketSolution has an interesting interview of Joel Spolsky, of Joel on Software fame. Joel, a former programmer at Microsoft, discusses some of the reasons he thinks some very popular software companies or projects fail, including Netscape, Lotus 123, Borland, etc." This interview brings out some mild boiler-room stories which sound like they could be the basis of a good book, along the lines of Soul of a New Machine .
Alot of .com's I've worked at in the past 2-3 years always wanted to "lowball" developers and engineers, while lining the pockets of resource managers, implementation managers, marketing people, etc.
/. - so I'll probably take a big hit on the karma - but I just was the casualty of another dotcom failure - and this was a seriousl problem.
Then a skilled/talented developer and/or engineer wants more money. The employer does nothing to retain them - thus the skilled/talented employee leaves.
Now who maintains the code?
The other problem is bringing in short term consultants for long term projects. The non-technical people who make these executive decisions don't seem to see the feasability of KEEPING their code maintained by the talented/skilled person who BEGAN the development on it.
I know alot of consultants read
Another problem is hiring non-technical managers to manage technical people. At my last job we had a manager off of an automobile manufacturing production line quit his job at the auto company to take a job as the manager of a group of Unix admins. This "bumper jockey" had NO CLUE what we did for a living, and treated us like a bunch of unionized UAW slobs, and not like professionals.
How can a non-technical boss effectively manage technical people???
Also - how about all the Ceo, Cio, Cto, eieio - types with their big salaries, catered lunches, etc... Alot of them have NO programming or hands-on technical experience. Hell - I've had the CTO come up to me and tell me that "The Internet was broken" when he knocked the dongle out of the side of his laptop - severing the network connection. And this guy is our Chief Technology Officer???? *lmao*
I'm not saying that only technological people can make technology companies work - but I do feel that managers should take some sort of hands-on classes to learn some basic programming and internet skills so they have SOME SORT OF CLUE about what WE all do for a living!
[Connection closed by foreign host]
Obviously, MS biggest problem though is that they don't know when to give up and actually rewrite. For instance, it seems that the windows series of operating systems are all made with the intent of being backwards compatible and reusing core parts back to early DOS systems. Backwards compatability and code reuse is nice and all, but there is a limit to it and a time to give up.
It will however be interesting to see what comes out of the "total rewrite" of IIS.
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
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"
From the interview's lead-in material:
At Microsoft, the job title of Program Manager is given to the people that design the software. They dream it up, write the specs, hold countless meetings, and basically lay the path for the developers to follow. The developers (Software Design Engineer) are tasked with actually programming that software (and thus would be considered "programmers"). Just to round out the roster, the Software Design Engineers in Test (SDET) write the testing suites used by the test teams, and the Software Test Engineers apply those suites to the code following a test plan that they create. In that heirarchy, only the SDE and SDET jobs could be accurately described as "programmers".
Note that this is actually not so cut and dried, wherein SDEs often do design work and test work, and SDETs often do the work of SDTs. PMs don't program, however (well, aside from javascript&html prototypes, anyway).
The point? Calling this Joel an ex-Microsoft programmer is misleading, because he was not. However, the position he held at Microsoft actually lends more credence to his views on design than if he were actually an ex-programmer, as part of the job description of a program manager is doing software design.
(Brief descriptions of all these job titles can be found at Microsoft's college site.)
However, I feel slimy for just reading that stuff. Here is what I got:
1. Bugs are fine if they get your product delivered.
2. Load in useless features to drive sales, knowing that your code will suck.
3. Once you have gobs of crap code and a large user base, there will never exist the possibility of re-designing things (eg, WinXP) since it doesn't matter that code sucks (see point 1) and all that counts is revenue.
4. Being efficient is a waste of time. Let the hardware catch up with the crap code.
5. The customer never has valid input anyway.
6. Do it fast and furious, even if January 1900 is broken. Consumers are idiots anyway.
These may be great for sales, but ultimately you will build crap. Garbage in, garbage out. I would rather design good software that was well designed and efficient than vomit up mounds of bloat that will ultimately topple under its own weight.
Software built poorly will never hold up over time. If you look at how little UNIX has had to change over the past 30 years to keep up with "The Internet Age" versus the amount of work done to get XP "working", the future looks bleak for Microsoft. In 20 years, their OS need 25GB of RAM simply to boot up. Of course, this seems not to concern them.
----- Refactoring is the reason why man does not mistake himself for a god.
Yes, there are a lot of companies who have been squashed (or, as Joel would say, "Had their lunch eaten") by Microsoft in large part because of Microsoft's money/marketing, but there are also a lot of companies that nose dived into failure because of their own ignorant business and technology decisions.
While Microsoft may not like the costs and annoyance of court cases and DOJ action, it must give them some satisfaction because most of those companies bringing suit against Microsoft are doing so because they think that's their best option. I would argue that for these plantiffs making better products would be a "better option."
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
From a purely intrinsic point of view, I agree with you StaticEngine. From a purely practical point of view, I couldn't disagree more.
Let me explain myself. I have been the type of programmer you speak of. I have written copiously commented code. I have properly formatted my code and used standardized function names and such. After all, I was taught in college to write and comment my code so that any programmer could walk in off the street and understand it easily; that made it easy to replace me and I was.
It seems that when you follow good programming practice, you end up destroying your job security; and as silly as it sounds... it appears to be sooth.
Jaded in a realistic world.
Codifex Maximus ~ In search of... a shorter sig.
What you're seeing there _is_ capitalism- it just happens to be 'laissez-faire'. Under current conditions, those guys are the only ones who survive, because they 'eat the lunch' of everybody else and make sure there's no choice to resort to, by hook or by crook. In strict laissez-faire as it's practiced in the modern world, there is no concept of 'society' at all. It's 100% Union Carbide and there is no such place as Bhopal...
Now, it's important to remember that there are OTHER types of capitalism, but to claim laissez-faire isn't capitalism seems a bit wrong. The trouble here is that you are aware of society and things like consequences to actions, perhaps you are aware of stuff like game theory that proves 'best doesn't always win' and you object to the rules of the game being virtually nonexistent, because you see what happens and you don't like it.
However, to do something about it you'll have to encourage a different sort of capitalism than the laissez-faire one we live with, and until then it will be about 'eating lunch' and to hell with society, customers, or even basic fitness to the task.
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.
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
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.