Live data from Hacker News

Ask HN: Best books on managing software complexity?

news.ycombinator.com

101–110 of 127 posts

Re: Ask HN: Best books on managing software complexity?

#101
post #15

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 abo…

has anyone also included a post deploy trim phase ? even through long discussions, the client's business might be affected by the new tool in ways that may make him reevaluate workflows or distribution of work, which mean potentially reshaping the code and maybe removing more stuff.

The way I usually do it is any time I'm asked to fix bugs, make changes, or do other maintenance I first try to find out if the affected functionality is still relevant, or if the easiest fix is to throw it out.

Re: Ask HN: Best books on managing software complexity?

#102
post #96
post #33

Out of the tar pit is the best paper on this I’ve ever read: http://curtclifton.net/papers/MoseleyMarks06a.pdf

This paper revolutionized my perspective on software engineering and ultimately how our company does business. If you want to skip to the good part, Chapter 9 is where you want to be. We were able to create a hybrid FRP system that uses SQLite & application-defined functions as the sandbox within which all of this hypothetical functional/relational business occurs. This is in production for several of our customers r…

Actually I think chapters 1–8 are more valuable than the chapters dealing with a concrete implementation because they teach you ideas and principles

Re: Ask HN: Best books on managing software complexity?

#103
post #27

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. 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…

This has nothing to do with the question, why are you going off on a tangent about philosophy of automation?

Re: Ask HN: Best books on managing software complexity?

#105
post #27

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. 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…

This has nothing to do with the question, why are you going off on a tangent about philosophy of automation?

Software is automation. By relying less on automation, your software is less complex. That's a way to manage software complexity organisationally.

Re: Ask HN: Best books on managing software complexity?

#107
post #7

I enjoyed "A philosophy of software design" by John K Ousterhout https://www.worldcat.org/title/philosophy-of-software-design... just be forewarned that at 180 pages, it's a lot more aspirational than instructive. It depends on what kind of organizational problem you're having: lack of experience, lack of interest, lack of discipline, lack of buy-in, or $other

I also recommend this book.

It's refreshing that they take a first principles approach in managing complexity.

Re: Ask HN: Best books on managing software complexity?

#108
OP here. Thank you for all of the great suggestions! I've compiled all the references into this spreadsheet: https://docs.google.com/spreadsheets/d/1kgFSWp7rM3ZegweXAoMN...>

From my perspective, the top "must-reads" are:

-- John K Ousterhout, A Philosophy of Software Design

-- Titus Winter (et al), Software Engineering at Google

-- Hanson and Sussman, Software Design for Flexibility

Other interesting titles that caught my eye:

-- Peter Naur, Programming as Theory Building

-- Scott Wlaschin, Domain Modeling Made Functional

-- Yehonathan Sharvit, Data-Oriented Programming: Unlearning objects (upcoming)

-- Nick Tune, Patterns, Principles, and Practises of Domain Driven Design

-- Robert L. Glass, Facts and Fallacies of Software Engineering

-- Donald Reinertsen, The Principles of Product development Flow

-- Eric Normand, Grokking Simplicity

Re: Ask HN: Best books on managing software complexity?

#109
post #105

Earlier quoted context omitted.

This has nothing to do with the question, why are you going off on a tangent about philosophy of automation?

Software is automation. By relying less on automation, your software is less complex. That's a way to manage software complexity organisationally.

This is like someone asking how to build a simpler house and your answer is to tell them to live in the woods.

If someone is trying to design a better plane, it doesn't make sense to tell them to just convince everyone asking for a better plane to stop traveling. It is nonsense and seems like you have unrelated ideas that you are trying to shoehorn into this question.

Re: Ask HN: Best books on managing software complexity?

#110
post #34

I agree with much of what's already said here. 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. 2. Attempt to reduce (or remove) the complexity at root before assuming you must model it. "The biggest tragedy in business is doing well that which should not be done at all." For example, we had an…

> For example, we had an important user still on a legacy browser because they couldn't afford to upgrade their old laptop. Instead of adding a complicated legacy layer, we bought them a new laptop.

I'm curious about the specifics regarding the combination of "important user" and "couldn't afford to upgrade".

Was the user's importance social rather than financial? Were the hardware requirements particularly hefty?

Post reply on HN