Comment by davedx | Hacker News Reader

Comment by davedx | Hacker News Reader

Eh, I've worked on billing, payments and salary systems, some of these problems are not that awful. It sounds like the source of much of it is just classic underestimation of the amount of work & complexity to implement something. If someone gets away with saying "shouldn't be hard right?" to the point it dictates the size of the team (2 engineers? That's barely a team), then you're going to have problems.

Some of it comes down to picking the right tool for the job. The article doesn't touch on technology choice at all, but it matters. When I built a salary system, I deliberately chose a tech stack that had good numeric calculation support (so not JavaScript). These choices matter and have lasting impacts on your project. Same thing for handling dates, for example here .NET and Java have excellent standard library support for everything date related. Other languages, not so much.

Another point the article talks about is change: companies change how they bill over time; customers change their plans. Again there's nothing specific to billing systems here. All systems have to deal with change. All systems beyond a trivial size end up with migration scripts, and sometimes those scripts end up being productized and becoming buttons in dashboards.

I guess my main point here is don't underestimate what might seem to be an "ancillary" product when it's an essential service that makes sure cash keeps flowing. Treat every important project with the care and respect necessary. Allocate resources properly. Don't underestimate. Oh, and don't underestimate.

My boss told me to estimate the effort it would take to make an app that integrates with a bunch of server systems. He estimated 'x' units of time, thinking only of the core functionality of what the app actually does. I told him it's more like 10x, because the core functionality is only a small part of a product. Billing, testing, the dev environment, customer-facing documentation, the product web site, etc... all add up.

What did it end up being? I’m guessing closer to your order of magnitude? Excluding scope creep, of course.

He abandoned the project before it even started, even though IMHO it was a good idea. Similar products that ended up with a wider scope include the likes of Okta, so clearly there was a large addressable market!

Something I've found is that there are two types of people when it comes to planning / forecasting:

SALES -- Wants to hear only positive things. Likes to ignore predictable issues, pretend unlikely risks will never happen, just go-go-go. Often sounds unreasonably optimistic to other people, which can be off-putting.

ENGINEERING -- Wants to hear all the bad things before committing. Likes to mull over all predictable issues to determine if they're show-stoppers and/or if workarounds are available. Often sounds unreasonably pessimistic to other people, which can be off-putting.

Both types can be in agreement that a project is a "good idea" while one type is listing only the upsides and the other type is listing only the downsides.

This can result in rather poor communication and missed opportunities.

> It sounds like the source of much of it is just classic underestimation of the amount of work & complexity to implement something

Yeah, but this doesn't help, because the problem is that billing is perennially underestimated. Everyone thinks it looks easy, and offers "solutions" like those in this thread. And mostly they work, until one day you wake up and you no longer know how your bowl of spaghetti code works.

A lot of things are perennially unterestimated, and making it work anyway is simply an engineer's job and can be quite fun. If it literally gives you nightmares, e.g. because a bad estimate gets turned into a deadline, chances are your job just sucks (and likely your company, too).

Don't forget the accounts receivable and reconciliation side too. I built one of those fresh out of college for an independent pharmacy chain. My and my boss spent years working on it and every time we thought we had it perfect another wrinkle would show up.

Yes, these are great additions. Reconciliation is a doozy, and there are so many reconciliation points - payments, usage data, supplier invoices.

And then there is revenue assurance…

I’ve written a subscription billing app on PHP and MySQL. Just the database queries to figure out what has been paid or not (x in-full/partially/over x in-time/late) are absolutely horrendous to get right even without the complexity of VAT, multiple subscription types, usage billing etc.

yeah that part is strangely hard. I did an rx pricing system for a pharmacy chain early in my career and the weirdest things would happen. The chain would just get random checks from insurance carriers with no EOB or anything to know what invoice to tie the check to. Then, when the insurance company realized their mistake, they wouldn't call us or cancel the check or anything they'd just short a invoice for the amount of the check or sometimes even divide it over multiple invoices. This would happen like 6 month later.

we had an account that was literally called "magic money" where these checks were deposited. Then when an insurance carrier shorted their invoice and we could find no rational reason why we would use the "magic money" account to cover it.

.NET timezones are not really practically useful. I suggest using noda times with its IANA timezone implementations. The EF Core pg adapter has 1st class support for noda times thanks to Shay Rojansky.

Why not javascript specifically? Using integers or floats is wrong in any language. You want a decimal representation library when dealing with money.

> Why not javascript specifically?

