Live data from Hacker News

Systems, not Programs

shalabh.com

1–10 of 29 posts

Re: Systems, not Programs

#2
I think we should go even further and think systemic. I work in the public sector, where we have more than 500 different IT systems (in this context, mostly programs).

It’d be a clear advantage if they were all build to be systems, but it would be even better if they were build to be systems that coexist with each other.

I wish suppliers would ask us what hardware we operate, what services and API we’d want them to interact with, and, made plans for what we have to do when their system eventually dies. Because right now, everything is build for specific purposes, and it’s impossible to make most things work together.

So you’ll have one program that handles finances for sick people. Another that handles networking to companies and businesses that help get sick people back on track. Another program which keeps track on the wellbeing on families with sick members. A while range of medical programs. And none of them work together, run on the same hardware or has any form of uniform support solution, so we have to waste thousands of nan hours simply making sure every program has the data it needs.

It’s silly, but every developmenthouse seem to suck equally at making non silo sollutuons.

Re: Systems, not Programs

#6
post #3

The problem with systems is emergent and unexpected behaviour. Things can go very bad very quickly once a death spiral kicks in.

Since emergent behavior itself, is wanted, the unexpected subset is what you imply is detrimental, but that's the case for programs as well.

Re: Systems, not Programs

#7
May I add a small change? s/program-centric/product-centric/ s/system-centric/human-centric/ Today the trend is selling anything from vaporware to medical product to cure non existent illness, IT it's no different than that. Ancient systems, born in a pioneering era, in universities labs, in company labs lead by tech savvy guys not managers, are built to innovate, actually no one company want innovation, it's bad for a management point of view, better found well know stuff salable as new thing to make money in a predictable way.

Re: Systems, not Programs

#8
post #3

The problem with systems is emergent and unexpected behaviour. Things can go very bad very quickly once a death spiral kicks in.

Since emergent behavior itself, is wanted, the unexpected subset is what you imply is detrimental, but that's the case for programs as well.

Emergent behavior isn't always wanted. Sometimes it's desirable (Oh, this widget can be copy/pasted into other documents! I didn't expect that to work yet.) Sometimes it's not (I can't figure out why this bot keeps stacking boxes. Patrolling the area is supposed to be its highest priority right now.).

Sometimes we can deliberately induce emergent behavior (https://en.wikipedia.org/wiki/Automated_planning_and_schedul...) by composing our system correctly. To create behaviors and solutions that we didn't initially conceive of. But if unplanned emergent behavior shows up, your system has become unmaintainable until you've identified the causes.

Re: Systems, not Programs

#10

Earlier quoted context omitted.

Since emergent behavior itself, is wanted, the unexpected subset is what you imply is detrimental, but that's the case for programs as well.

Emergent behavior isn't always wanted. Sometimes it's desirable (Oh, this widget can be copy/pasted into other documents! I didn't expect that to work yet.) Sometimes it's not (I can't figure out why this bot keeps stacking boxes. Patrolling the area is supposed to be its highest priority right now.). Sometimes we can deliberately induce emergent behavior ( https://en.wikipedia.org/wiki/Automated_planning_and_schedul…

Why do you reference the article on planning and scheduling?
Post reply on HN