Nick on 'Joel on Software'
Recently I have found a book in my company's library. The cover looked funny so I was curious enough to open the table of contents and then quickly scan through a couple of pages. Both topics and the language used in the book convinced me to take it home and I have finished in in just a couple of days. Here I would like to provide a quick review (probably 100,000th one if you search for others) of this book.
If you are an experienced software engineer, you will find most of the topics discusses in this book quite familiar. And if you are good one, you will most likely agree with most of the statements there. If you are a junior programmer and are just starting your career, I highly recommend you to read this book. First of all, you will better understand the behavior of your more experienced colleagues. Secondly, you will get soft of crash-course about “how to do the things right”
The author begins from defining a list of 12 questions, answers to them would rate the quality of the software development process at a company. I am totally agree with all of them. While reading this section I have immediately recalled one episode of my own career. It was the “second start” for me, first job after moving to a new country. In Canada, there is a very strong discrimination against the newcomers when it comes to the job search and it was the beginning of 2004, so I took one of two positions that were offered to me with almost no hesitation. It was a very small startup with some potential and…exceptional set of problems. Actually, it would rate ZERO using Joel Test. I have spent huge chunk of my 5-month stay at this company (before moving to a better place) by pushing them to introduce the source code control, the bug database, some sort of schedule, basic documentation and the design specs. I know that they have hired their very first tester after I have left. Unfortunately, it was too late for this company :( I am sure that if they were better organized, they would do much better.
Of course, the test is not perfect. My previous company would score probably at 6/12. But, in fact, I would lower the rating to 4. Why? Yes, they did have the source code control - one of the most expensive tools. Did they take full advantage of it? They were barely using it. CVS would work for them nicely and for free. Yes, they did have the bug database. One of the most expensive, again, as you can imagine :) But why did the list of bugs circulate around as Excel spreadsheets? Joel says that Microsoft scores 12/12. Formally, I believe him. Do they make good software? I do not think so. They definitely need a huge database for the bugs ;)
In the next couple of sections the author talks about some well-known (but not very frequently used ;) ) techniques like the nightly builds, functional specifications, fixing the existing bugs before proceeding to the major new features, prototyping and the danger of over-architecturing the solutions. I particularly liked the chapter called “Don't Let Architecture Astronauts Scare You”. Very true, the people sometimes go too far when designing software. Either they finally fail to create the product because they cannot really implement their super-advanced ideas or their product does a lot of things…except the one that was originally planned :) The key point there is about the productivity. At the beginning, there is a problem to solve. You succeed if you solve your problem. If you think about the future while designing the solution, you may create something that will work long enough to make the customers happy (and to make you richer). However, if you try to solve all imaginable problems around the original one, you will fail. Personally, I had a bunch of examples in my practice proving it.
The section on the interviewing gives some very simple and effective ideas about how to approach the hiring process (from the employer's perspective, but it may be also useful for the smart candidates to prepare themselves for the interviews at the good companies). Of course it is technical, but it is about hiring the developers.
The chapter called “Getting Things Done When You're Only a Grunt” is talking about the problem that is usually faced by the smart people starting working at the bad companies. I believe most of us have been in this kind of situation at some point during the career: you know how to do the things right but the place you happened to work at does not really encourage these development practices. How to remain yourself, how to do your job and deliver the quality and to avoid being fired for not respecting the questionable “company values”? How to make the things better? Especially if you are young and not the major player in the team. This chapter contains some useful and practical advises that may turn the situation in your favor.
At the end, there is a couple of chapters called “Strategy Letters”. They are mostly about the business-related problems that are quite generic. This is a mix of business examples, the author jumps from one to another criticizing some ideas, decisions and strategies chosen by various companies in the past.
I have noticed that sometimes the author becomes too rude (especially when it is about the interviewing process, I remember seeing too many words like “idiot”), too egotistic or just makes the statements without any justifications (just because I think it is right). Well, no one is perfect, this also applies to the engineers. Actually, the more you know, the more you realize how many things are out there that you do not understand, do not know good enough etc. I may be wrong, but I imagine it may be sometimes hard for the colleagues to work with Joel :) Sometimes I loose my patience too and if the person I am talking to does not understand what he/she is supposed to know for years. But the humans are not machines, I remind it to myself from time to time.
The author seems to be extremely proud of the fact that he worked for Microsoft ;) Frankly speaking, I am not a big fan of this company, what it did in the past (purely from the engineering perspective, nothing wrong with the business side). I was always comparing Microsoft with the tobacco companies. Some of them are very successful, they make a lot of money for themselves and their shareholders. However, the tobacco companies have [indirectly] affected the health of the millions…
The author seems to claim that he knows everything. He aggressively attacks many things, including the ones he is not familiar with. For example, in one of his “Strategy letters” he describes his experience with Java on the mobile phone. He says that he could not find a way to use the address book, SMS messaging etc from Java. Then immediately follows the statement “Sandboxes didn't work then and they're not working now.”
Regardless of these little problems, the book does worth reading. It is all made from the postings from his personal blog so you can also find all this stuff online.
blog comments powered by Disqus