Ask HN: Best books on managing software complexity?

I enjoyed &quot;A philosophy of software design&quot; by John K Ousterhout <a href="https:&#x2F;&#x2F;www.worldcat.org&#x2F;title&#x2F;philosophy-of-software-design&#x2F;oclc&#x2F;1274059436" rel="nofollow">https:&#x2F;&#x2F;www.worldcat.org&#x2F;title&#x2F;philosophy-of-software-design...</a> just be forewarned that at 180 pages, it&#x27;s a lot more aspirational than instructive. It depends on what kind of organizational problem you&#x27;re having: lack of experience, lack of interest, lack of discipline, lack of buy-in, or $other

The least complex software is the one never built. We often over-automate. Automation is brittle and inflexible and easily ends up lined with edge cases and other types o complexity.<p>Automation is great when it replaces a stable, well-working manual process.<p>The way to introduce automation is to first experiment with humans doing something manually until you have a great process. Then take the dumbest, most reliable part of that and turn it into a computer program that alerts a human if it encounters an edge case.<p>Try not to handle edge cases in the software, but try to remove them from the greater system in which they occur.<p>Automate by elimination, not by complexity.<p>Good books in this vein would be anything with Taiichi Ohno in the title, or, perhaps better, as the author.

I feel like a broken record for the amount of comments I&#x27;ve posted related to Deming and lean product development these past few days, but as Taiichi Ohno says, the biggest waste is overproduction.<p>A lot of the things we build into our software is complexity nobody really needs. One way of managing it is by never making it in the first place. This takes at least two things:<p>- Thorough discussion with the customer about what problem they <i>really</i> are trying to solve. They will come to you with what they think is the solution. That way leads unnecessary complexity.<p>- Rough economical analysis of choices. Often we do things because that&#x27;s what one ought to do. Make a quick napkin calculations. A lot of the things one ought to do are not actually necessary.<p>There are way too many books to recommend here, but perhaps some of the most relevant are<p>- Deming&#x27;s The New Economics, and Out of the Crisis,<p>- Reinertsen&#x27;s Principles of Product Development Flow,<p>- Ward&#x27;s Lean Product and Process Development.

OP here. Thank you for all of the great suggestions! I&#x27;ve compiled all the references into this spreadsheet: &lt;<a href="https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1kgFSWp7rM3ZegweXAoMN-4Hv88sNS--xUuDnHp6IftQ&#x2F;edit" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1kgFSWp7rM3ZegweXAoMN...</a>&gt;<p>From my perspective, the top &quot;must-reads&quot; are:<p>-- John K Ousterhout, <i>A Philosophy of Software Design</i><p>-- Titus Winter (et al), <i>Software Engineering at Google</i><p>-- Hanson and Sussman, <i>Software Design for Flexibility</i><p>Other interesting titles that caught my eye:<p>-- Peter Naur, <i>Programming as Theory Building</i><p>-- Scott Wlaschin, <i>Domain Modeling Made Functional</i><p>-- Yehonathan Sharvit, <i>Data-Oriented Programming: Unlearning objects</i> (upcoming)<p>-- Nick Tune, <i>Patterns, Principles, and Practises of Domain Driven Design</i><p>-- Robert L. Glass, <i>Facts and Fallacies of Software Engineering</i><p>-- Donald Reinertsen, <i>The Principles of Product development Flow</i><p>-- Eric Normand, <i>Grokking Simplicity</i>

“Software Engineering at Google” has been eye opening for me. It hits what you are looking for in its first chapter and then goes into details of different aspects in later chapters.<p><a href="https:&#x2F;&#x2F;abseil.io&#x2F;resources&#x2F;swe-book" rel="nofollow">https:&#x2F;&#x2F;abseil.io&#x2F;resources&#x2F;swe-book</a>

I agree with much of what&#x27;s already said here.<p>1. Figure out the difference between your inherent and accidental complexity. The Cynefin framework can be a useful way of thinking about what types of complexity you have.<p>2. Attempt to reduce (or remove) the complexity at root before assuming you must model it. &quot;The biggest tragedy in business is doing well that which should not be done at all.&quot; For example, we had an important user still on a legacy browser because they couldn&#x27;t afford to upgrade their old laptop. Instead of adding a complicated legacy layer, we bought them a new laptop.<p>3. Think of the whole system, rather than just shifting the burden somewhere else within the system. This is why microservice architectures so often fail - engineers think they&#x27;ve reduced complexity because each service is so simple. Yet all they&#x27;ve done is move the complexity into the operational layer, where it&#x27;s harder to deal with. Gerald Weinberg is a fun writer in this space.<p>4. In many organisations, a lot of people&#x27;s salaries depend on their ability to add complexity, especially to processes but also to code. If you are working within such an organisation, you will have a Sysiphian task until you solve the organisational problem. Whether you can solve this problem depends on how much influence you have. This is why &quot;skunkworks&quot; projects so often work until they are re-integrated into the mainstream.<p>5. Once you&#x27;ve sorted out the organisational complexity, separated the inherent and accidental complexity, you&#x27;ll be most of the way there. Keep reviewing and challenging everything. Complexity is a weed that just seems to grow unless you constantly tend to the garden.

