> More fundamentally, though, for both music and books, most of the arguments and questions are music industry questions and book industry questions, not tech or software questions
I agree with this so much, but in practice people actually don't realize this enough.
When I work with business teams, they have a hard time distinguishing business rules from tech problems. So they'll say something like... Oh the payouts aren't deposited in time, we need to detect in advance that a payout is required and start the deposit process earlier. And then they'll say, that's a tech problem for the tech team to solve.
Except not really, yes it takes a software engineer to program a computer to enact these rules and this process, if you've chosen to have the process managed by a computer. That said, all the difficulties are in defining the business rules. When exactly should you start the depositing process? Based on what will you define when it has to start, what if it's started and the customer removes their bank details, or what if etc. This all becomes hard business problems for the business to solve.
So what happens in practice is, business domain experts overtime start to abstract more and more things to the computer, leaving the software to actually answer for these business problems and define the rules for them. In turn it is often to the developer to figure out the solution to the business problem and a strategy to solve it, and then implement it in the computer. Those things often end up happening together.
That's why I think in effect software companies slowly move to owning the business itself. And this is a part of software is eating the world.
As computers take over control, enforcement and execution of more and more business processes, the management and administration authority is slowly reversed, software becomes at the root, and software engineers at the helm. It becomes increasingly difficult for business people without that software background to realize that most things are not a software problem, but a business problem which they could be focusing on themselves, but are delegating more and more over to software companies and software engineers.
It's pretty common to ask a business domain expert about how should this be handled, and for them to ask back, well how does the computer currently handles it?
I agree with this so much, but in practice people actually don't realize this enough.
When I work with business teams, they have a hard time distinguishing business rules from tech problems. So they'll say something like... Oh the payouts aren't deposited in time, we need to detect in advance that a payout is required and start the deposit process earlier. And then they'll say, that's a tech problem for the tech team to solve.
Except not really, yes it takes a software engineer to program a computer to enact these rules and this process, if you've chosen to have the process managed by a computer. That said, all the difficulties are in defining the business rules. When exactly should you start the depositing process? Based on what will you define when it has to start, what if it's started and the customer removes their bank details, or what if etc. This all becomes hard business problems for the business to solve.
So what happens in practice is, business domain experts overtime start to abstract more and more things to the computer, leaving the software to actually answer for these business problems and define the rules for them. In turn it is often to the developer to figure out the solution to the business problem and a strategy to solve it, and then implement it in the computer. Those things often end up happening together.
That's why I think in effect software companies slowly move to owning the business itself. And this is a part of software is eating the world.
As computers take over control, enforcement and execution of more and more business processes, the management and administration authority is slowly reversed, software becomes at the root, and software engineers at the helm. It becomes increasingly difficult for business people without that software background to realize that most things are not a software problem, but a business problem which they could be focusing on themselves, but are delegating more and more over to software companies and software engineers.
It's pretty common to ask a business domain expert about how should this be handled, and for them to ask back, well how does the computer currently handles it?