Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Best books on managing software complexity?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 127 posts

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

#91

Post by kqr »

extheat wrote: post #52
kqr wrote: 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…

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

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.

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

#92

Post by majkinetor »

eklavya wrote: post #87
majkinetor wrote: post #80

Earlier quoted context omitted.

I think you don't understand automation. > 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…

You are making some really bold claims and you really might be an expert but I think you should open your mind to the slight possibility that others might also know what they are talking about. The OP specifically started with the premise that fast changing businesses would spend all their time fixing their automation and it might not make sense in that situation. Can’t comprehend how that doesn’t make immediate sens…

Meh...

Here is the exact case you mention, just WAY worst. This is something I did for chocolatey community:

https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...

This page is report of the PowerShell framework I developed mostly in first year of development (https://github.com/majkinetor/au) that checks ~250 web sites for updates on various software. Today it has 6 errors and usually never much more. On my own location I keep ~60 packages and I I tackle errors maybe once a year. Stuff just work, and you rarely have to visit, otherwise I would be involved entire day into this and I am not, while those packages have many millions of users.

Now I spend almost 0 time maintaining packages and I am one of the top choco package owners.

Check out the options used, some of which make it so robust:

https://github.com/chocolatey-community/chocolatey-packages/...

> It’s sources keep changing frequently, robust automation here is probably a research project and simple automation is orders of magnitude more bang for buck.

Even if the source changes frequently its better to automate. Its not when it keeps changing daily or more then that. By automating you learn something new, so it pays more for your experience. Manually working every day the same thing (that may move around) doesn't involve complex thinking and is just waste of time.

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

#94

Post by agumonkey »

kqr wrote: 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.

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

#95

Post by kqr »

majkinetor wrote: post #92
eklavya wrote: post #87

Earlier quoted context omitted.

You are making some really bold claims and you really might be an expert but I think you should open your mind to the slight possibility that others might also know what they are talking about. The OP specifically started with the premise that fast changing businesses would spend all their time fixing their automation and it might not make sense in that situation. Can’t comprehend how that doesn’t make immediate sens…

Meh... Here is the exact case you mention, just WAY worst. This is something I did for chocolatey community: https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7... This page is report of the PowerShell framework I developed mostly in first year of development ( https://github.com/majkinetor/au ) that checks ~250 web sites for updates on various software. Today it has 6 errors and usually never much more. On…

> Even if the source changes frequently its better to automate. Its not when it keeps changing daily or more then that.

Now I think we can get somewhere! Is this an admission that automation is not worth it when the processes or inputs change too often?

If so, then this frequency (which you have given as daily) depend entirely on the business needs in question.

Often, there's no business case to run an automated process daily.

Weekly or even monthly are very common intervals for processes in business. For a process that needs to run monthly, you only get twelve executions in a year. If the inputs change every six months, do you still think spending 60+ commits (as in your settings example) is worth it every six months, when there are cheaper ways to do it with limited human intervention?

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

#96

Post by bob1029 »

fred123 wrote: 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 right now.

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

#97

Post by majkinetor »

kqr wrote: post #95
majkinetor wrote: post #92

Earlier quoted context omitted.

Meh... Here is the exact case you mention, just WAY worst. This is something I did for chocolatey community: https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7... This page is report of the PowerShell framework I developed mostly in first year of development ( https://github.com/majkinetor/au ) that checks ~250 web sites for updates on various software. Today it has 6 errors and usually never much more. On…

> Even if the source changes frequently its better to automate. Its not when it keeps changing daily or more then that. Now I think we can get somewhere! Is this an admission that automation is not worth it when the processes or inputs change too often? If so, then this frequency (which you have given as daily) depend entirely on the business needs in question. Often, there's no business case to run an automated proc…

> Often, there's no business case to run an automated process daily.

Almost 100% of the cases I have run daily, hourly and even less (5,10,20,30 minutes schedule are common). I even had one recently that executed millions of requests to some REST API daily, running every few seconds. I call those "app supporting scripts", and I offload specific features of the main app to those.

Must be architectural thing I guess, I work as principal architect and I design most of my services so that they rely heavily on automation support.

> Is this an admission that automation is not worth it when the processes or inputs change too often?

I don't work in a vacuum. For me there are no rules about anything, context is most important (patterns, best practices etc. are for newbies). That case does lean to the manual side on first thought, but it all depends on other factors.

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

#98

Post by Ozzie_osman »

- Philosophy of Software Design (great short read packed with insight)

- Mythical Man-Month (the classic, a little outdated but the principles still ring very true)

- Software Engineering at Google (thoughts from a company that has spent a lot of time thinking about this at scale)

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

#99

Post by kqr »

majkinetor wrote: post #97
kqr wrote: post #95

Earlier quoted context omitted.

> Even if the source changes frequently its better to automate. Its not when it keeps changing daily or more then that. Now I think we can get somewhere! Is this an admission that automation is not worth it when the processes or inputs change too often? If so, then this frequency (which you have given as daily) depend entirely on the business needs in question. Often, there's no business case to run an automated proc…

> Often, there's no business case to run an automated process daily. Almost 100% of the cases I have run daily, hourly and even less (5,10,20,30 minutes schedule are common). I even had one recently that executed millions of requests to some REST API daily, running every few seconds. I call those "app supporting scripts", and I offload specific features of the main app to those. Must be architectural thing I guess, I…

Then I suspect we are in violent agreement only working on processes at different timescales in our day-to-day!
Post reply on HN