A philosophy of software design by John Ousterhout <a href="https:&#x2F;&#x2F;smile.amazon.com&#x2F;dp&#x2F;1732102201&#x2F;ref=cm_sw_r_apan_glt_i_WR2F47J0SEXNEPJNE0BZ" rel="nofollow">https:&#x2F;&#x2F;smile.amazon.com&#x2F;dp&#x2F;1732102201&#x2F;ref=cm_sw_r_apan_glt_...</a><p>The entire focus of the book is reducing complexity.

This might seem more basic&#x2F;beginner level but I really have enjoyed working through How To Design Programs. [1] It teaches you how to think about data, types, abstraction, and creating mini languages&#x2F;sets of functions for robust, adjustable, and maintainable code. It&#x27;s helped me immensely as I&#x27;ve started to build much more complicated stuff. It&#x27;s amazing how you can follow the design recipies, break problems into parts, plug functions together, everything just works. Applying these principles in a typed language (TypeScript) has massively improved my ability to much more complex stuff that is also more safe and maintainable.<p>[1]: <a href="https:&#x2F;&#x2F;htdp.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htdp.org&#x2F;</a>

Peter Naur&#x27;s &quot;Programming as Theory Building&quot; is a classic essay, and absolutely worth reading. This transcription [1] (with some extra remarks at the end by the transcriptor?) is pretty accessible.<p>[1] <a href="https:&#x2F;&#x2F;pablo.rauzy.name&#x2F;dev&#x2F;naur1985programming.pdf" rel="nofollow">https:&#x2F;&#x2F;pablo.rauzy.name&#x2F;dev&#x2F;naur1985programming.pdf</a>

At an organizational level, Donald Reinertsen &quot;the principles of product development flow&quot; is outstanding.<p><a href="https:&#x2F;&#x2F;books.google.de&#x2F;books&#x2F;about&#x2F;The_Principles_of_Product_Development_Fl.html?id=1HlPPgAACAAJ&amp;source=kp_book_description&amp;redir_esc=y" rel="nofollow">https:&#x2F;&#x2F;books.google.de&#x2F;books&#x2F;about&#x2F;The_Principles_of_Produc...</a><p>It motivates small batch sizes, decision making at ground level, short cycle times, all the mechanics behind kanban, scrum, XP, without ever using any of their jargon.<p>And it moves up into economics by explaining e.g. cost of delay as a metric guiding useful decision making.<p>The book eatablishes a wonderful shared understanding of the principles underlying lean and agile, why they work and how to make them work, shared understanding between engineering and management.

Yet to experience proper work life, but really enjoyed Brook&#x27;s <i>The Mythical Man-Month</i>

Architectural perspective:<p>Clean Architecture: A Craftsman’s Guide to Software Structure and Design <a href="https:&#x2F;&#x2F;www.oreilly.com&#x2F;library&#x2F;view&#x2F;clean-architecture-a&#x2F;9780134494272&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.oreilly.com&#x2F;library&#x2F;view&#x2F;clean-architecture-a&#x2F;97...</a><p>Organizational perspective:<p>An Elegant Puzzle: Systems of Engineering Management by Will Larson <a href="https:&#x2F;&#x2F;press.stripe.com&#x2F;an-elegant-puzzle" rel="nofollow">https:&#x2F;&#x2F;press.stripe.com&#x2F;an-elegant-puzzle</a>

Written by the authors of sicp: <a href="https:&#x2F;&#x2F;mitpress.mit.edu&#x2F;books&#x2F;software-design-flexibility" rel="nofollow">https:&#x2F;&#x2F;mitpress.mit.edu&#x2F;books&#x2F;software-design-flexibility</a><p>Organization is just a name for a group of methodologies. Ultimately what we want is the right way to organize programs for maximum flexibility.

Out of the tar pit is the best paper on this I’ve ever read: <a href="http:&#x2F;&#x2F;curtclifton.net&#x2F;papers&#x2F;MoseleyMarks06a.pdf" rel="nofollow">http:&#x2F;&#x2F;curtclifton.net&#x2F;papers&#x2F;MoseleyMarks06a.pdf</a>

