Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Wo

Rating:
Summary: Good Book? I Don't Think So
Review: All these raving reviews must be the author's friends, because I didn't see what they were raving about. Spolsky can be amusing at times, but his advice is not something I would impart into an professional development organization.

If a software development manager insists this is a must-read for his/her organization, then he/she should be fired immediately.

Rating:
Summary: Entertaining and informative
Review: Anybody that works in software will thoroughly enjoy this book - even if you won't agree with everything the author has to say his views are well presented, to-the-point and delivered with a good sense of humor. In my case I've found myself agreeing with almost everything in this book, I wouldn't be surprised if you would find the same thing too.

The book is broken down into short self-contained chapters, making it a perfect companion for the busy software professional. Highly recommended.

Rating:
Summary: Every programmer should read this book
Review: Every programmer should read this book. It's as simple as that. Joel is a legend in the industry and his articles have been required reading for some time. He covers technical topics, as well as project management and professional topics. But the real value of the book is in the practical advice he presents in an entertaining manner.

Every once in a while a book comes along that rekindles your interest in the topic. This is one of those books. There is so much good information, and it's presented so effectively, that you will be motivated to do something with it that will help your projects and your career.

Rating:
Summary: why bloggers should remain bloggers and not author books
Review: Halfway through this book I realised I kept getting more and more irritated until I finally stopped to figure out why I was getting so annoyed.
At first I thought it was because of his comparisons between engineers who program on the unix platform vs. those who program on the windows platform ( according to the author unix programmers are "programmer centric" while windows programmers are "end user centric" ) - that comparison rankled a little bit but it wasn't a completely egregious statement. I happen to not agree with it but I can see some kind of argument for this theory. I then thought it might have to do something with the fact that he talks highly of Microsoft as a company ( that's ok with me :-) and cites some really idiotic reasons for why that company is way ahead of all it's competiition ( because it's led by a programmer as it's CEO ).
No - it turned out that I was getting more and more annoyed with his attitude towards bugs/QA and testing. He recommends 1 tester per 2 programmers as one of his criteria for an organisation scoring well on the "Joel Test". His attitude towards programming seems to regard bugs as a natural side effect of programming - which is why he recommends a ratio of 2:1 . We all know that "bugs" is a synonym for "errors" - producing errors as part of producing code is NOT ok. The words bugs implies a sentient existence ( like " a bug crept into my code" ) which is dodging responsibility for the "errors" you are introducing. Seriously - this attitude should be considered gross incompetence in any programmer.

He also comments ( in chapter 1 ) that students learning to program should be taught using C because that exposes the innards of a computer to them ! He does not understand what programming really is - instead he wants to expose irrelevent details like how an array is actually allocated located on the stack. IMHO - teaching programming to a novice using C as your vehicle is forever going to make him either brain-dead or make him really arrogant about "getting pointers" ( rather like the author ).
The author also devotes a chapter to a concept called "Leaky Abstraction". As an example he cites TCP over IP as an abstraction of guaranteed delivery over an unguaranteed delivery channel - the leakiness that he then cites is that TCP cannot gurantee delivery if say a dog chewed through your network cable ! The example by itself is OK but his argument is specious at best.

Please read his blog if you are interested in what he has to say - don't waste money on this book.





Rating:
Summary: New release now, but a timeless value
Review: I love the many comments about development tools and the selection of programming environments. I wish more IT folks had some kind of clue about this sort of thing. The section on character set encodings was spot on.

There are so many different items of value in this book. Yet it flows and doesn't feel overloaded. Some commonly overlooked coding subject matter; lots of industry and project insight.

As the author stated, too many projects do fail. I think this book at least lightly supports my notion; that there are just too many make-believe chefs in the kitchen.

Controlling management types should take the day off and consider some of what's in this book. Programmers are going to find a lot of great morsels and some good laughs.




Rating:
Summary: Great Read!
Review: I'm an experienced software developer, but I wasn't a computer science major and haven't worked for a large software organization. To date, formal specifications, formal schedules, daily builds, bug databases and other topics covered by this book are ideas I haven't been exposed to. This book brought me up to speed and showed me how to apply these common sense approaches to my development in spite of the fact that I don't have management authority. I'm sure I'm a better developer as a result of applying the principals discussed in this book. I highly recommend it.

Rating:
Summary: Extreamly thought provoking.
Review: Joel is good a pissing people off! Weenie armchair quarterbacks and other fanatics that are easily infuriated probably won't like this book, or Joel's other writings.

