Two months later the law changed adding a new special case somewhere deep inside. I could start over. Lesson learned: don't outsmart the logic of the business.
Two months later the law changed adding a new special case somewhere deep inside. I could start over. Lesson learned: don't outsmart the logic of the business.
This way you know when you come back to it, what must stay, what must go, and what must change.
Hats off to you, you wonderful person!
This resulted in him filing a large number of minor bugs between the spec and the reference implementation: https://hevc.hhi.fraunhofer.de/trac/hevc/query?status=accept...
And a product: http://www.argondesign.com/products/argon-streams-hevc/ (page includes explanatory video)
Edit: the tool critical to the project was "Ometa": https://en.wikipedia.org/wiki/OMeta
On a much smaller scale, VPRI made part of their TCP stack by parsing ASCII diagrams of packet contents (e.g. see the STEPS reports at http://vpri.org/writings.php )
Edit: Ah, I see user nradov has already mentioned this in a sibling comment :)
http://www.vpri.org/pdf/tr2007008_steps.pdf (Appendix E).
There is a reason people tell you to do "KISS". Which is just coding what you need right now, and not trying to be too smart about it.
Life is full of special cases : try to code an international calendar application, and you'll see what I mean. So many cultural things, so many political things, so many legal things...
So yeah, if you can find an elegant way to generalize your problem, do so. But unless you work on a purely theorical topic, you will have special cases. And they will change.
It's easier to check that the code matches the law (after all there are no test vectors on the law apart from case law so you have to go by the drafting) and it makes updates when an amendment is made much simpler.
That, and there is usually zero need to optimise.
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.
“It was decided!”
“By whom? Why?”
“???, It was decided!”
“...”
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.
If it was easy, developers wouldn't be well paid.
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.
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.
Every year on budget day I used to listen to the live speech from the house of commons in case they changed something that effected billing - one year they changed VAT (sales tax) in the middle of the month.
If you can get over their lack of coolness (some implementations use spreadsheets!?!?!) they are a nice way to separate the crazy complicated stuff that changes all the time from the rest of the more static logic.
Anyway, business logic is a perfect example of stuff that should go in Policy: functional, side-effect-free code (but not necessarily tidy or easy to read) which computes a value from a set of inputs. Like the parent says, effort spent optimising here may end up being a poor investment if the requirements change every year.
Mechanism code, OTOH, generally ends up containing all the side effects. It's harder to test so it tends to be dumb and, therefore, less susceptible to changing requirements. Optimisations here can pay off because the code lives longer.
Really though it all comes down to tests, tests and more tests. Automation is an asset and test cases outlive everything so make sure they work against the interface, not the implementation.
Time for a DSL and a compiler from the DSL to a truth table! :)