These are some of the books that I recommend on the topic of building software. The links are Amazon affiliate links.
The best treatment of Lean principles (especially the concept of "waste") that I have read. Required reading for anyone studying Lean, in my opinion.
I read this after already having studied and practiced Lean for some time and it seemed like the best treatment of the essential plan-do-check-act loop I'd read so far. Many of the examples it uses are from factories, but the problem solving techniques are universal.
One of the quintessential books on Lean Manufacturing. Not everything is directly applicable to software, but the principles and philosophy behind them are.
Checklists, both recurring and one-off are an important part of ensuring that things get done correctly and things do not get missed.
This does a good job of speaking to a very similar technique as the Toyota Kata book while using examples from multiple other industries. It also touches on queueing theory and hand offs in its own way. It's quite approachable.
Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor and Lead
This book is written from the perspective of a manager and their report and walks through the process of learning to problem solve by writing an A3 report, getting feedback, being asked questions about it, and refining it over time. It's an easy read and will help to clarify the analysis and problem solving process for more complicated problems. I think it takes place in a factory, but again, the techniques are just as applicable everywhere.
This book focuses on "The Theory of Constraints" which we could say is a cousin of Lean. It's a fairly simple premise that is slightly more difficult to recognize how to put into practice in non-factory processes. I like it because it reinforces what the primary goal of a business is (making money) and it introduces the notion of bottlenecks and how to deal with them. Be warned that bottlenecks are a tricky thing and it can be tempting to see them where they don't exist.
This is the best book on queuing theory and other "common sense" principles about product development that apply to many other things that I know of. It gets more complex (more math) as it progresses, and I only tend to recommend reading up to Chapter 6. It's dense. It doesn't tell you how to do things, but it lays out a set of fundamental principles. For example, we schedule a daily meeting with two people that can do "final inspection" of the work that we do. It's a 30 minute time block so that it is reserved on their calendar. That way we know it will take at most 1 day before we can get something inspected (approval, release to production). This is the notion of scheduling on a "cadence", rather than just-in-time which this book talks about. Again, "common sense", but as we know, common sense is anything but common.
A very good treatment on management by ensuring that those being managed have autonomy and accountability. The "I intend to..." practice detailed in the book has been especially effective on our team and is very powerful in its own right.
I believe this book is still overly influenced by Scrum and "Kanban", but there is much in it that is thought provoking and useful. Consider it a mid-point between big-A Agile and Lean.
Great advice on software design. The author does not speak much about using tests to guide and give you feedback on your design, which I think is missing from this book. Keep that in mind while reading it.
The seminal book on Test Driven Development (TDD). Strongly recommended if you do not already know how to do TDD.
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
Excellent treatment of database and other data storage and communication mechanisms. The end of the book starts to describe event-sourced autonomous components what the author believes is the ultimate goal, at least as far as we can see. I tend to agree.
The partitioning of front end applications requires special techniques in order to ensure that user experience does not suffer. This book greatly influenced the way that we build our applications. In particular the use of Server-Side-Includes (SSI) has been an excellent tool for separating our web applications into separately developed and deployed applications.
This book was written in the 1970s, so the programming languages used in its examples are not likely to be familiar. However, this book contains much of the foundational work for software development principles like SOLID, the importance of heeding cohesion and coupling, etc. In particular, the chapters on cohesion and coupling are quite good. It's a somewhat challenging academic read. It is out of print, so I bought my copy on eBay.
Most of the book is solid, practical advice for software developers.
Practical guidance on user interaction design. The examples no longer match the aesthetics we are accustomed to, but the principles and guidance is just as applicable as it has always been.
This book is not about software, but it speaks to the more universal principles of design. Those principles are applicable to software. This book is where people first encountered (and subsequently, started misusing) the term "affordance".
Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience
Guidance for communicating with stakeholders and other people that do not share the same skill or fundamentals in design.
[Comments](https://github.com/aaronjensen/software-development/discussions/[Discussion ID])
Subscribe to be notified of new articles
Copyright Aaron Jensen 2024-present