A first glance at this book might give you the impression that Joel Spolsky is another bloging cynic with more opinion then experience. But don't be fooled. Joel is a very smart guy and this book is a great read. You probably won't agree with everything he says, I don't, but this book really makes you think.

An old coach of mine (Tony Blauer) told the "Good information doesn't displace OTHER good information."

Considering opinions that are the same as our own is far less valuable than opinions that differ from our own. Joel's book is full of opinions that have "growth opportunity.

Really good writers make you think. According to the chief blogger on my team at Microsoft (Rory Blyth) a great blogger is at least a but controversial, they not only make you think, they make you want to respond. Joel is on my short list of bloggers in aggregator.

The book is basically a collection of Joel's writing originally published on his blog at www.JoelOnSoftware.com, though this is not his first book. As near as I can tell the writings span a time frame from 2000 to 2004.

Joel is an interesting guy, the kind of guy you'd love to debate. He was an Israeli paratrooper went to Yale, worked at Microsoft for a few years then Juno, and now owns Fog Creek Software in New York.

To begin with, the book is a FUN. Joel's casual writing style is almost conversational and makes for a read that's more like listening to a story than reading a manual. I read it cover to cover in two days.

One of the things that I, as a Microsoft employee, love about the book is that Joel published his thoughts at "points in time" and his opinions evolve over time. It's important to remember this as you read the book. His opinions as a former Microsoft employee are also interesting. Some of them I see as dead on. Others tainted by the years between now and when Joel worked at Microsoft and distance between Microsoft's strategy then and now, and, of course, Joel's morphed perspective as the owner of a growing Software Vender. None the less, this is the kind of guy you'd wanna have dinner with. (Joel, can I buy you dinner next time I'm in New York ?)

Above all Joel's perspective on software development is, pragmatic and honest and his style of communication is direct, even blunt (which I love.)

The book is divided into five parts.

1. The practice of programming.
2. Managing Developers
3. Random thoughts on Not-So-Random Topics
4. Microsoft's .NET
5. The Best of Ask Joel

Part one on the practice of programming is full of hard nosed, pragmatic guides for developing great software including Joel's somewhat famous "12 Step Test", the importance of writing specs (and HOW to), scheduling software projects, why you MUST daily build, "Hard-Assed bug fixin', the Five Worlds of Software Development, Paper Prototyping, "Architecture Astronauts" (WICH I LOVED) , Fire & Motion, Wrong Ideal from Computer Science, Biculturalism, and Crash Reports (brilliant!).

Part two can basically be viewed as a forensic guide to (organizationally) why software development projects often fail and how to manage software development so that it doesn't fail. He bucks conventional management theory in explaining that most "incentive programs" in software development are counter-productive, that the industry fails to appropriately hire and keep software testers, developers NEED workspaces with walls and doors, and "Things you should never do" including some really interesting theory on "leaky abstractions".

Part three is all "Joelisms" !

I'm not going to describe this section too much - you really need to read it for yourself, but here are some of the chapter subjects.

" Rick Chapman's In search of Stupidity.
" What is the work of Dogs in the country?
" Getting things done when you're only a grunt. (MANDATORY READING !)
" Big Macs vs. The Naked Chef.
" Nothing is as simple as it seems.
" Defending "Not Invented Here" Syndrome.
" Ben & Jerry's versus Amazon.com
" Chicken and Egg Problems
" Bloatware & the 80/20 myth.
" The Economics of Open Source
" Murphy's Law gone wild.
" How Microsoft lost the API War.

Part four is Joel's reactions, over time, to .NET Tools and Technologies.

Part five is the Best of Ask Joel, selections from his forums.

In summary. GREAT BOOK, whether you agree with Joel's opinions or not. As easy as this book is to read, everyone that works in some part of Software Development or IT should read it.

I hope Joel writes another opinion based book. There are lots of folks writing books that help you learn, far fewer folks are writing books that make you THINK.

Lastly, the thing I liked the very most about this book is that it's reminded me how much I want to write MY OWN book.

Thanks Joel.




Rating:
Summary: Thought Provoking
Review: Joel on Software is a collection of 45 articles from Joel Spolsky's Web Column. Yes, that means you could read these articles online for free, but if you're like me you'll appreciate having the best of the collection gathered and arranged in one easy-to-read-anywhere source.

So what are all these articles about? Opinions. Joel is one of those guys that has an opinion on everything and sometimes he's even right. (Sorry Joel, couldn't resist.) Just how right and how wrong will vary for each reader I'm sure, but in truth it doesn't matter. Joel's observations, rants, strategies, and opinions are always intelligently presented. That means he'll make you think, especially when you disagree.

