As a project manager or development manager, you will one day - perhaps today - be confronted with a developer who earnestly insists that he or she can build a calc engine in a couple of days. You'll maybe even get "I'll do it over a weekend". And despite your nagging doubts, enthusiasm trumps experience and you give the go-ahead (is it just me, or is it that the older and wiser we get, the more we question ourselves?). Anyway, after four frantic days of coding, you will be presented with a home-brew calculation engine.

It will be buggy and unreliable and it will probably have a horrible and unintuitive syntax. But your product needs a calc engine, and so you commit to the in-house version. No sooner is it baked into the core of your app than subtle bugs emerge. Performance slows when you hit real-world loads. Next thing, the client has built so many calculations that he demands named sub-expressions, just to encapsulate logic and keep things under control. Maybe you have hierarchical structures, and the client demands that a parent node must automatically aggregate all the child nodes.

Before you know it, you've blown four, five, six weeks of developer time trying to get it right. All the other stuff your developer was supposed to be working on gets thrown out the window. The client has lost faith. The home-brew calc engine has side effects that extend into every corner of your application so refactoring is virtually impossible. 

With heavy heart, you (and your boss) realize that because of that one choice that you made or allowed to happen, your organization is now burdened with a mass of ugly code that it has to maintain in perpetuity. And the one developer that knows how it works is starting to take private phone calls in the hallway...

Don't be that manager.

Just buy a proper calc engine and go build your app.