Slashdot Mirror
Joel On Software
The essays in this book are even-handed. While he focuses on Windows, Spolsky is not a fanatic believer in one approach over another; if C# works better than Visual Basic for a specific task, so be it. His approach is refreshing when so much is written by opinionated members of the "Microsoft is the source of all evil" camp.
Spolsky starts with down-to-earth topics, such as how to estimate the length of time programming tasks will require, and the ratio of QA people to developers needed for a healthy product. He then moves on to share his thoughts on managing developers and higher-level software-related issues.
One of the book's opening salvos, "the Joel Test for Better Code," is a simple "irresponsible" test that Spolsky created to provide insight into how well a development organization is functioning. The test looks for things like using source-code control, and having testers create daily builds with a single click of a button. As someone who has worked companies that would have failed the "Joel Test" miserably, I can attest to the importance of these criteria.
The chapter on Unicode is a short and to-the-point overview on the topic and should be required reading for any software developer and product manager who wants an introduction to Unicode.
Clean and bug-free code is a common thread in several essays in the first part of the book. Spolsky explains the inappropriateness of developers performing QA and stresses the need to "eat your own dog food." Having developers conduct testing is a waste of resources and upsets them just the same; forcing developers to use their own product will motivate them to create a better one.
In "Fire and Motion," Spolsky takes issue with the "architect astronauts" who generate vague technology announcements that are often counterproductive by creating fear, uncertainty and doubt. While these announcements may drive competitors to waste cycles in converting their code base to the latest technology, they offer no real substance. Misguided companies, mesmerized by the promise of new technologies or by demands from numskull customers, can sap years of developer time when product improvement should have taken precedence.
In "Biculturalism," Spolsky dispassionately discusses the differences in world view between Windows and UNIX programmers. Spolsky probably rankled some UNIX fans, but I share his perspective. Spolsky points out that UNIX developers are just as smart as Windows developers, but when it comes to understanding their end users and having empathy for customers, they tend to fall short.
The "Gorilla Guide to Interviewing" is relevant to all hiring managers. Spolsky describes some of the traits of his ideal hires. Those who, in one sentence, are both smart and "get things done." Spolsky believes in hiring people that can perform multiple roles. Spolsky believes in making a "sharp" decision about the candidate, and finds insulting that a hiring manager would not find the interviewee good enough for his own team but would refer him to another team. Spolsky shares one of his hiring secrets: never hire a "maybe." This might seem obvious, but he details why it's better to reject a good candidate than to hire a bad one. Firing can cost a lot of money, time and effort. Additionally, Spolsky suggests questions to ask during an interview and the necessary "what not to ask."
The "Iceberg Secret Revealed" discusses the manner in which customers express their pain, and points out that customers often don't really know what they want. It is the product manager's job to find a solution that will solve their customer's pain while keeping an eye on the market she is addressing. Just listening to customers without proper filters, is as Spolsky points out, a recipe for disaster. And the Iceberg Secret? Spolsky illustrates in five different ways how customers and stakeholders only look at the tip of the iceberg, and not at the substance beneath it.
In one of the shorter chapters, a missive on measurement, Spolsky addresses the prickly issue of measuring performance in companies. In addition to his own insights on measuring performance, he recommends Measuring and Managing Performance in Organizations by Robert Austin. I will add that to my reading list.
Spolsky wrote an introduction to In Search of Stupidity . He offers there the "geek's" perspective on what it takes to make a successful software company, taking as a starting point the ten largest software companies in 1984 and the equivalent list of 2001. His conclusion is that "no software company can succeed unless a programmer is at the helm." With his usual even handedness, he is quick to point out some of the debacles programmers are responsible for. In the example he gives, Netscape's disastrous rewriting of their code base and almost complete loss of market share while they were doing it. His bottom line? To succeed, a company needs a management team that love and thoroughly understand programming and understand and love business. Not as easy as it sounds.
In his five "Strategy Letters," Spolsky writes about issues that are relevant to anyone making strategic business decisions in the software industry. He starts with company growth modes by comparing Ben & Jerry's to Amazon. He then discusses the classic "Chicken and the Egg" problem when building new platforms. His example is still relevant -- few will develop .NET-based clients until a large number of end users have the .NET engine installed on their PCs and end users will not install it until there are enough applications that require it. Spolsky moves on to discuss backward compatibility, open source economics and the myth of bloatware.
Spolsky points out that despite the growing size of applications, the cost of disk space has plummeted even faster. This may be true, but Spolsky does not address the programs' resulting sluggishness despite more and more processing power. Spolsky wraps up the essay by dismissing the notion of coming out with a "lite" version for a given software product. I agree that lite versions do not always satisfy everyone, but they can be a great way to keep out low-end competitors from entering the market in addition to a way to introduce customers to the high-end product.
The chapter about Microsoft losing the API war is a classic. Spolsky starts with the seemingly outlandish assertion that Microsoft lost the API war. After apologizing for his "grandiloquence and pomposity," he goes on to build a convincing case that if Microsoft has in fact not lost the war, they are definitely in danger of doing so. He starts with the diminishing interest in the Windows API as a development platform. He then describes how two camps inside Microsoft (the "Raymond Chen" and the "MSDN Magazine" groups) are influencing Microsoft's approach to their developers' tools. The former group emphasizes creating a backward-compatible operating system, free of bugs and impervious to third-party applications' errors that can harm it. On the other hand is the MSDN group, promoting the latest and greatest Microsoft has to offer. As Spolsky sees it, the latter group has the upper hand, and because of this, Microsoft is losing their developer base to simpler, more easily deployed platforms.
In part 4 of the book, Spolsky takes on Microsoft's .NET strategy. He describes Microsoft's tendency to create FUD in the marketplace with vague, hollow statements, and details his own company's reasons for not adopting .NET anytime soon. Spolsky wraps up with a very straightforward feature request: a linker for .NET. This would seem to be an obvious feature, but Microsoft so far doesn't agree. Microsoft is acting as though they want to win the development platform war in a single sweep. At the same time, independent software vendors (ISVs) are resisting, because they have to guarantee backward compatibility and support for everything their customers run.
My only complaint about the book is that it's too short. On my bookshelf, it resides next to the Mythical Man Month, another favorite.
Spolsky is knowledgeable, funny and free of unnecessary religious fervor. Joel on Software is a must-read for developers, product managers and those who want more insight into the world of developing software.
Daniel Shefer is a Software Product Management professional and has written numerous articles on this topic. You can purchase Joel on Software from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
shut your Hoel, Joel
Noone knows who this guy is, and noone cares what he thinks.
Running a weblog and some rinky-dink "software" company doesn't make you an industry expert!
Comment removed based on user account deletion
-1 flamebait, but all Joel ever talks about is what a smart guy he is and how everyone else is an idiot and all companies, except fog creek, suck.
A long time ago I decided that Joel on Software would be non-political. In programming terms, politics are orthogonal to software
Not quite so. If you vote for the wrong guys, you software-making activities might stand a greater chance of moving overseas, and then the two issues won't be orthogonal anymore.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Joel is assembling a volume of "the best software essays" of 2004 and is taking reader nominations. Suggest something if you have a favorite, or just click through and read everyone else's picks.
What I'm listening to now on Pandora...
The entire book is available on the Web for free, since the book is basically the collection of Joel's best articles. He cleaned them up, according to the introduction, but anyone willing to "look inside the book" (tm) before getting it, has a chance to go through 100% of it.
In this context amateurs also include long-time tech professionals who don't know a thing about management or leadership and therefore are extremely impressed by some of the basic management stuff he is able to regurgitate.
I keep forgetting.
"M$"...
"Behemoth of a corporation"...
You're such a slashbot...
*Sigh*
It is Google's #1 hit for programming tricks.
I have quite a wide range of interests, so the articles aren't really just about programming anymore.
Request your free CD of my piano music.
For those that don't know the background to the story, Joel published a "How Microsoft Lost the API War" essay on his blog which stirred up enough developers at Microsoft that the company decided it would backport their new windowing and rendering system ("Avalon") and their new networking and messanging system ("Indigo") to previous versions of Windows, including XP. Before this essay, the said technologies had been designed for Windows Longhorn only.
.NET falls on listening ears in Redmond, time will tell.
Point being that Joel has a lot of influence and a lot of respect among the Microsoft folks. I also hope his suggestion of a linker for
Tech, life, family, faith: Give me a visit
Joel is definitely no PHB (pointy haired boss). You will think that many of his insights are just plain common sense and that is correct. The problem is that too many times management will not use common sense and they need someone like Joel to point it out to them.
I'm Joel's collections made it into dead tree form as that will lend them some more credibility. Good reading.
Does any of you guys know of something like http://www.fogcreek.com/CityDesk/ for linux?
Attention mods, this "post" is just an excuse to get people to click on the Amazon referral link. MOD SPAMMER DOWN please.
Gotta love this:
Joel on Software is a collection of essays from the Joel Spolsky's Joel on Software web log.
Your mistake is that you don't realize that's a compliment. Anyone with a 30% usefulness rate is worth reading. (As long as you have a brain, you don't need to believe the other 70%, right?)
Yeah, you gotta watch those guys, I much prefer the unopinionated members of the "Microsoft is the source of all evil" camp - they write much better stuff.
After two minutes of poking around his web site I found this gem:
But for almost any kind of real business, you just have to know how long things are going to take, because developing a product costs money. You wouldn't buy a pair of jeans without knowing what the price is, so how can a responsible business decide whether to build a product without knowing how long it will take and, therefore, how much it will cost?
Of course, the time it takes to develop a specification so detailed that "the business" can decide how long it will take and, therefore, how much it will cost is three time the amount of time you'll ultimately spend "developing the product".
Proud neuron in the Slashdot hivemind since 2002.
"His approach is refreshing when so much is written by opinionated members of the 'Microsoft is the source of all evil' camp."
:)
I prefer to be called "honest" and not "opinionated".
--I smoked my sig.
Step 1. Post a referral link to slashdot. ...wait for it...
Step 2. Wait for idiots techies who SHOULD KNOW BETTER to mod up your spam.
Step 3. Collect referral cheques from linked purchases and...
***PROFIT!***
Does the F in FP stand for FIFTH? wtf. you loser.
I do not pay much attention to Joel Spolsky because he seems to have a poor understanding of the most important trend in software today: the open source revolution (OSR). He rarely writes anything positive about OS (or, at least as of 18 months ago, he rarely did so), and his CMS software, CityDesk, is not open source software. Open source tends to improve more rapidly than proprietary software. If Joel understood that simple fact (and he does not), then he would release his software under an open source license. And he would move to Linux, abandoning M$ Windows.
Furthermore, Joel's "technical interview questions" are less than optimal. If you want to assess a prospective employee's intelligence, the first questions that you ask should be along these lines: "How long have you been using Linux or *BSD? How long have you been using Apache, Tomcat, Zope, mod_perl, PHP, gcc, etc.? What is the difference between TCP and UDP? What are the most salient differences between Linux distributions these days? Why do you use your particular distribution (of Linux, *BSD, etc.)? What do you know about package management?"
Why do people who have such a poor understanding of the OSR (e.g., Joel, Steve Jobs) attract such attention, nay, adoration, from Slashdor readers? I simply do not understand it.
A lawyer & digital forensics examiner. Also an expert on open source software (OSS).
"In fact there are lots of great reasons for bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner."
Interesting reasons. Bloat is still bad, no matter how much CPU you decide you can throw at it.
I guess that's why you're pimping it here on Slashdot, huh.
Sorry dude! I looked at your site and read through a few of the articles. I didn't find anything interesting to me. In contrast, nearly all of the articles by Joel have been interesting to me (I have read most of them more than once over the years).
Do not pass Go, do not collect $0.02.
Sorry you didn't find anything interesting, but I'll be writing several more articles in the coming year, so please bookmark it and check back from time to time.
Request your free CD of my piano music.
Hell I'm ever reading the chapters on writing specs. So you can tell it *must* be good then.
Hmm, when I went poking around I found this quote almost immediately..
....
'First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it."'
I don't think you are really justified to call the guy an idiot with your single, most likely very out of context, quote. Here is where I got this quote.
My review would be that it was a quick, enjoyable, and thought provoking read. I don't think you should necessarily live by what he says, but he makes some good points. I particularly appreciated his essay about how to write functional specifications, and after reading that online, I decided to go out and purchase his book.
.NET, seem quite dated.
The book doesn't flow too well, since it's a collection of loosely related (or sometimes not-at-all related) material. You also have to check the dates on each one, since some of the essays, particularly his early comments about
Overall, I'm happy I read it. If 30% of it has something useful or insightful, then it's a bargain.
"I have never let my schooling interfere with my education." - Mark Twain
It's pretty pathetic that you refer to Microsoft as M$ and then try to pimp your Amazon affiliate link in the same post.
I realize critical writing is difficult, but if you're going to advertise a book review, deliver one. Like most Slashdot "reviews", this review is actually a summary.
A review should provide critical thoughts on the strengths and weaknesses of the material under consideration. A book review is not just a regurgitation of its contents. It also also provides an evaluation of its merits, noting where it succeeds or fails in its purpose. And enables me to determine if its worth its while.
This "review" nicely summarized the contents of the book but largely failed to inform as to whether the reviews are well written, provide new ideas, or present old ideas in particularly valuable manner. Therefore, I cannot recommend reading this review. Instead, just read the book's table of contents.
ShoutingMan.com
+5 informative? Please. This is just another post by cloudkj to spam his Amazon affiliate links.
He has a history of this.
Quit modding this dickhead up.
In "Biculturalism," Spolsky dispassionately discusses the differences in world view between Windows and UNIX programmers. Spolsky probably rankled some UNIX fans, but I share his perspective. Spolsky points out that UNIX developers are just as smart as Windows developers, but when it comes to understanding their end users and having empathy for customers, they tend to fall short.
I should probably read the thing firsthand, but if this is an accurate summary then it is garbage. This "difference in "world view" between Windows and UNIX programmers is such an overly simplistic and stupid straw man argument.
Politics are orthogonal to software indeed, why don't you follow your own goddamn sentiment Joel.
Having worked a ton of jobs as an electrical, hardware, and software engineer I can tell you that this generalization makes absolutely no sense. In general, there is absoultely no macroscopic correlation between software usability and underlying operating system platform. Software development is such a complex process, and for anything other than some shitty little bug tracking tool, one that involves more than a few people. How these teams are managed (that ranges from methodology, to choosing the smart/professional people in the first place) has absolutely nothing to do with some UNIX/Windows dichotomy you're promulgating. There are of course the zealots, of which you are a Windows/Microsoft one, even if you don't realize it. This is from the fact that you draw this simplistic separation, no matter how charitable you are about the other side.
When you get out of the realm of the shrink wrap software market from Best Buy, you realize there is a huge multi billion dollar industry of software used for things like manufacturing and design, and no Joel, they're not all programmers tools.
For many segments of this market, the operating system used becomes a secondary issue to having an integrated or working system.
For a high profile example, there was the LAX shutdown due to the shitty designed Windows based ATC system. Apparently, according to you, at least the developers had empathy for the poor bastards flying to LAX when their shitty system didn't work. The fact of the matter is that this could and probably would have happened if the same team of idiots had chosen to use a UNIX system. It is not an issue of smartness or UNIX people people being as smart as Windows people.
Someone please persuade me that this review, the post and most of the comments are not written by people who personally know Joel of Joel and Joel Joel. Joel.
Joel.
Something like fifty articles, essays, rants and scrawls.
The author of DrunkenBlog says of Living with Schizoaffective Disorder " It's the kind of thing that reminds you of why the web is cool."
Request your free CD of my piano music.
Another book on programming interviews (from the interviewee's viewpoint) is Programming Interviews Exposed. Seems like a decent book for preparing for Microsoft-style interviews.
EricJavaScript is not Java, damn it!
Request your free CD of my piano music.
After reading this book, I actually decided Joel was much LESS clever than I initially thought. Most of his knowledge is directly from Microsoft, you might as well read a Microsoft training manual. Yet it's plainly obvious he fails, for a LONG time, to grasp .NET
.NET is and of course, he ends up moving Fog Creek software towards it. He seems short sighted in many regards. Remember the page where he wanted a linker for .NET? hehe.
Pages upon pages bitching about how stupid
My impression after reading the book is that he was a rich guy who went to good schools, was given opportunities and learning early (thousands of dolloars on computers when he was a kid and computers were quite rare), and basically recycles things he was spoon fed at Microsoft.
There's nuggets of goodness, but my opinion of Joel's knowledge and expertise actually went down after reading the whole book.
Bloat matters when you think about distribution.
There is a limit to the "bloat is good" principle. I have a reasonably fast cable modem connection at home, and don't really mind 10-20 MB downloads (assuming my cable connection is the bottleneck here). When things are getting bigger than that, it must be something I really want, up to something like 300 MB. Beyond that I just won't be bothered.
But there are still a lot of people over dialup. I definitely would not be touching anything beyond 20 MB over dialup. Also, if the download site is slahdotted or something to dialup speeds it means almost the same thing.
I hardly ever buy anything that I can't download and try from the web first (it's ok if they send me a CD/DVD backup in mail).
Then you have limited form factor devices where bloat really, really does matter. Show me a cool 20 MB app and I show you my PDA with 5 MB memory (yeah, it's getting kinda old).
Just about the only situation where you may be able to forget bloat is if you can get an OEM deal for your software. Or maybe not - after all, you probably want other distributions channels in addition to OEMs.
if C# works better than Visual Basic for a specific task, so be it.
I always see mention of "suitability for specific tasks" with respect to different programming languages, I've never seen anyone explain which languages are best for which tasks, much less why. If anyone can spill some wisdom, I'm all ears (er, eyes, I guess).
How applicable any given technology I believe to be generally related to the people involved far more than the technology.
From how familiar a group is with how to get the most out of a technology, to what ways the people in the group are most comfortable thinking and developing, you should always start with a group and use the technology that will worst best in concert with them - it may be a new technology, it may not, the important part is that you do not weigh down a group with unnecessary problems before they start.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If this is offtopic, then so is the parent. Stupid mods; you're not supposed to mod down just because you disagree with what's being said...
It's official. Most of you are morons.
He means, geeks run unix, ma/pa kettle run winders. That's a fact, Jack!
(Fingers, don't fail me now)
/.
Joel's sayings is common sense. The guy is a little bit overrated, because almost every good software engineer more or less knows these things.
I would have thought better of him if he could come up with a new software engineering methodology that makes development less-time consuming and error prone, and a programming language to back it up.
After all, he is considered to be one of the most experienced programmers, and he certainly has the publicity to be claimed one of the top programmers of the planet. If he can't come up with something fresh, who can?
I simply do not understand it.
Perhaps because you're so blinkered by your belief in the 'one true way'.
That's funny, because my girl toots my horn.
``Having developers conduct testing is a waste of resources and upsets them just the same; forcing developers to use their own product will motivate them to create a better one.''
Actually, that can be viewed as a contradiction. Forcing developers to use their own product is having them conduct testing. It's the only test that works; you don't just test what you think needs to be tested, you test what actually needs to be tested.
This is also why many open-source projects are so successful, and many others are miserable failures. The ones that succeed are invariably the ones that the developers write for themselves; the ones that fail the ones that they make for others. Most OSS UIs suck, because we don't need them to be better.
With commercial software, it's largely the other way around. The software is developed for Real Users, and therefore often has a good interface and a bad implementation. Now the ideal might just be commercial open-source software - like OS X: open source core, commercial UI. The core could use a lot more hacking, though.
Please correct me if I got my facts wrong.
He's clearly talking about distributing end user software (Juno) to end users, and then getting crash reports back. He just looked in the function at the top of the stack (maybe that's the only function he had access to in the crash log) and assumed that C++ can't have NULL references, so this must be a problem with the user's machine.
He says,
"When you have a million users, it is amazing what will crash, often because of severe low memory conditions or severely crappy computers," and his solution for the problem is, "you will find crashes in places like that and you won't believe your eyes. (And you won't fix them. Cosmic rays, man. Get a new computer and this time don't install every cool shareware taskbar lint gizmo you find. Sheesh.)"
No-where in the article does he blame this problem on another programmer. In fact his entire point is that no programming error can cause this problem. He says it's completely impossible, and blames it on the user's computer and says they should get a new one.
He is perhaps right about it being related to computers with little memory, in which case a call to malloc() or new [1] might have returned NULL, and then he's dereferencing and passing to this function, however a well-behaved program should check for this kind of thing, of course.
Prematurely blaming a crash on the environment the program is running on is generally a pretty clear sign of an inexperienced programmer....
[1] new can't return NULL in Standard C++, but he was probably using MSVC++ = 6, and that does.
And he is correct. The top people at the most successful companies have moved up through the ranks or have a background in what the company does/makes. I saw one report that like 60 percent (was it more?) of the fortune 500 companies have this trait, and of the remaining ones, half drop out of the top 500 soon after they get in.
It's true that there are aspects of running a company that are independant of what it does or what industry it's in. They really make that point in business school. The problem is there are aspects to running any business that they just don't teach in business school. You'll find lots of engineers, chemists (see Exxon), etc who get real world experience and then pick up an MBA and move up the food chain. I've never heard of an MBA going back for a technical degree, have you? And which one do you suppose is more valuable?
If your company suddenly brings in a bunch of xEOs from an unrelated industry, it's time to find new cheese.
That's a business issue. Business decisions can be affected by politics, but business can be affected by a lot of factors, e.g. money, capital, revenue, profit, etc. (hint, hint)
I want to drag this out as long as possible. Bring me my protractor.
The most important trend in software is translation of implementation independent models into implementation dependent code. The OSR only exists because software development has been of such poor quality for so long. Face it, if the software does what it's supposed to do, nobody would ever care about the code being open source. Free software is a bird of a different color. Kind of like free anything. ;-)
Joel is the biggest stuffed shirt that I know of in popular media. And he's not even that popular, outside of us in the type-for-a living crowd.
He embodies an impractical and obtuse attitude towards software development that has made me walk out on or simply refuse a few job interviews.
Anytime some dipstick wants me to estimate the number of piano movers required in lower Manhattan, I want to tell them to stop snorting the crack that Joel is handing them. Or whatever people do with crack.
His 'articles' aren't much more than his well-meaning, but useless "folksy" opinions on subjects that are either common sense (and therefore unneccesary), or him simply being contrary (and therefore unusable) to drum up blog links, and therefore sell more of his weak foggy-bottom bug-tracking-with-salsa-and-cheese or whatever. Which, of course, is designed with and intended to support the very same impractical methodologies that he espouses on a regular basis.
Joel is essentially the homeopathy of the software world - not really dangerous, but useless, time wasting, and a proponent of expensive false hope for those too clueless to actually use critical thinking in thier lives.