Joel On Software is originally the web site at http://www.joelonsoftware.com/, but it is also a "best of" compilation from the web site, in book form. Both are by Joel Spolsky, a programmer who worked on Excel and Juno throughout the nineties, and now runs Fog Creek Software. Here I refer to the content of both jointly as Joel On Software, with emphasis on the presentation in the book.
The full title of the book itself is in fact,"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, Work with Them in Some Capacity". Wow, that nails it pretty well.
Joel On Software is a book about several things; it is about programming, it is about software development, and it is also about software project management, among other things. The book is directed, as the title indicates, at a variety of different people, from pure coders to codeless managers, but mostly people who are somewhere in between. The actual content of the book is in essays which are largely copied verbatim from the web site.
Joel's positions are very practical. He is not really into Methodologies or New, Exciting Platforms. He is into having the best coders and making and letting them do what they do best, day in and day out, which is programming. This emphasis on programmer skill and personal commitment over methodologies and New And Exciting is in fact a recurring trend in all of the books I like on software development. (Compare Facts And Fallacies Of Software Engineering, The Art Of Unix Programming, The Pragmatic Programmer.)
The first part of the book, "The practice of programming," contains essays about programming; that is, it is more for programmers than about them. Here are some of the highlights from the programming section.
This essay is a great first step in evaluating your software development organization. Here, Joel outlines a painfully short 12-step test for determining just how bad your project or team is. The test does not provide a hard and fast rating; rather, it gives general indicators of what is happening in a few different areas, and a good starting point for a high quality organization.
(Instead of posting the test here, I will recommend that you go read it on the site; it is presently located at http://www.joelonsoftware.com/articles/fog0000000043.html. It is very brief.)
The company where I work, which shall remain anonymous, does not fare very well against the Joel test. We get at least a 1 on the Joel test for using source control. We probably deserve a 2 for source control and daily builds, since I build my whole project every few minutes, and no project is done by more than 2 or 3 people at a time, usually. My perception is that other parts of the company (or, rather, the other four guys) usually have a spec and often have a schedule and other such things, so there may be a 5 or 6 over there.
Over-emphasis of the test might qualify as cargo cult behavior, but this is unlikely. Having or doing any one of the things on the test is a definite and significant improvement over not having or doing it. So the Joel test apparently serves as an indicator of quality, as well as a direct path to improvement! This is a great mystery.
Joel killed a lot of trees over functional specifications; there are 4 consecutive essays on them. What he has to say can be summed up pretty well using the titles of the essays and a nice quote from each:
- Part 1: Why bother?
- Answer: "because when you design your product in a human language, it only takes a few minutes to try thinking about several possibilities, revising, and improving your design."
- Part 2: What's a spec?
- Answer: "A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on."
- Part 3: But... How?
- Answer: "program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs." (Joel discusses what exactly a program manager is. Use your imagination.)
- Part 4: Tips
- Answer: (See essay for five bulleted points, starting with "Be Funny.")
So, I hope you get the idea. Joel puts a lot of emphasis on certain, highly necessary parts of project management, and one of them is the functional spec.
This is in contrast to all the people who either don't do a spec at all, or do a half-assed mini-specification as part of the presentation to the client (such as us), or engrave the technical details and price into the functional specification (alternative view of us). Joel mentions a technical specification, which is apparently a different part of the process.
There are a great number of other interesting and important things you should probably read out of the programming section. Check it out for yourself, or poke through the archives on the web site for anything that sounds like something you don't know about.
Joel has written a lot of essays about different aspects of project management. Some of them are about managing the programmers, and some of the are about managing... the other stuff. Whatever that stuff is, he writes about it. Here are some of my personal favorite bits out of the management stuff.
This is one of my favorite sections of the book. It seems to me that if a 'Joel' ever interviewed me, I would do just about as well as a recent computer science graduate, or even better. Joel emphasizes general programming and problem solving knowledge over knowing language syntax or all of the libraries from memory, et cetera. In fact, the best summary is the one he gives: Smart, and
Gets Things Done. I could give you all the bulleted points, or you could go and read them yourself.
Among other controversial issues, his mention of college education is lumped in with looking for acceptance by "selective organizations" such as Microsoft and Yale. It is observant that excitement and intelligence don't always represent commitment or diligence, and that there are few things to indicate those. (I lose on that one; I dropped out of Purdue, which is not as selective as you might think.)
My second favorite out of the management section is the iceberg. Or rather, the iceberg secret. The iceberg secret, briefly, is that non-technical people do not know that the visible, surface user interface is only a small fraction of the work that goes into the project. (This is even true in web applications, believe it or not.) This 'secret' is actually something most people in the field probably know by instinct.
It seems a great number of my frustrations grow out of this fact. You see, in my present project, I am in direct contact with the graphic designer who is "designing" the web site. (She works at a marketing firm that brings us a great deal of business.) She doesn't have a good sense of what I do all day, and thinks the better part of my job is making sure the type is correct on all the pages, and seeing to it that all the fonts are just perfect. (I do do all that, of course, but I would rather do it at the right time.)
Other random things
There's a lot of "other", since not everything is either programming or management. There is a lot of market position and "don't do this, it's really stupid" type stuff in his rants, and a lot of surface analysis of businesses and business practice having to do with basic microeconomics, and so forth. There is a lot of stuff worth reading in there if you like stuff that's filed in "bizarre , miscellaneous and other".
Actually, I'm being unfair; there are 3 sections that aren't programming or management. One of them is odds and ends; one of them is specifically about Micorosoft and their strategy; and the best of "Ask Joel". I think these parts are in the back for a reason; it is because Joel would really rather you read about functional specifications and character encodings and architecture astronauts and so forth.
I've just tried to give you some inkling of what the book and site are about. I've also been griping about my own organization. The cool part, though, is that my boss really likes the book, so I assume he's looking at getting a lot of the Joel test stuff going, and probably looking into some of the other things. (I hope he looks at the interview stuff and then gets us some better programmers, so I'm not the only one pulling in an 80% profit margin. :)
Note that, on the subject of Joel, he hath also written User Interface Design For Programmers, which also is loosely based on essays from the web site, but with more extra content.