Review on the book "Joel on Software"
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 is written by Joel Spolsky, published by Apress, in June 2008.
Joel Spolsky maintains the famous blog Joel on Software and writes extensively on software development, management and other topics that are of interest to software developers and their managers. This book collects some articles written by him that are regarded as having more endurable value. Probably almost all articles are available online and you can read them there. However, probably the benefit of having a such book is that you can pass it to your developers and managers so they can read it as well. Following we just talk about some topics discussed in this book.
He suggests the Joel Test which includes 12 steps to improve the development process. They look simple but some of them are not easy to follow in practice. For example, probably most programmers sit in cubicles and not many companies can provide for quiet working environment. Some managers mistakenly think that open space always creates congenial working environment while in fact most of the time it can be very distractive and counterproductive. However for some other steps you can do without much difficulty if you follow his reasoning.
For example, you should ask candidates to write code during interview. In practice, we have seen too many architects or senior developers who can write very fancy specifications or draw architecture diagrams but fail to write any code. It is important that the candidates are smart and can get things done. You should also feel comfortable working with them if they join the team.
He also talks about avoiding "architecture astronauts" whose minds are only on abstract ideas so high in the sky that we have to gasp for oxygen. He also brings up the concept of "leaky abstractions" so we should be prepared to peek inside the nice abstractions from time to time if something goes wrong. All these discussions help developers avoid chasing the fad and stay down-to-earth to solve problems that are practical. To understand his whole reasoning and argument, you'd better read his book to have full understanding.
Throughout the book, he also touches on why Microsoft is so successfully and will stay. This is probably a useful reality check for anti-Microsoft enthusiasts.
There are also some other interesting topics such as why and how you should write specifications and manage schedules, the economics of open source, why the so-called bloatware could stay and win. All in all, this book is full of insights on software development, management and other topics that you may encounter in your daily life. You may also feel delighted sometimes in what he says because you want to say the same but fail to say it so well as he does. It is certainly a delightful read.