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.
Ask HN: Best books on managing software complexity?
101–110 of 127 posts
Re: Ask HN: Best books on managing software complexity?
#102Out 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…
Re: Ask HN: Best books on managing software complexity?
#103The 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…
Re: Ask HN: Best books on managing software complexity?
#104Re: Ask HN: Best books on managing software complexity?
#105The 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?
#106Out of the tar pit is the best paper on this I’ve ever read: http://curtclifton.net/papers/MoseleyMarks06a.pdf
I would add Frederick Brooks' No Silver Bullet alongside this for better understanding.
Re: Ask HN: Best books on managing software complexity?
#107I 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
It's refreshing that they take a first principles approach in managing complexity.
Re: Ask HN: Best books on managing software complexity?
#108From 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?
#109Earlier 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.
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?
#110I 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…
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?