Ask HN: Best books on managing software complexity?

They had a project in planning for 18 months but hadn't been able to start it. I was hired as a principal and given this one of my major impacts to deliver, though other things kept getting piled on in front of it. To actually get it done one weekend I sat down and cranked out a functioning POC that could easily and rapidly be extend into the fully working system.

Come Monday they were blown away to see the major progress of an actual working system, and loved the system and were very happy about it. Then the bike-shedding began, an order of magnitude more person hours was spent talking about it than it took me to build it and they required rewriting it because they a data library I used 'old tech and uncool'..

Hilariously that data library was actually a DDD system that created bounded contexts and enforced a domain model in them, but due to their lack of understanding they didn't see that! The hilarious irony!

I wasn't a DDD guy, though having been a high level architect for 15 years I was using all the things I have found that worked best. Some time later I was reading about DDD and realised that system was actually DDD. Of course by that time I had already left, to deliver working systems instead of waste time bike-shedding with cargo culters!

Same with a search for a to-do app I was looking for. Until I was thinking my file explorer was already great at filing, so I just add txt files and so on to order my projects. Naming is key if you want it to work well though.

I use Joplin for some more complex things, like keeping track of certain project features and progress.

Automation is great when it replaces a stable, well-working manual process.

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.

Try not to handle edge cases in the software, but try to remove them from the greater system in which they occur.

Automate by elimination, not by complexity.

Good books in this vein would be anything with Taiichi Ohno in the title, or, perhaps better, as the author.

There were some things that I did find reason to take notes on, such as:

- Each area of responsibility should have a team dedicated to it, even if some teams end up having zero people in them, and sometimes members from other teams have to rotate into that function. I liked this because I know how easy it is to forget that some functions are understaffed if you squeeze them in with other functions.

- If you want to improve how the larger organisation works, run the improvement as an experiment in your team and then publish a very brief report on the results along with instructions for how other teams can try it. I liked this because I've often done the first part, but I've often forgotten the publishing part.

- A leader is asked to decide a million things a day. Your job is not the make those decisions, your job is to figure out a system in which the decision is not needed, or the right decision is clear for anyone to see, and then help others participate in that system. I knew this from before, but it bears repeating because it's so easy to forget in the heat of decision-making.

(The last point has a more general corollary: your job is never to do what you were hired for, it's to teach others how to do what you were hired for.)