Ask HN: Best books on managing software complexity?

I haven't read any of the books on architecture recommended in this thread, but I learned how to manage software complexity by:

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're using a programming language with plenty of OOP features, you'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

2. If you can'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't make the unit test run, then that's life slapping you in the face to tell you that your code is way too tightly-coupled.

By the end of the day, doing any of the above things (but more so, both!) will teach you the true essence of KISS.

I found DDD very poorly written. It's a nightmare slog to read. I find Evans isn't a gifted writer and thinks unedited rambling is appropriate for a textbook. The 600 pages could easily have been 100. DDD can also be a poison to core systems, and Evans never considers this (I don't think he knows it). If you try to encode business domains, service lines, product names, stakeholder role names, what have you, into your core software, now you can't iterate on the business, because it requires refactoring the core. Building generic platforms with minimal "domain" (whatever that term means, Evans can't even define it) concerns in it, and keeping the business logic as far in user configuration land as possible, gives a business more flexibility and a better chance at surviving.

I feel like a broken record for the amount of comments I've posted related to Deming and lean product development these past few days, but as Taiichi Ohno says, the biggest waste is overproduction.

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:

- Thorough discussion with the customer about what problem they really are trying to solve. They will come to you with what they think is the solution. That way leads unnecessary complexity.

- Rough economical analysis of choices. Often we do things because that's what one ought to do. Make a quick napkin calculations. A lot of the things one ought to do are not actually necessary.

There are way too many books to recommend here, but perhaps some of the most relevant are

- Deming's The New Economics, and Out of the Crisis,

- Reinertsen's Principles of Product Development Flow,

- Ward's Lean Product and Process Development.

I don’t believe that Evans was arguing for pulling every concern in the wider system into a single model (the last third of the book gives techniques for overall system architecture). Different service lines, or products, would surely belong in distinct bounded contexts in DDD.

> keeping the business logic as far in user configuration land as possible

This sounds dreadfully difficult to build and test. The kind of business rules engine that you’re describing is more likely to be overpriced and buggy than a simpler well-modeled set of core domain classes imo.

Not every piece of software should be excel.

Re: An Elegant Puzzle: If you remember, could you please write a bit about the key insights from it?