> Is the issue that we're conflating the two tasks into one?
I'd say it's the opposite. Business logic is software. More than that, bureaucracy is software too. Same goes for contracts, and laws too[0]. It's because "If <this> then <that> happens" is code. "Do <this bunch of stuff> until <this happens>, except when <something else happens>, do <that> instead" is code.
So when you're encoding the business logic in your software, what you're doing is copying some external code into your program, and translating it from natural/legalese to your programming language. With all the consequences this entails - you now have two independent pieces of code that do the same, are not visibly connected, and evolve separately. Whenever something changes in the way business works, someone needs to update that same code across applications that use it. Mistakes are bound to happen.
A big problem in the above is the state of the code you're translating from - the actual logic of the business. It's a continuously evolving system that's being developed by people who are specialists in business, not in logic. That's why business rules often seem sort of but not quite coherent, with exceptions and repetitions, and special cases. It's because people responsible patch them up as they discover problems, but the concept of refactoring or unit testing or integration testing of actual business rules is something between not known and not doable in practice.
So in the end, I'd think that yes, there's more than one type of jobs in here, but they're actually all software development. Not in the sense that they're all writing programs for computers - some of it is writing programs for humans (the bureaucracy) - but all of it could use some of the insights and tooling from software development. There is no separation between "software" and "logic" - there's only separation between what can be fully specified, and thus treated as code, and what cannot be specified, because it's too much tied to fuzzy, case-by-case value judgements.
(Going back to your bridge example: you hire civil engineers to design the bridge, but then again, you don't just go out and say "hey, I have money, go build me a bridge!". A bridge has to serve a purpose and integrate into other systems, which is why those bridge designers get input from traffic engineers, urban planners, and other engineers/engineer-likes.)
--
[0] - Now, to be very clear, I'm not on-board with the current ideas of "code as law", and I don't want them becoming reality any time soon. Fully specifying laws would require us to have total understanding of human values, which we don't have - that's why the role of human judgement is important, and that's the good reason for which laws are underspecified. Same goes for contracts and some business rules too.
[1] - They sometimes also have an incentive to keep things opaque. Sometimes a reason for a business rule to be unnecessarily lax may be that the "wrong" state is actually a "good" state to someone who doesn't want to admit to it. Think e.g. costs savings by trading off security or reliability, or tax evasion.
I'd say it's the opposite. Business logic is software. More than that, bureaucracy is software too. Same goes for contracts, and laws too[0]. It's because "If <this> then <that> happens" is code. "Do <this bunch of stuff> until <this happens>, except when <something else happens>, do <that> instead" is code.
So when you're encoding the business logic in your software, what you're doing is copying some external code into your program, and translating it from natural/legalese to your programming language. With all the consequences this entails - you now have two independent pieces of code that do the same, are not visibly connected, and evolve separately. Whenever something changes in the way business works, someone needs to update that same code across applications that use it. Mistakes are bound to happen.
A big problem in the above is the state of the code you're translating from - the actual logic of the business. It's a continuously evolving system that's being developed by people who are specialists in business, not in logic. That's why business rules often seem sort of but not quite coherent, with exceptions and repetitions, and special cases. It's because people responsible patch them up as they discover problems, but the concept of refactoring or unit testing or integration testing of actual business rules is something between not known and not doable in practice.
So in the end, I'd think that yes, there's more than one type of jobs in here, but they're actually all software development. Not in the sense that they're all writing programs for computers - some of it is writing programs for humans (the bureaucracy) - but all of it could use some of the insights and tooling from software development. There is no separation between "software" and "logic" - there's only separation between what can be fully specified, and thus treated as code, and what cannot be specified, because it's too much tied to fuzzy, case-by-case value judgements.
(Going back to your bridge example: you hire civil engineers to design the bridge, but then again, you don't just go out and say "hey, I have money, go build me a bridge!". A bridge has to serve a purpose and integrate into other systems, which is why those bridge designers get input from traffic engineers, urban planners, and other engineers/engineer-likes.)
--
[0] - Now, to be very clear, I'm not on-board with the current ideas of "code as law", and I don't want them becoming reality any time soon. Fully specifying laws would require us to have total understanding of human values, which we don't have - that's why the role of human judgement is important, and that's the good reason for which laws are underspecified. Same goes for contracts and some business rules too.
[1] - They sometimes also have an incentive to keep things opaque. Sometimes a reason for a business rule to be unnecessarily lax may be that the "wrong" state is actually a "good" state to someone who doesn't want to admit to it. Think e.g. costs savings by trading off security or reliability, or tax evasion.