Joel's articles are organized into three major sections and two minor ones. The first big section "Bits and Bytes: The Practice of Programming" is a collection of Joel's thoughts on the art and science of programming. This section largely branches out from one of the early articles, "The Joel Test: 12 Steps to Better Code". As it sounds, this is Joel's 12 Step Program refined from years of programming in the trenches. I agreed with him on many points, and only strongly disagreed on one point. He convinced me to at least try a few practices that I hadn't given enough consideration to in the past and that's never an easy sell with me.

The next section, "Managing Developers", centers largely around, well, managing developers. Joel has plenty of experience here. He held manager positions on the Microsoft Excel team as version 5.0 was developed, he was in charge of developers at Juno for years, and he now runs Fog Creek Software. I'm not a manager and never have been, so I honestly didn't expect to get much out of this section. In truth, it was probably my favorite. I learned scary facts about interviewing and the interviewing process, the effectiveness of multitasking (for humans, not processors), and just how the people calling the shots think. He makes a sensational case in here about why you should NEVER rewrite a code base from scratch. I just knew he was wrong about that before I read this book. I'm still struggling to find the faults in his logic, but he certainly put a few cracks in my armor here...

The last major section, "Being Joel: Random Thoughts on Not-So-Random Topics" is really an insightful section on business strategy, as it applies to software operations. There is a classic contrasting of Ben & Jerry's verses Amazon style growth, a definition of what exactly bloatware is, a great look at the economics of open source software, and detailed look at some changes Microsoft is going through.

Finally, there is a small section on .NET, which surprised me by being interesting to my non-Microsoft self, and a short Q and A with Joel appendix.

In all this, Joel basically develops his version of Sun Tzu's The Art of War for programmers. There are great tactics and strategies to be learned here for any level of programmer. You might have to suffer through a little praise for Microsoft and listen to some painful truths about Unix, but Joel is a fair-minded author who will also tell you what Unix does right and where Microsoft makes mistakes. Ride the waves when he stirs things up and learn what you can. Just don't tell Slashdotters what you're reading.

Rating:
Summary: Worthwhile your time, some drawbacks.
Review: Joel Spolsky does very well in presenting the "best of" his weblob - Joel On Software - in book form. There are very few rough edges due to the transition of one form to another.

As for content, Joel has unique insights on the software industry, albeit from the shink-wrap Windows-centric world. When Joel stays the course and talk about these things he excels and draws non-obvious, but intuitively right conclusions. I quite enjoy his writing style and have found his thoughts on paper very useful. This book is an easy read, and hard to put down.

The only downfall of the book is the same problem that Joel himself criticises Eric Raymond for in "The Art of Unix Programming" - that is, his statements on a culture that is foreign to him often miss the mark. While ESR paints the Windows-culture incorrectly in his otherwise excellent work, Joel misses the boat in his characterisation of the Open-Source community. Too often does Joel dismiss the Open-Source community as teenage bedroom hacker zealots, rather than a broad community inclusive of professionals and large multinationals.

While distracting from the remainder of the book, we can forgive Joel - his business is Windows shrink-wrap, but his insights go further in describing a broader subsection of the ICT industry. This book is good stuff, and is a great follow on from his excellent previous work on user interfaces. A good read for software engineers, developers, programmers and those people that manage these activities.

Rating:
Summary: "mumbhai" is being silly
Review: Listen, if you take this guy's review seriously after reading something like this:

We all know that "bugs" is a synonym for "errors" - producing errors as part of producing code is NOT ok. The words bugs implies a sentient existence ( like " a bug crept into my code" ) which is dodging responsibility for the "errors" you are introducing.

then there are issues.

"bugs" does not mean "just" errors. Let's say I read the specs, ask questions to the writer of the spec to clear up ambiguities, program exactly to spec - perfectly, and after I'm finished: something changes in the spec. THAT IS A BUG.

Or, let's say it gets past spec, development, and Beta stage and their is a request from your users to change something. THAT IS A BUG.

Or, let's say there is a suggestion of a new feature. THAT IS A BUG.

Bug's encompass a lot of things besides just "errors". Think about that and then think about this guy's rant.