3 ms·

For me it is the separation of business logic and data from the programming implementation. Often the workflow in automating a work process is: - Worker has in

For me it is the separation of business logic and data from the programming implementation. Often the workflow in automating a work process is: - Worker has intuition on how things work - Specialist starts automating and running into exceptions, walls - Worker explains exceptions as they're discovered - Specialist adds spaghetti to the 'clean' business logic model they started with - This keeps going until the end result looks like what the worker expects - The worker then sees a datapoint they think is incorrect, but they can't check it because the business logic is embedded in software, code, database stored procedures, etc. - The specialist is then called back into debug and resolve the issue. At my workplace we run into this issue constantly, where the ability to modify/adapt the business logic is lost through automation, and it becomes obscured to the point that the intuitive workers can't trust that the logical model is right. There needs to be better separation of business logic from models so that programmers don't need to 'dig' into business processes and exceptions, and workers don't need to deal with part of their responsibility being shoved into a black box that they're not sure they totally trust or can adapt easily should a need arise.

csours 4y ago
Wow. I would say the complete opposite. Why are you writing a program for work unless you are helping to solve a problem? The implementation only exists to work with business logic and data. Excel is an implementation that does not care about business logic and data. Anyone can add their own business logic and data.
- akersten 4y ago
  That most of the business world lives and breathes Excel is a testament to OP's point. Companies can cram whatever garbage logic they like into a spreadsheet and no one has to call a developer Microsoft because their pivot table isn't doing The Business Thing that they expect - the end users simply have the power to understand and fix the problem themselves.
  - csours 4y ago
    Sure, but then what is your job? Making Excel? No one needs you to make Excel, it already exists.
- probablypower 4y ago
  >Why are you writing a program for work unless you are helping to solve a problem? I'm not entirely sure what your point is here other than implying that the programs I/we write aren't solving a problem, which is not the case. > The implementation only exists to work with business logic and data. This is true. I would say that any implementation of automation is really an implementation of business logic that turns one set of data into another. For example, taking financial transaction data and using business logic to convert this into data that measures company profitability. > Excel is an implementation that does not care about business logic and data. Yes and no. Consider the example of transaction data -> profitability measures. If you compute this in excel, you are hand entering data (or using data inputs if you're not a neanderthal) and you're inserting business logic into cell formulas that relate to other cell formulas. Maybe you're even using VBA. Business logic is embedded in the worksheet. This is why you end up with a lot of small companies that have "THE" accounting spreadsheet and "THE" inventory management spreadsheet. It is the extent to which they can automate. I don't know if you've ever tried to detangle the business logic from an excel spreadsheet, but it is a pain in the ass, and it is very bug-prone. Tracking down bugs and errors in an excel spreadsheet is spiritual torture. > Anyone can add their own business logic and data. I guess you may have read my post from the perspective of a small company, where it is entirely feasible to store your company's data and business logic in spreadsheets. I'm coming from the perspective of a large enterprise where having excel spreadsheets on the critical path of any business process is a disaster.
  - csours 4y ago
    We may be talking past each other. > "There needs to be better separation of business logic from models so that programmers don't need to 'dig' into business processes and exceptions, and workers don't need to deal with part of their responsibility being shoved into a black box that they're not sure they totally trust or can adapt easily should a need arise." I agree that this is unsatisfying, but I don't see programming tools fixing this, and especially not "separation"; however, I don't know what you mean by separation. I think UX* is the way to approach this, so that developers account for the actual data and decisions in a workflow. I think you convince the business with better observability. * UX is not UI.
panstromek 4y ago
> the ability to modify/adapt the business logic is lost through automation This is a really interesting observation, I haven't thought about it like that before.

csours 4y ago

Wow. I would say the complete opposite. Why are you writing a program for work unless you are helping to solve a problem? The implementation only exists to work with business logic and data. Excel is an implementation that does not care about business logic and data. Anyone can add their own business logic and data.

akersten 4y ago
That most of the business world lives and breathes Excel is a testament to OP's point. Companies can cram whatever garbage logic they like into a spreadsheet and no one has to call a developer Microsoft because their pivot table isn't doing The Business Thing that they expect - the end users simply have the power to understand and fix the problem themselves.
- csours 4y ago
  Sure, but then what is your job? Making Excel? No one needs you to make Excel, it already exists.
probablypower 4y ago
>Why are you writing a program for work unless you are helping to solve a problem? I'm not entirely sure what your point is here other than implying that the programs I/we write aren't solving a problem, which is not the case. > The implementation only exists to work with business logic and data. This is true. I would say that any implementation of automation is really an implementation of business logic that turns one set of data into another. For example, taking financial transaction data and using business logic to convert this into data that measures company profitability. > Excel is an implementation that does not care about business logic and data. Yes and no. Consider the example of transaction data -> profitability measures. If you compute this in excel, you are hand entering data (or using data inputs if you're not a neanderthal) and you're inserting business logic into cell formulas that relate to other cell formulas. Maybe you're even using VBA. Business logic is embedded in the worksheet. This is why you end up with a lot of small companies that have "THE" accounting spreadsheet and "THE" inventory management spreadsheet. It is the extent to which they can automate. I don't know if you've ever tried to detangle the business logic from an excel spreadsheet, but it is a pain in the ass, and it is very bug-prone. Tracking down bugs and errors in an excel spreadsheet is spiritual torture. > Anyone can add their own business logic and data. I guess you may have read my post from the perspective of a small company, where it is entirely feasible to store your company's data and business logic in spreadsheets. I'm coming from the perspective of a large enterprise where having excel spreadsheets on the critical path of any business process is a disaster.
- csours 4y ago
  We may be talking past each other. > "There needs to be better separation of business logic from models so that programmers don't need to 'dig' into business processes and exceptions, and workers don't need to deal with part of their responsibility being shoved into a black box that they're not sure they totally trust or can adapt easily should a need arise." I agree that this is unsatisfying, but I don't see programming tools fixing this, and especially not "separation"; however, I don't know what you mean by separation. I think UX* is the way to approach this, so that developers account for the actual data and decisions in a workflow. I think you convince the business with better observability. * UX is not UI.

panstromek 4y ago

> the ability to modify/adapt the business logic is lost through automation This is a really interesting observation, I haven't thought about it like that before.