Javascript has one number type; float.

It's fair to say most JS code is only handling floats especially if you're just relying on JS's automatic casting but JS does have BigInt as well, and it has a whole bunch of numerical typed arrays that only accept specifically typed numbers like Uint8 or Int32 etc. You can do math in JS quite safely if you delve into the less well-known types a bit.

Not true.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

1) Wow, I didn't know that existed.

2) Wow, those downsides are insane. It's not constant time, thus can't be used in cryptography...? Has huge performance impacts and can't be casted to a "number"- how is this implemented? it can't be native INTs on the CPU?

Any cryptography is surely using Uint8Array.

>Any cryptography is surely using Uint8Array.

Is this to optimise memory operations over a large plaintext/cipher text or is there some other advantage to it that is less obvious (e.g. more resistant to timing attacks?)

No, it’s because Number is internally floating point and cannot represent all integers.

"Integer number of cents" is a fine way to deal with money unless you want sub-cent units. Otherwise, you can divide it up smaller: a few stock exchanges use [price in dollars] * 10^8 as their price unit, and store a 64 bit int.

Exactly, and BigInt fits this role perfectly.

> "Integer number of cents" is a fine way to deal with money unless you want sub-cent units

I use this approach to minimize the amount of time I have to waste on trivial money operations such as storage and api's, but this approach (number of cents) falls apart quickly the moment you need to do something as simple as calculate tax or a commission. So, still likely no getting around proper float math even if you may not really be all that interested in sub-cent units.

You really want to use a decimal library for any serious financial math. And if you’re doing the math on tiny units of processing you’re going to want the precision and accuracy.

You don’t need to work in decimal cents. Many work in thousandths of a cent or smaller. But you want an infinite upper and lower bound. Even 64 bit integers only has so much upper range depending on how far you subdivide a penny. You also want the precision guarantees when you take those numbers and do more than just add or subtract them.

Why do you need an infinite upper bound for money? I agree that you need to do saturating arithmetic, but 2^64/10^8 dollars is about 10^10 dollars, which is the around the GDP of the US. A number that big is not going to show up in your billing system if you do everything correctly.

With all numerical calculations, you need to be careful about losing precision on mathematical operations, so it's a good idea to think about things like this even if you use a decimal number system with a very wide dynamic range - it won't be very precise all the time.

No. You want a parametrized "Money" type, one that can do calculations in varying numbers of decimals, and configurable rounding. There are legal requirements that make this necessary.

One (from memory, not exact) calculation I've had to implement for a customer: Multiply prices by whole numbers. Prices are given in cents subdivided to 5 digit precision, result should have 10cent precision, rounded down. Then, for the tax calculation, get taxes from some tables, 3 different taxes for each line item. Apply the first two taxes, Euros with 10 digit subdivisions, then round "according to trade custom" (which is the usual "up from .5 cents, down from below .5"). Then add the third tax, Cents with 5 digit subdivisions, round down. Then add all the line items and their taxes, separately as well as together.

And if there is a Skonto, take care to properly unravel the tax stuff again.

I've had to do it in plain Typescript, it is possible, but it really sucks. Those days when you yearn for COBOL... ;)

I was thinking the same thing. It’s like “(computer thing) is hard” is the new thing

Only if you can use modern Java.

But yeah, also VAT calculations should be outsourced how ever possible. In the US, sales tax is at the postcode level so it gets really crazy.

It sucks you have to pay VAT even on digital goods and services nowadays. Ideally it'd be abolished entirely.

+1 on the abolishment!

What would you suggest to outsource VAT calculations? We've yet to find a tool / platform we really like, that we could partner with.

AFAIK, Avalara is the defacto player on this kind of stuff

Yes,it is! but I'm wondering if there is a player that is a bit more: - Developer-friendly - SMB-friendly?

Not sure how much it costs but doesn't look very SMB/startup-friendly...

If you think that government will give up (should they?) on all that tax money, you're probably fooling yourself...

Ha yes I almost edited my comment earlier to mention that calculating tax is probably something most people should just outsource to a third party.

I also have experience with wage tax calculation systems, and the solution we went with was browser automation that used a third party wage tax calculator. That stuff can be impossibly complicated -- and with many governments it changes every year too!

> it sucks you have to pay VAT even on digital goods and services nowadays. Ideally it'd be abolished entirely.

what do you propose as replacement? It's not as if the governments are going to let go part of their tax revenues

Reply on news.ycombinator.com