Joel On Software

Posted December 8, 2020

Joel Spolsky is a computer scientist and blogger who wrote many books about programming and software development. Some of his observation about programming are timeless, and his books are worth a read. The writing style is light and enjoyable making his articles both educational as well as easy to read. His blog joel on software was also compiled into a series of books. Some of the blog posts are pertinent today and even explain my interest in maintaining this blog. I have tried to include some of my favourites here.

The Law of Leaky Abstractions

Programming is full of abstractions and they are extremely useful in making complex topics easier to understand. Compared to C and C++, garbage collected languages such as Python and Java are far simpler to use because you don’t need to directly manage memory. The user is abstracted from the memory by the allocator and garbage collector. This abstraction, however, is not perfect and it’s possible to still have memory leaks and other problems. A leaky abstraction is one that forces you to still have to understand how the layer under the abstraction works. The abstraction saves you time but relying on it too much can lead to other issues which are far harder to solve.

Cardboard Chewie

A client entered into a software company and noticed one of the developers sitting at a table explaining a complicated issue they were having with a life-sized cardboard cut out of Chewbacca. The person asked a manager what was going on and it was explained to him that 4 out of 5 times chewie can solve the issue. This had the added benefit of reducing the number of times one developer would need to interrupt another dev to ask questions. The process of explaining and issue can often highlight something that was missed or allow a person to reconsider the context enough to be able to answer the question themselves.

Joels 12 Rules

The article is a simple checklist of things companies can do to make sure the quality of their code is as good as possible. I am amazed that even today I have worked for companies that don’t have continuous integration. It is also difficult since nowadays for quantitative trading, there is an expectation for quants to also have a high level of programming as well as dev ops. Knowing how to use git properly is an invaluable skill even as a quant.

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

It’s Better to Refactor than Rewrite

The temptation to start from writing a piece of software from scratch is always there but in almost all instances is the wrong decision to make. Joel talks about how Netscape was the market leader and then decided to rewrite everything from scratch. This was a massive mistake since by the time they had completed the re-write they had completely lost their market share.

Always Ship Your Code

It is better to get something close to correct and into production since there is a huge amount to be learned from live trading. It is a similar problem to analysis paralysis in quantitative research. There is always a temptation to do a little more tuning. In the same regard with software, there is always a tradeoff between getting an imperfect product to a client and never delivering anything. I think one of the main advantages is that the faster the code ships, the faster issues with the foundation code are identified and fixed. This saves a lot of waste time in having to retest (backtest) software once at a later data a bug is found.

Eat Your Own Dog Food

To write good software the company should use the software. If you won’t use it, why would anyone else?