71–80 of 127 posts
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…
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…
I am sorry but this is tangential to what OP is asking.
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.
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…
> 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 some…
Earlier quoted context omitted.
I am sorry but this is tangential to what OP is asking.
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.
Earlier quoted context omitted.
> 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 some…
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.
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.
For Software specific issues i highly recommend David Parnas' collected papers in the book Software Fundamentals. He and his colleagues defined much of what is mainstream in today's Software Architecture/Organization practice.
Finally, the case studies given here are a great source of insights: https://aosabook.org/en/index.html
Earlier quoted context omitted.
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.
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 t…
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.
I think it is worthwhile to first look into the fields of Complexity Science/Complex Systems Science and Systems Thinking/Systems Theory for overarching insights : [ https://en.wikipedia.org/wiki/Complex_system and https://complexityexplained.github.io/ ] and [ https://en.wikipedia.org/wiki/Systems_thinking and https://thesystemsthinker.com/systems-thinking-what-why-when... ] For Software specific issues i highly rec…
Earlier quoted context omitted.
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 t…
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 t…
> 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.
Manual process is incomparable to automation, because $3k human will make mistakes as humans are not good robots. Also, your miserable $3k human can now do normal thing.
> 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.
It doesn't have to be static, it just mustn't be random. Also, how often process changes is important and automation with scripts (that can be changed ad hoc) allows for quick flexibility when problems arise.
> 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.
You are also robbing yourself of time to do other things which may lead to more progress, since you are fixing flaky automation all the time.
> A human can chain such scripts together in the requisite sequence by spending very few minutes of their day.
I LOLed. A minute for a single script. You must have missed that in enterprise there are hundreds of scripts. Heck, I usually have 20-30 on a single project.