I think it is worthwhile to first look into the fields of <i>Complexity Science&#x2F;Complex Systems Science</i> and <i>Systems Thinking&#x2F;Systems Theory</i> for overarching insights : [ <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Complex_system" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Complex_system</a> and <a href="https:&#x2F;&#x2F;complexityexplained.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;complexityexplained.github.io&#x2F;</a> ] and [ <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Systems_thinking" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Systems_thinking</a> and <a href="https:&#x2F;&#x2F;thesystemsthinker.com&#x2F;systems-thinking-what-why-when-where-and-how&#x2F;" rel="nofollow">https:&#x2F;&#x2F;thesystemsthinker.com&#x2F;systems-thinking-what-why-when...</a> ]<p>For Software specific issues i highly recommend David Parnas&#x27; collected papers in the book <i>Software Fundamentals.</i> He and his colleagues <i>defined</i> much of what is mainstream in today&#x27;s Software Architecture&#x2F;Organization practice.<p>Finally, the case studies given here are a great source of insights: <a href="https:&#x2F;&#x2F;aosabook.org&#x2F;en&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;aosabook.org&#x2F;en&#x2F;index.html</a>

These are more architecture focused but maybe relevant.<p>The Phoenix Project. The DevOps Handbook. The Google SRE Book. And “Kill It With Fire.”

I’ve been liking Grokking Simplicity so far. It starts out by separating code into three parts: data, computations, side-effects.<p>You want to minimize side-effects, preferring computations over them, and data over computations.<p>I’m still early into it, however, this already has been a helpful lens to view my code through.<p><a href="https:&#x2F;&#x2F;www.manning.com&#x2F;books&#x2F;grokking-simplicity" rel="nofollow">https:&#x2F;&#x2F;www.manning.com&#x2F;books&#x2F;grokking-simplicity</a>

I found this one very good: A Philosophy of Software Design<p><a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;dp&#x2F;173210221X" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;dp&#x2F;173210221X</a>

Michael Feather&#x27;s book on legacy code contains a lot of advice that ought to be obvious, and yet every time I&#x27;m handed a scary piece of complex legacy software, I leaf through Feather&#x27;s book and I almost always find something useful.

The Pragmatic Programmer<p><a href="https:&#x2F;&#x2F;www.amazon.co.uk&#x2F;Pragmatic-Programmer-Andrew-Hunt&#x2F;dp&#x2F;020161622X" rel="nofollow">https:&#x2F;&#x2F;www.amazon.co.uk&#x2F;Pragmatic-Programmer-Andrew-Hunt&#x2F;dp...</a>

Domain Driven Design by Eric Evans

&quot;Large-Scale C++ Volume I: Process and Architecture&quot; by John Lakos

Domain Modeling Made Functional - Scott Wlaschin

Not a book, but this paper “big ball of mud” has resonated with me in describing troubles I’ve faced before, and has me coming back to it as I run into new architectural problems where I’m not confident in my&#x2F;our approach.<p><a href="http:&#x2F;&#x2F;www.laputan.org&#x2F;mud&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.laputan.org&#x2F;mud&#x2F;</a>

The &quot;original&quot; Scrum book <a href="https:&#x2F;&#x2F;read.amazon.com&#x2F;kp&#x2F;card?asin=0130676349Q&amp;preview=inline&amp;linkCode=kpe&amp;ref_=dbs_a_def_rwt_bibl_vppi_i2" rel="nofollow">https:&#x2F;&#x2F;read.amazon.com&#x2F;kp&#x2F;card?asin=0130676349Q&amp;preview=inl...</a><p>Stuff on lean manufacturing (yes. manufacturing!) <a href="https:&#x2F;&#x2F;www.amazon.de&#x2F;dp&#x2F;B000SEGIVS?ref_=cm_sw_r_kb_dp_ocvTDbQPS1EGA&amp;tag=kp0508-21&amp;linkCode=kpe" rel="nofollow">https:&#x2F;&#x2F;www.amazon.de&#x2F;dp&#x2F;B000SEGIVS?ref_=cm_sw_r_kb_dp_ocvTD...</a><p><a href="https:&#x2F;&#x2F;www.amazon.de&#x2F;dp&#x2F;B002LHRM2O?ref_=cm_sw_r_kb_dp_I9SSDb704MDTV&amp;tag=kp0508-21&amp;linkCode=kpe" rel="nofollow">https:&#x2F;&#x2F;www.amazon.de&#x2F;dp&#x2F;B002LHRM2O?ref_=cm_sw_r_kb_dp_I9SSD...</a>

This is a book that focuses on managing software complexity and to &quot;avoid painting oneself into a corner&quot;:<p><a href="https:&#x2F;&#x2F;mitpress.mit.edu&#x2F;books&#x2F;software-design-flexibility" rel="nofollow">https:&#x2F;&#x2F;mitpress.mit.edu&#x2F;books&#x2F;software-design-flexibility</a>

- Philosophy of Software Design (great short read packed with insight)<p>- Mythical Man-Month (the classic, a little outdated but the principles still ring very true)<p>- Software Engineering at Google (thoughts from a company that has spent a lot of time thinking about this at scale)

