BT

Book Review Understanding Software by Max Kanat-Alexander

| by Roland Meertens Follow 7 Followers on Oct 27, 2017. Estimated reading time: 3 minutes |

The book "Understanding Software" by Max Kanat-Alexander is an interesting read for project managers and software architects. It provides insights in how to keep your software simple, and how you can avoid complex unmaintainable software.

Kanat-Alexander is the blogger of www.codesimplicity.com. He wrote his first book, called Code Simplicity, in 2012. Since that year he wrote a lot of additional blog posts, and bundled some of them, together with additional stories, in this book. If you want to get a feel for the writing style, you should take a look at the website http://www.codesimplicity.com. Most of the content in the book is available on the website. The chapters in the book read like the blog posts, but they are edited and curated to better fit the medium of a book.

The book comprises 43 chapters. Reading a chapter will only take you several minutes, which makes it a great book to read on your daily commute. You can read each chapter independent of others, so it's easy to abandon the book for a while and pick it up whenever you face a problem. The chapters are divided into seven parts. Personally, I think splitting it into four sections better fits the content of these sections, and I will discuss it this way in the rest of this review.

The first section (part 1,2,3 and 4) comprises of tips for becoming a good programmer. It tells you what attitude you need to have, and what you need to do to be good at programming. You get a feeling for what code complexity actually means, and how you can create complex programs. The book continues on to discuss what a bug is, how you can solve it, and where they could come from.

The second section (part 5) discusses engineering in teams. This section is useful for people who have to deal with a team of software engineers. It discusses metrics you can use to measure engineering productivity, and how you can find what is blocking the productivity of your team. What I liked best about this part of the book is the human-centered approach to removing these blockers. Although it would be easy to only give tips on tools that increase productivity, Kanat-Alexander discusses how you can increase your productivity by discussing these tools with your team. Not only does he share his experiences working in a company, but he also discusses his experience working in the open source community. If you are interested in growing and maintaining an active community for your open source project the tips in this book will certainly help you.

The third section (part 6) discusses the purpose of software, and how to build it. What I liked to read were the sections on test-driven development. The cycle of observation is great for looking at a development process. In the last chapter of this section, Kanat-Alexander discusses the philosophy of testing, and how you should approach it.

The last section (part 7) focuses on practitioning software engineers. Interesting is the "avoid bad programming" approach Kanat-Alexander takes. He mostly talks about what ideas are bad, what you should NOT implement, and in what ways you could lose grip on your software. Although these principles will give software engineers a better feeling on how to approach their software problems, code samples or architecture diagrams are things I missed in this chapter. Although I had a lot of good insights in how to avoid bad software, I am still missing some kind of grip or guidelines to make my software fantastic.

Conclusion

All in all, I think the book is most useful for project managers and architects. The parts that describe engineering in teams, and how to handle code complexity in a software company, will inspire you to tackle complexity in your own projects. The book provides the high-level overview on how to build better software, and how to help others build better software. I expect that software engineers reading the book will mostly get a feeling on how to code better, but that the book lacks the necessary actionable details for them to actually improve their code.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT