5 ms·

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 oth

by kqr 5y ago

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

extheat 5y ago
Conversely, automation creates a clear and well defined workflow for completing a task. There is nothing to "automate" if there is not already a manual process to doing it. Sure, sometimes the automation you introduce can be an over-engineered solution that's more difficult to maintain (or just not work) compared to a human-done manual process. To that point I think a valid solution would be to make the process itself more automation friendly, if possible given your circumstances.
- kqr 5y ago
  Yes. This is what Taiichi Ohno would call "standard work": well-defined processes intended to be executed literally, and evolved with and by the people who perform the execution. Standard work is a great source of things to automate, but automation is not a replacement for it.
majkinetor 5y ago
> Automation is brittle and inflexible Wait what ? Mine automation works for years without an issue. Flaky automation is meaningless. > that alerts a human if it encounters an edge case. No. It shouldn't alert anybody almost never if it's good. When you have 300 automation routines, even if it alerts once a year you will have some alert every day. So it needs to alert lower then that, when the world falls out or something...
- kqr 5y ago
  Yes, you can spend a lot of time and complexity on truly robust automation. But it's not always the most ROI move economically. Especially not in highly volatile businesses where your processes may need to change rapidly.
  - majkinetor 5y ago
    You didn't calculate ROI right. If YOU are the one that does intervention, then your time is lost constantly doing manual fixing of failed scripts. Not to mention reputation loss, end user dissatisfaction etc. Automation routines MUST be robust, must handle all weird cases that happen frequently (at least once a year), and must notify when they fail to do so always. Then you should come back and see how to not make them fail even then.
    - kqr 5y ago
      I think you are incorrect on both accounts. It's easy to spend upward of $10000 on really robust automation, when the same manual process would cost only $3000 over its usable lifetime, and the economical-but-less-robust automation costs $1000 over the same period. The robust automation, in that case, has over 10× worse ROI. What's wrong with that calculation? The thing about really robust automation is that for it to pay off, the process have to be static over a large number of executions. For many business needs, the process, or its inputs, change every few executions, and you never get to reap the benefits of robust automation before it needs to be redone at great expense. As for thinking that it's a dichotomy between "no automation" and "absolutely robust automation"... well, I think you're robbing yourself of a large chunk of the strategy space by refusing to see any middle ground but the two extremes. Edit: also note that I'm not talking about "failed scripts" at any point. I'm talking about scripts that do exactly what they are supposed to, but they are performing a narrow, easily automated slice of the work. A human can chain such scripts together in the requisite sequence by spending very few minutes of their day.
      - majkinetor 5y ago
lalwanivikas 5y ago
I am sorry but this is tangential to what OP is asking.
- forinti 5y ago
  I think there is an aspect worthy of analysis there. He has clearly been reading up on The Toyota Way and one aspect of it is that they look to understand well a process before automating it. I have found that a lot of complexity comes from mindlessly automating processes: you end up with systems integrations and data conversions that add a lot of complexity and are often brittle too.
  - elcapitan 5y ago
    This is indeed very typical for many digital automation projects created by bureaucracies. As the head of a German airline said, "If you digitize a shitty process, then you’ll end up with a shitty digital process".
CyberDildonics 5y ago
This has nothing to do with the question, why are you going off on a tangent about philosophy of automation?
- kqr 5y ago
  Software is automation. By relying less on automation, your software is less complex. That's a way to manage software complexity organisationally.
  - CyberDildonics 5y ago
    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.
    - kqr 5y ago
      That's not how I see it. Imagine for a moment that we had an epidemic where every family just had to build a five-story mansion complete with service buildings to feel like they keep up with the Joneses. That's what I see a lot of in software right now. I'm merely suggesting that maybe a regular two-story family house is enough. Maybe even one story, depending on needs. Note that only the first sentence of my comment said "don't automate". The other eight described a way to automate with less complexity when you have to.
      - CyberDildonics 5y ago
        Imagine for a moment I think this is the problem - you are imagining a question that isn't being asked by telling someone to just not make that problem. This person asked for book on managing complexity. You are saying 'just don't make software as complex and do it by not making software at all'. That is two steps removed from being any sort of answer to this question.

