paint-brush
Top 4 Classic Software Development Booksby@scottmiddleton
994 reads
994 reads

Top 4 Classic Software Development Books

by Scott MiddletonSeptember 22nd, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Scott Middleton is the CEO and founder of Terem, Australia’s leading tech product development firm. He has compiled a list of classic books on the fundamentals of software development. These books have provided the foundations and first principles to approach software development, and later, product development. The Goal's most enduring point for me is the identification of bottlenecks (constraints) and seeking to remove them. The Mythical Man-Month by Frederick Brooks is most famous for highlighting that adding more people to software projects doesn’t always increase output.

Company Mentioned

Mention Thumbnail
featured image - Top 4 Classic Software Development Books
Scott Middleton HackerNoon profile picture

Much of modern problems in software development have actually been solved and we keep forgetting this to our peril. Every day something pops up in a conversation, on one of our teams or on socials that can be addressed by a book from years and sometimes decades ago. 

I think of these as classic books on the fundamentals of software development. These books have provided the foundations and first principles to approach software development, and later, product development.

It’s challenging to debate the merits of SAFe (Scaled Agile Framework), for example, without having an understanding of the fundamentals.

Let’s get into the books in no particular order.

This list is focused on the management/approach more so than programming. 

1. The Goal

The Goal’s most enduring point for me is the identification of bottlenecks (constraints) and seeking to remove them. The Goal, written by Eliyahu M. Goldratt, makes this point through a fictitious story about a plant manager who is struggling with production at his plant. He tries a variety of methods to improve output but just seems to be throwing money away until he sees that one machine, in particular, is slowing the process down.

2. The Mythical Man-Month

Published back in 1975 by Frederick Brooks, this book is most famous for highlighting that adding more people to software projects doesn’t always increase output, but it also provides foundational thinking in other areas like goal setting, testing and managing complexity. 

The book also includes an essay about how there is no silver bullet for improving productivity (that’s right, implementing SAFe won’t suddenly make everything better).

I’ve seen some comments about the lack of acknowledgement of females (it uses “man” “him” etc rather than “her”, “women” or “people”). You’ll need to acknowledge the date it was published and look past this.

3. Making Things Happen 

Making Things Happen is a collection of practical essays from an ex-Microsoft project management veteran. 

I remember this book for practical insights into effective software project management. Yes, it might be pre-agile and mention that now dirty word “project”, but the insights still apply to anyone leading an initiative in software. 

The author, Scott Berkun, shares hard-won lessons on planning, scheduling, slippages, goals, understanding your scope and more. He also covers working with stakeholders and tension between customer needs, technical requirements and business drivers (you can see how this isn’t a new problem).

4. Zen and the Art of Motorcycle Maintenance

This book uses the fictitious tale of a motorcycle journey to develop a philosophy on what defines “good” or “quality”. 

Written by Robert Maynard Pirsig, the main takeaway it has left me with is the need to lift the covers on any topic or situation and understand the inner workings on that topic. It is similar to reasoning from first principles (Elon Musk and Charlie Munger are big fans). 

When it comes to situations on software teams and products, it is often digging into the fundamentals that help you move it forward.

Coincidentally, the philosopher that wrote it had a day job writing computer manuals.