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.
Uh, no shit, and if North Korea nukes his office that might affect his coding, also. Obviously he's talking about the code itself, which cares nothing about the guy at the keyboard.
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.
Yeah, I used to work for a company that believed that. No specifications, since deciding how things will work would take too long. So we did iterative software development, instead - build it once, present it to the users, and then start over because it wasn't what they wanted.
I quit.
Oh man, am I ever happier now.
Joel is no idiot. He realizes that specifications take time and effort to develop, and to keep up-to-date. He argues quite convincingly for specifications as a wise investment of time, not a waste. A large section of this book is devoted to "painless" specifications, and it is insightful and useful. This book is the only book I've ever felt a need to keep next to my keyboard - and it's not even a technical manual.
That's cool, but I think having the book on your desk can do more to get other people to read it than pointing them to a web site. Logical or not the people who should read his stuff will be more inclined to believe a book though from experience the people who should read the essays, won't.
Frenchman to King Arthur - "You've got two empty halves of coconuts and you're bangin' 'em together"
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
I really don't understand the response. I work for a medium sized company that is growing fast. A lot of our initial infrastructure (hardware & software) came to the company via 2 key acquisistions. We use OS software and solutions where we can and were they make sense. Nevertheless, we have to be able to support a range of non-OS solutions. If we hire a programmer help maintain a legacy VB application it is great if he/she has OS experience, but certainly experience in MS environments is absolutely critical. Unless you are lucky enough to work in an OS bubble the questions you pose are just plain silly. What I personally value in coworkers is smarts, work ethic, and an ability to learn things quickly. The specifics are secondary because they change.
His point still stands though. It's a sacrifice. Anything you make at all, the very first decision you make whatsoever is whether you are going to actually make it, and that hinges almost entirely on how much it's going to cost to make. Stapling a bunch of fatty components together has the advantage of being relatively fast. It's not entirely uncommon for software to bloat up at first and trim it's fat here and there where it matters later.
So without bloatware, there would be products we wouldn't have at all.
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
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?"
Well that would be great if you were interviewing them for a job developing web applications on Linux - however, since he writes most of his software for the Windows platform they would be pretty useless questions really wouldn't they?
It's funny, everybody thinks they know to vote for one guy or the other, and they'll somehow prevent software development (or car-building, or steelmaking) from moving overseas.
But did you ever stop to think about the laws that would be necessary, especially for software or services? And could they be effective? If I buy software from a guy in the Netherlands instead of Iowa, are they gonna bust me?
What if I hire an Asian coder I met on a BBS to work on a site? And what if I like the guy's work, and I want to use him to work on 20 more sites? And then he decides to hire first one helper, then another, and his company grows? At what point do I have to stop doing business with him?
How do you write a law like that without being incredibly ambiguous, or leave numerous loopholes, or ways to work around it (not to mention the paid-for loopholes, similarly pitched in the name of "job protection").
Folks have been promising protection from overseas competition since... well, forever. And it should be blessedly obvious by now that it just doesn't work. Trying to regulate software and services in that manner is a civil liberties nightmare.
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.
>> Interesting reasons. Bloat is still bad, no matter how much CPU you decide you can throw at it.
It's comments like this that make me think that computer science should be taught as an engineering discipline.
It's a tradeoff. Engineers make tradeoffs all day long. Consider the costs and the benefits. In this case it's a tradeoff of how much does the user care about bloat vs. how soon they want the product. As disk and memory and cpu speed all increase EXPONENTIALLY at the same cost point over time, the tradeoff often falls towards bloat since exponentially falling hardware prices make the user more likely to be indifferent.
Yes asking someone how long they have gone to school is the same as asking someone what they have DONE at school. I've got 5 years of major ISP exp, that trumps 10 years of screwing around with a single PC in your basement.
kashani
- Why is the ninja... so deadly?
Going ahead without a plan is a sure-fire way to get shafted. Especiall when the client doesn't have only _one_ person representing them and making the decisions, as is the pipe-dream of extreme programming. You soon end up with 1 of them wanting something, 1 threatening to cancel the contract if he doesn't get something completely different, 3 playing politics and prestige games and trying to make a "my department is more important than yours" point to each other, and 2-3 wanting to turn the whole program into something completely unrelated because their department didn't really need an e-commerce system but could use a customized project planning tool.
And I even have an experience that went like this: the client actually nominated one person to represent him and make the decisions for him. The ideal situation, right? So we go ahead, and even accept a ton of change requests from him, and conversely he aggrees that extra time is needed to implement those. Also that some features that needed the most time weren't that necessary and can be left out for now. Had some iterations with him too. All went smoothly.
So then here comes the big day and deadline and have to get the program accepted and paid. And the client PHB gets in the act and overrides the representative. "What? You threw away _that_ feature I explicitly requested myself in the beginning?! On whose authority?! And why the heck is this program two months late?! I needed it in March!!" (The two months had been accepted by his representative as time to implement the change requests.)
Turns out the peon nominated to represent him didn't have as much authority as he and we thought. And not having anything written down and signed for all that stuff in between, well, basically his view was that we went into phantasy land and implemented something else than what he asked for. Two months late too.
"No development method can save you if complete idiots are in charge."
Quite insightful, but therein lies the rub: development without any specs and just doing what the clients fancy this week, basically puts _them_ in charge. They're your new managers, they decide what you do. And they're not even trained or experienced to manage a programming project. How do you prevent half of them from being complete idiots?
Basically I'm not against iterations as in showing the the client some progress. But I do like having _some_ specs, if nothing else to prevent wasting even more work.
True, the client doesn't know exactly what they want from the beginning, and just writing all down will make the bad spec that you mention. But here's the fun part: you can help the client give you a good spec. Mock-ups and small demos take a lot less work than actually coding those features, and lets them see roughly how things work and kill dumb ideas just the same.
A polar bear is a cartesian bear after a coordinate transform.
I simply do not understand it.
Perhaps because you're so blinkered by your belief in the 'one true way'.