6 ms·

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 unde

by davedx 4y ago

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.

jiggawatts 4y ago
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.
- texasbigdata 4y ago
  What did it end up being? I’m guessing closer to your order of magnitude? Excluding scope creep, of course.
  - jiggawatts 4y ago
    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.
doctor_eval 4y ago
> 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.
- moring 4y ago
  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).
- chasd00 4y ago
  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.
  - doctor_eval 4y ago
    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…
nivenkos 4y ago
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.
- AnhTho_FR 4y ago
  +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.
  - karambahh 4y ago
    AFAIK, Avalara is the defacto player on this kind of stuff
    - AnhTho_FR 4y ago
      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...
- gbersac 4y ago
  If you think that government will give up (should they?) on all that tax money, you're probably fooling yourself...
- davedx 4y ago
  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!
- baud147258 4y ago
  > 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
eurasiantiger 4y ago
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.
- chasd00 4y ago
  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.
Waterluvian 4y ago
Why not javascript specifically? Using integers or floats is wrong in any language. You want a decimal representation library when dealing with money.
- dijit 4y ago
  > Why not javascript specifically? Javascript has one number type; float.
  - onion2k 4y ago
    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.
  - eurasiantiger 4y ago
    Not true. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - dijit 4y ago
      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?
      - eurasiantiger 4y ago
        Any cryptography is surely using Uint8Array.
        SgtBastard 4y ago
johnwheeler 4y ago
I was thinking the same thing. It’s like “(computer thing) is hard” is the new thing
MustardBob12 4y ago
.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.

by davedx 4y ago

jiggawatts 4y ago

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.

texasbigdata 4y ago
What did it end up being? I’m guessing closer to your order of magnitude? Excluding scope creep, of course.
- jiggawatts 4y ago
  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.

doctor_eval 4y ago

> 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.

moring 4y ago
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).
chasd00 4y ago
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.
- doctor_eval 4y ago
  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…

nivenkos 4y ago

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.

AnhTho_FR 4y ago
+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.
- karambahh 4y ago
  AFAIK, Avalara is the defacto player on this kind of stuff
  - AnhTho_FR 4y ago
    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...
gbersac 4y ago
If you think that government will give up (should they?) on all that tax money, you're probably fooling yourself...
davedx 4y ago
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!
baud147258 4y ago
> 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

eurasiantiger 4y ago

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.

chasd00 4y ago
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.

Waterluvian 4y ago

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

dijit 4y ago
> Why not javascript specifically? Javascript has one number type; float.
- onion2k 4y ago
  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.
- eurasiantiger 4y ago
  Not true. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - dijit 4y ago
    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?
    - eurasiantiger 4y ago
      Any cryptography is surely using Uint8Array.
      - SgtBastard 4y ago

johnwheeler 4y ago

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

MustardBob12 4y ago

.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.