by kqr 5y ago

extheat 5y ago

Conversely, automation creates a clear and well defined workflow for completing a task. There is nothing to "automate" if there is not already a manual process to doing it. Sure, sometimes the automation you introduce can be an over-engineered solution that's more difficult to maintain (or just not work) compared to a human-done manual process. To that point I think a valid solution would be to make the process itself more automation friendly, if possible given your circumstances.

kqr 5y ago
Yes. This is what Taiichi Ohno would call "standard work": well-defined processes intended to be executed literally, and evolved with and by the people who perform the execution. Standard work is a great source of things to automate, but automation is not a replacement for it.

majkinetor 5y ago

> Automation is brittle and inflexible Wait what ? Mine automation works for years without an issue. Flaky automation is meaningless. > that alerts a human if it encounters an edge case. No. It shouldn't alert anybody almost never if it's good. When you have 300 automation routines, even if it alerts once a year you will have some alert every day. So it needs to alert lower then that, when the world falls out or something...

kqr 5y ago
Yes, you can spend a lot of time and complexity on truly robust automation. But it's not always the most ROI move economically. Especially not in highly volatile businesses where your processes may need to change rapidly.
- majkinetor 5y ago
  You didn't calculate ROI right. If YOU are the one that does intervention, then your time is lost constantly doing manual fixing of failed scripts. Not to mention reputation loss, end user dissatisfaction etc. Automation routines MUST be robust, must handle all weird cases that happen frequently (at least once a year), and must notify when they fail to do so always. Then you should come back and see how to not make them fail even then.
  - kqr 5y ago
    I think you are incorrect on both accounts. It's easy to spend upward of $10000 on really robust automation, when the same manual process would cost only $3000 over its usable lifetime, and the economical-but-less-robust automation costs $1000 over the same period. The robust automation, in that case, has over 10× worse ROI. What's wrong with that calculation? The thing about really robust automation is that for it to pay off, the process have to be static over a large number of executions. For many business needs, the process, or its inputs, change every few executions, and you never get to reap the benefits of robust automation before it needs to be redone at great expense. As for thinking that it's a dichotomy between "no automation" and "absolutely robust automation"... well, I think you're robbing yourself of a large chunk of the strategy space by refusing to see any middle ground but the two extremes. Edit: also note that I'm not talking about "failed scripts" at any point. I'm talking about scripts that do exactly what they are supposed to, but they are performing a narrow, easily automated slice of the work. A human can chain such scripts together in the requisite sequence by spending very few minutes of their day.
    - majkinetor 5y ago

lalwanivikas 5y ago

I am sorry but this is tangential to what OP is asking.

forinti 5y ago
I think there is an aspect worthy of analysis there. He has clearly been reading up on The Toyota Way and one aspect of it is that they look to understand well a process before automating it. I have found that a lot of complexity comes from mindlessly automating processes: you end up with systems integrations and data conversions that add a lot of complexity and are often brittle too.
- elcapitan 5y ago
  This is indeed very typical for many digital automation projects created by bureaucracies. As the head of a German airline said, "If you digitize a shitty process, then you’ll end up with a shitty digital process".

CyberDildonics 5y ago

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

kqr 5y ago
Software is automation. By relying less on automation, your software is less complex. That's a way to manage software complexity organisationally.
- CyberDildonics 5y ago
  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.
  - kqr 5y ago
    That's not how I see it. Imagine for a moment that we had an epidemic where every family just had to build a five-story mansion complete with service buildings to feel like they keep up with the Joneses. That's what I see a lot of in software right now. I'm merely suggesting that maybe a regular two-story family house is enough. Maybe even one story, depending on needs. Note that only the first sentence of my comment said "don't automate". The other eight described a way to automate with less complexity when you have to.
    - CyberDildonics 5y ago
      Imagine for a moment I think this is the problem - you are imagining a question that isn't being asked by telling someone to just not make that problem. This person asked for book on managing complexity. You are saying 'just don't make software as complex and do it by not making software at all'. That is two steps removed from being any sort of answer to this question.