Joel On Software 166
| Joel On Software | |
| author | Joel Spolsky |
| pages | 362 |
| publisher | Apress |
| rating | 9.5 |
| reviewer | Daniel Shefer |
| ISBN | 1590593898 |
| summary | Great insights into programming, software in general and how to do it right. |
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.
Joel is a blowhard (Score:1, Insightful)
Re:Joel is a blowhard (Score:2, Insightful)
You just described most of the programming population (except for the fog creek part)
From Joel's blog (Score:1, Insightful)
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.
Re:From Joel's blog (Score:3, Insightful)
Re:From Joel's blog (Score:4, Funny)
Re:From Joel's blog (Score:4, Insightful)
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.
Re:From Joel's blog (Score:3, Informative)
Re:From Joel's blog (Score:2)
That's not a political issue. (Score:2)
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)
Aha! (Score:5, Interesting)
Joel is assembling a volume of "the best software essays" of 2004 and is taking reader nominations [joelonsoftware.com]. Suggest something if you have a favorite, or just click through and read everyone else's picks.
Worth noting (Score:5, Interesting)
Re:Worth noting (Score:4, Insightful)
Re:Worth noting (Score:1)
GoingWare's Bag of Programming Tricks (Score:1, Offtopic)
It is Google's #1 hit for programming tricks [google.com].
I have quite a wide range of interests, so the articles aren't really just about programming anymore.
like How to Promote Your Business on the Internet? (Score:1, Interesting)
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.
Re:like How to Promote Your Business on the Intern (Score:1, Offtopic)
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.
If you like my writing, there's more (Score:1, Offtopic)
Something like fifty articles, essays, rants and scrawls.
The author of DrunkenBlog says of Living with Schizoaffective Disorder [geometricvisions.com] " It's the kind of thing that reminds you of why the web is cool. [drunkenblog.com]"
Stop me before I write again (Score:2)
A quick FYI (Score:5, Interesting)
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
Re:A quick FYI (Score:2, Insightful)
Re:A quick FYI (Score:2, Insightful)
Re:A quick FYI (Score:1, Informative)
Re:A quick FYI (Score:3, Insightful)
Software is not factory work, methodologies come in and out of favor, but great developers produce more and cleaner code than an average developer. I have never been on a project where people can be replaced like "lego pieces". There
OT: Re:A quick FYI (Score:3, Insightful)
Re:A quick FYI (Score:1, Offtopic)
Re:A quick FYI (Score:2, Informative)
Just playing devil's advocate here, how would top executives know how to spot a talented developer? There's a developer at my work that people think is "very talented" because he's always boasting about how good and fast he is, inflating his own accomplishments and stroking people's egos. Realistically, he's an average developer, but he fools the "top executives" because they all come fr
Re:A quick FYI (Score:3, Interesting)
Indigo was supposed to be available for Windows XP and Windows 2003 [msdn.com] ever since it was announced.
Don Box's introduction to Indigo in the Jan 2004 issue of MSDN (available on the web since early November 2003) says as much [microsoft.com]:
Definitely no PHB (Score:4, Insightful)
I'm Joel's collections made it into dead tree form as that will lend them some more credibility. Good reading.
Circular Reference (Score:4, Funny)
Joel on Software is a collection of essays from the Joel Spolsky's Joel on Software web log.
Re:Circular Reference (Score:1)
[Book name] is a collection of essays from [author name]'s [blog name] web log.
They just all happen to have the same name!
Re:Circular Reference (Score:2)
Damnit, they should have namespaced it!
What I liked was this one:
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...
Well yeah, if both options are evil, of course you can't get fanatical about one approach over the other. Sheesh.
Re:Circular Reference (Score:2)
Yeah, that's a much better example.
People should also scold Microsoft for using the name "Avalon", which will only cause confusion since both Avalons are architectures for developing applications.
Watch those guys (Score:3, Funny)
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.
Opinionated?! (Score:1)
I prefer to be called "honest" and not "opinionated".
Re:Opinionated?! (Score:2)
Got one? (almost any evil will do - war, terrorism, child molesters) In the cosmic scheme of things, software companies don't even show up on my evil radar.
Q.E.D.
I do not pay much attention to Joel Spolsky (Score:2, Insightful)
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 [fogcreek.com], 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 li
Re:I do not pay much attention to Joel Spolsky (Score:3, Insightful)
Re:I do not pay much attention to Joel Spolsky (Score:3, Insightful)
Read through Mr. Spolsky's web site and see that he doesn't acknowledge free software/open source at all other than sterotypical blanket bromides.
Re:I do not pay much attention to Joel Spolsky (Score:5, Insightful)
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?
Re:I do not pay much attention to Joel Spolsky (Score:1, Troll)
In terms of intelligence, there is a huge difference between person X, who began using Linux (or *BSD) in 1993, and person Y, who waited until 2003 to do so. Person X is likely to be far smarter (unless person Y was, say, only 10 or 12 years old in 1993).
Re:I do not pay much attention to Joel Spolsky (Score:2)
Re:I do not pay much attention to Joel Spolsky (Score:4, Insightful)
kashani
Re:I do not pay much attention to Joel Spolsky (Score:2)
Trust me, people such as Linus, Larry Wall, and Tim O'Reilly are damned smart.
Just becuase some smart people adopted Linux early does not mean adopting Linux early is a sign of being smart. I mean, I assume you adopted Linux early, but you include such an obvious logical fallacy as this, so right now I'm not impressed with your smarts. Unless your a troll, in which case it was well done.
And if you think that Windows has a future (as Joel apparently does), then you are probably an idiot.
If you thi
I simply do not pay much attention (Score:4, Insightful)
Perhaps because you're so blinkered by your belief in the 'one true way'.
Re:I do not pay much attention to Joel Spolsky (Score:2, Funny)
Re:I do not pay much attention to Joel Spolsky (Score:3, Insightful)
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.
And if you understood that sold software is intended to generate income, not exist for its own benefit, maybe you could run a business.
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?
What the hell for? Lots of intel
Re:I do not pay much attention to Joel Spolsky (Score:2, Insightful)
When the time comes (ie, there is a significant linux desktop pre
Bloat is good! (Score:3, Insightful)
Interesting reasons. Bloat is still bad, no matter how much CPU you decide you can throw at it.
Re:Bloat is good! (Score:4, Insightful)
So without bloatware, there would be products we wouldn't have at all.
Re:Bloat is good! (Score:2)
What does CPU have to do with big binaries, besides an increase in paging, which is arguably a memory thing, even if you're talking about CPU cache...
Re:Bloat is good! (Score:2)
Re:Bloat is good! (Score:5, Insightful)
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.
Re:Bloat is good! (Score:2)
That distinction is already made. You have computer scientists (people who do research into cool type systems and write lots of papers), and you have software engineers (people who work with existing tools and write big systems in the "real world"). Both sorts do valuable work, but in completely different ways and with completely different goals. And I don't think the choice of terminology was
Re:Bloat is good! (Score:2)
The problem is that many software "engineers" are trained with computer science degrees resulting in poorly engineered systems.
Re:Bloat is good! (Score:2)
Sure, if your code is intended for the "lean mean programming competition 2005" then you want it to be slimline, but if it's heading for your customer's PCs then you have to fulfill their criteria, and size of application is probably 23rd on their wish list.
Re:Bloat is good! (Score:2)
Sometimes it means that you have to deliver something that is not as perfect as you would want it to be; make it more perfect would require too much resources. Resources that you don't have, or that should be used for something else.
It also shows in his opinion about the rewriting of
Re:Bloat is good! (Score:2)
<sarcasm>He wants us to demean our art with commerce! Shock, horror. That would be untrue to our Xerox PARC ancestors.</sarcasm>
"Currency is the sincerest of flattery" said someone, and to some extent it's true. That people are willing to pay for the product (whether in classic license or shareware license or GPL support license) is important. For one thing, it keeps me supplied with hardware:-)
Re:Bloat is good! (Score:2)
Bought It. Reading It. Enjoying It. (Score:1)
Actually I just read this too... (Score:4, Insightful)
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.
Re:Actually I just read this too... (Score:2)
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.
His essay on functional specs misses the mark in a number of areas.
He starts out wrong:
Nobody who's managed more than one project makes that claim twice and for most managers, the need for specs is obvious. The usual reason projects
Re:Actually I just read this too... (Score:2)
1) Customer requirements spec written by the Client/User/Business Analyst/consultant. Provided what they request is feasable, we go to:
2) Functional spec prepared by the Systems Analyst, gives a high level overview of how the solution will work. If this is approved by the Client, and the solution is sufficiently complex, we go to:
3) Techincal spec prepared by the Systems Analyst, upd
Review advertised. Summary delivered. (Score:5, Insightful)
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.
Sounds like 13yr old kid rants (Score:3, Interesting)
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.
Re:Sounds like 13yr old kid rants (Score:2)
Interesting comment. When I read this sentence I couldn't help but think about a chap called ESR who wrote a whole book based on a shitty little mail application. And somehow, that book has turned into one of the cornerstones of the open source movement.
For many segments of this market, the operating system used becomes a secondary issue to having an
An error in one of his essays (Score:4, Interesting)
Re:An error in one of his essays (Score:3, Informative)
Re:An error in one of his essays (Score:2)
Re:An error in one of his essays (Score:1)
Re:An error in one of his essays (Score:2)
You can do "assert(&r != NULL);", I guess, but that is utter nonsense.
Re:An error in one of his essays (Score:2)
When you have an object that seems OK, and then you try to call a member function on it and it goes boom, it means that somebody else stomped on the memory of that object. (I guess the other possibility is a bad link where the header file and the library are out of sync, but that shouldn't be the case in a field failure.)
Cosmic rays or
Management (Score:2)
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
Re:An error in one of his essays (Score:2)
Re:An error in one of his essays (Score:2)
> What's its behavior? It's undefined, because a pointer-to-NULL is dereferenced, and that's a big C++ no-no.
> It could be anything whatsoever according to the C++ standard.
In other words, Joel was lucky.
He could have ended up with demons flying out of his nose [catb.org].
A wee bit disappointing... (Score:4, Insightful)
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.
Re:A wee bit disappointing... (Score:3, Insightful)
Joel is smart, but he's decidedly old school in many ways. Or rather he's old school for the typical reason people are old school: because he's resistant to change. This is common among technical people in my experience. First they rant about h
Re:A wee bit disappointing... (Score:2)
I've never quite understood... (Score:2)
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).
That's because so much depends on the people... (Score:2)
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 befo
Re:I've never quite understood... (Score:4, Informative)
All the
Functionally, VB.NET, C#, J#, and Managed C++ all have exactly the same capibilities. They are all sequential, procedural, imperative, object-oriented languages that support single inheritance, interfaces, events, exceptions, type generics(they will in v2.0), reflection and share a common runtime library and work in a sandboxed VM. The ONLY differences between them are in syntax. So, it doesn't really matter which of these languages are used unless someone in the group doesn't know the syntax for a language in a source file they need to work on. The interfaces between them will be equivalent regardless of language.
Compare this to a functional language such as Common LISP [iu.edu] or Scheme [drscheme.org], or a declaritive rule-baed language like Prolog [csupomona.edu] or Mercury [mu.oz.au]. Mercury can compile to
Haskell [haskell.org] has to jump through hoops to get the needed multiple inheritance to work.
OTOH, there are some interesting projects like F# [microsoft.com], an OCaml like functional language. It has some serious issues to be compatible with
It's like Microsoft offers you several languages, but they are all the same. The illusion of choices without really having any. They should just be like Java and admit that there might as well be one language-- seriously, Java could have all the multi-language support of
As for what languages should be used when, where and by whom: I don't know. I'm still trying to figure that out. I know that some are good and bad for certain things, but I also know that personal preference is important, too.
</rant>
Joel is way too self-assured (Score:3, Informative)
Joel is good,but his sayings are common sense. (Score:2)
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. I
Testing, Dog Food and Open Source (Score:2)
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
Re:Testing, Dog Food and Open Source (Score:2)
Proper QA testing is vastly different from actually sitting down and using the product; the two are no where near being close.
If a developer is 'testing' a product, they're suppying known inputs to subroutines to see what gets returned, putting in known data to see if calculations return appropriate answers, and so on.
If they're actually 'using' the product, they notice that that little popup that happens for result X really should just be a status message on the bottom of the window, or that this data
Joel on boring (Score:2)
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'
Re:Bullshit (Score:1, Funny)
Re:Bullshit (Score:1, Insightful)
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?)
Re:What's the guy's name again? (Score:2, Funny)
Re:Yep, this guy's an idiot (Score:4, Funny)
Re:Yep, this guy's an idiot (Score:5, Insightful)
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.
Re:Yep, this guy's an idiot (Score:2)
That's a fine anecdote, and an unfortunate experience, but it's not proof that specs somehow save you from this problem. You were clearly deciding how things work when you built the code, so decisions got made. If those bad decision
Re:Yep, this guy's an idiot (Score:4, Insightful)
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.
Re:Yep, this guy's an idiot (Score:2)
We even had such a project. The manager was basically sick and tired that the subordinates were
Re:Yep, this guy's an idiot (Score:2)
Well, gee. It's so obvious. I wonder why noone else figured that out before. (Sarcasm there, if you can't tell.)
"B) automate all your tests"
We do.
"Yeah, if you're used to writing buggy software, that's a good attitude to have. But doing XP, you're doing QA from day one via automated acceptance tests."
Ah, more XP bullshit and double-speak.
No, XP merely redefines the meaning of the word "bug". If it's not in an automated test, it's not a bug. Even if the client's data is pwn3d by an
Re:Yep, this guy's an idiot (Score:2)
I believe that's already explained in Kent Beck's books very clearly. It's based on redefining semantics so that "bug" suddenly means what everyone else calls "known deffect".
Funny thing is, Microsoft too ships with no known defects as a matter of policy. By XP definition (again, Kent Beck's definition) all the buffer overflows and exploits that pop every weeks are therefore not bugs. They're at most change requests and
A bit trigger happy with the name calling? (Score:3, Interesting)
'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 [joelonsoftware.com] is where I got this quote.
Re:Cool (Score:1, Informative)
Amazon Spammer at it again... (Score:1, Informative)
He [slashdot.org] has [slashdot.org] a [slashdot.org] history [slashdot.org] of [slashdot.org] this [slashdot.org].
Quit modding this dickhead up.
Re:Cool (Score:1)
Another book on programming interviews (from the interviewee's viewpoint) is Programming Interviews Exposed [amazon.com]. Seems like a decent book for preparing for Microsoft-style interviews.
EricJavaScript is not Java [ericgiguere.com], damn it!
Re:Open Source Citydesk? (Score:1)
Just guessing, I'd start with DocBook. I *think* there's a free online book about it at O'Reilley.
All of the above is a guess-- I'm not much involved in producing documentation.