>Lesson learned: don't outsmart the logic of the business.
Very often when people try to solve problems, like the one you faced, with software, they fail to recognize that you might have to rethink the business logic. It's my belief that the majority of software design for specific niche business and governments fail because there was a lack of willingness to change and simplify the rules.
Of cause a project create a new system for taxation will fail, if you have 6000 pages of rules, not including the tax law itself.
Often we think we have a software bug/issue, in reality what we have is a flawed business logic. Until such time the people in charge fixes the logic, we're not able to do anything clever of efficient in software.
>* they fail to recognize that you might have to rethink the business logic*
Oh, we often recognize this.
You try telling a paying client that you think their business process is sub-optimal. I'll fetch the popcorn...
There are systems out there essentially replicating the workflow of older systems which replicate the workflow of an even older one, which was designed simply to automate a paper-based process all those years ago. If you are talking to a large business then the chances are that the people you are talking to don't have authority to change the business processes even a little bit.
Or, as is more often the case in my experience, the logic is dealing with real world cases that are outside the software's control and the business logic must follow the real world cases to be worthwhile. Which I guess is what the parent's spec example is really an example of.
I worked on ERP software in a past life and this was the main challenge. The software had to deal with "normal" cases well enough to improve efficiency, but had to be flexible enough to allow employees to handle unavoidable exceptions, without becoming a giant kludge. There was nothing worse for a user than having to deal with a special case and finding that they can't because they are blocked by the software.
You're right. But when a government is involved, you cannot even start explaining to `the business` they have flawed logic. (Believe me, I've tried... and failed)
It was decided over dozens of meetings with dozens of people, and there are not good notes. Those people are smart and considered more details than you did (but not always the same details). There is rightly fear that if we reconsider this again we will forget one of those other details and some up with a decision that is better for your case but worse overall because it breaks some other case.
Isn't it more likely they just keep on adding little exceptions in order to be able to show they pushed something through for their constituents? That's the impression I got when reading these laws in the first place (a bone for the liberals, a bone for the socialists, ....)
Isn't this is a feature, not a bug? When things are decided by a democratically elected body you don't necessarily want a contractor coming in and tweaking things "because this is a better way."
Alas the real world is often not amenable to the fiery rage of logical-minded programmers. I’m sure there are plenty of examples of poor logic in real-world policies that could be simplified but there are just as many or more exceptions that serve a purpose, whether the justification is encoded in your requirements docs or not.
That's also why large software projects for government usually fail.
Create a system that handles all the rules of a single municipality or so -- doable. But too expensive for a single municipality.
So we create one system that will work for all municipalities! That way they can afford it, right?
Yes, but none of them is going to change their process. All the different ways of doing more or less the same thing have to be supported, in one system.
End result: nothing working, way over budget. Every single time.
Interestingly, the APL community (or at least the kdb/K community) and the Forth community (from what I hear) often push in the exact opposite direction. They seem to love to take advantage of any accidental regularity in the problem as given to simplify the code as much as possible.
The logic is that often the specs don't change, and if you make the code concise enough, you can just rewrite it if you need to make it more general.
Oh, some things never change. Others change all the time... And there are a few that absolutely never changed, but as soon as you automate them, they will change.
Most projects like this fail because they don't practice TDD. They have pages of code and no single proof that it works as expected apart from feedback from people testing it which is prone to errors.
6000 pages of rules is not a problem. You can implement anything but if you don't care to prove you implemented it correctly then that will almost never work.
Proof and test are different things, you seem to be missing them. A proof is a math concept to verify that all cases are handled, a test is a implementation concept to check one particular case is handled the way you think it should be. Both are important because both uncover a different type of bug. (Proofs uncover cases where you didn't think of something, tests uncover cases where you thought of something but didn't get some detail right)
Very often when people try to solve problems, like the one you faced, with software, they fail to recognize that you might have to rethink the business logic. It's my belief that the majority of software design for specific niche business and governments fail because there was a lack of willingness to change and simplify the rules.
Of cause a project create a new system for taxation will fail, if you have 6000 pages of rules, not including the tax law itself.
Often we think we have a software bug/issue, in reality what we have is a flawed business logic. Until such time the people in charge fixes the logic, we're not able to do anything clever of efficient in software.