<a href="https:&#x2F;&#x2F;link.springer.com&#x2F;chapter&#x2F;10.1007&#x2F;978-981-15-5856-6_7" rel="nofollow">https:&#x2F;&#x2F;link.springer.com&#x2F;chapter&#x2F;10.1007&#x2F;978-981-15-5856-6_...</a> Has a bunch of useful references. Olivier de Weck of the MIT held an awesome conference speech at the 2016 MIT SDM Conference explaining sources, metrics and cost of organizational complexity linked to engineering complexity. Sadly, the video no longer appears online. But the work of him and his group (references in the article above) is highly relevant to your question.

I haven&#x27;t read any of the books on architecture recommended in this thread, but I learned how to manage software complexity by:<p>1. Counter-intuitively, being deeply interested and reading about a topic in natural science. Software is complex because it is a system, and especially if you&#x27;re using a programming language with plenty of OOP features, you&#x27;re going to benefit a lot from understanding how nature separates properties and functions into organic matter, how they work in concert to achieve a particular effect, and how they compose each other to scale up from the atomic to the cosmic scale; or<p>2. If you can&#x27;t be bothered to learn about topics beyond programming itself, then practice unit testing. As a matter fact, attempt to write unit tests for your old code. If you can&#x27;t make the unit test run, then that&#x27;s life slapping you in the face to tell you that your code is way too tightly-coupled.<p>By the end of the day, doing any of the above things (but more so, both!) will teach you the true essence of KISS.

Bob Martins stuff is good, like Clean Architecture <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Clean-Architecture-Craftsmans-Software-Structure&#x2F;dp&#x2F;0134494164" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Clean-Architecture-Craftsmans-Softwar...</a><p><a href="https:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2012&#x2F;08&#x2F;13&#x2F;the-clean-architecture.html" rel="nofollow">https:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2012&#x2F;08&#x2F;13&#x2F;the-clean-a...</a>

Surprised nobody have mentioned Making software, <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Making-Software-Really-Works-Believe&#x2F;dp&#x2F;0596808321" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Making-Software-Really-Works-Believe&#x2F;...</a><p>It takes a empirical view on the software process. Does writing tests first help you develop better code faster? Can code metrics predict the number of bugs in a piece of software? Do design patterns actually make better software?

First keep it simple, shameless self plug: <a href="https:&#x2F;&#x2F;www.radicalsimpli.city&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.radicalsimpli.city&#x2F;</a>

Michael C. Feathers - Working Effectively with Legacy Code<p>Scott Wlaschin - Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Do you want to find out about managing a bad case of complexity in an existing project? Or are you searching for ways to avoid getting into a bad place with sw complexity and looking for even radical simplicity because you are determinde to avoid (or can&#x27;t afford) complexity?<p>These are quite different missions since it&#x27;s rarely possible to recover form complexity if you&#x27;ve already gone there.

For me it&#x27;s Design Patterns: Elements of Reusable Object-Oriented Software<p>The essay in the the beginning of the book gave me a profound epiphany back then.

As a baseline on what is know and not know about managing software projects, I always recommend Robert L. Glass <i>Facts and Fallacies of Software Engineering</i>.<p>More speculatively, I think that the following biology readings are inspiring:<p>- Gerald Jay Sussman, <i>Building Robust Systems an essay</i>. In general, biology should be a source of inspiration for engineers.<p>- E. Goldratt, <i>The Goal</i>

Software complexity is often made worse by organisational complexity. Someone put it as &quot;make sure people do complex jobs in simple organisations rather than the other way around.<p>David Marquet&#x27;s books have been surprisingly helpful to me in shaping simpler organisations, starting, of course, with Turn the Ship Around.

I suggest looking into: <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Righting-Software-Juval-L%C3%B6wy&#x2F;dp&#x2F;0136524036" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Righting-Software-Juval-L%C3%B6wy&#x2F;dp&#x2F;...</a><p>It&#x27;s very unorthodox, but cuts through a lot of the bullshit.

I touch on both these perspectives in my book ‘Risk-First Software Development’. You can read all it online at <a href="https:&#x2F;&#x2F;riskfirst.org" rel="nofollow">https:&#x2F;&#x2F;riskfirst.org</a> if you want.<p>Hope this is useful to you.

At least from where I&#x27;m at (ex-SWE, quit at a relatively junior level), I&#x27;m not sure this is something you can read about and reason logically. It&#x27;s something you need to a feel for through experience.

It&#x27;s a long shot, but is anyone aware of useful MOOCs that cover this topic?

Grady Booch “OO Analysis &amp; Design”<p>Classics

Best book is task description how to add small feature to your project. If it’s still clear and easy, then you don’t need to read any books about software complexity management ).

Object Thinking by David West