19 ms·

> Under no circumstances does my engineer brain think this is a good idea. At all. Yeah, if that's the model engineer in the "don't build your own billing syst

by q3k 3y ago

> Under no circumstances does my engineer brain think this is a good idea. At all. Yeah, if that's the model engineer in the "don't build your own billing system" mantra then the article had the opposite effect on me. Now I want to build such a system because this made me feel like I'm significantly more qualified than I previously thought.

arnon 3y ago
Don't do it
- q3k 3y ago
  Now I'll also do it out of spite! :)
  - arnon 3y ago
    Don't say I didn't warn you
jerf 3y ago
Naw, you still don't want to, at least not in a context in which you're billing enough to be a real workout, because the non-engineering aspects will still get you. Like this: https://news.ycombinator.com/item?id=37557989 https://news.ycombinator.com/item?id=37557989 which, in short, refers to the fact that nobody in the company considers billing a system to be designed in the first place, so it gets approached with a truncated Waterfall that doesn't even have a requirements analysis phase, so you'll have no support whatsoever for your attempt to bring higher quality to billing. Also, with all due respect to those working on billing I have seen that it is generally handed to engineers who are, shall we say, adequate for the task but no more, and unless you're 100% greenfielding you're going to be dealing with their stuff no matter what. From another cynical point of view, it is a situation where you can fail miserably and bring great pain to the company that is traced directly to you, but there is no success; a functioning billing system is just what is expected. It's all downside and no upside for you personally. I have a billing system (a component of the larger whole) and I'm pleased to be able to hand it off next month. I've not enjoyed my stay there. Though it was miles better than when I brushed the data lake/data analysis world. If I had to maintain this system for another few years I could and I wouldn't scream if I had to do it again someday. Dealing with the data analysis world beyond just throwing them some data is a "never again".
- specialist 3y ago
  > ...miles better than when I brushed the data lake/data analysis world The data pond, puddle, and lakeside cottage methodology would have spared you that pain. More seriously, my experience with that world reinforced my view that it's all monkey motion (much effort, negative value). Otherwise, spot on summary of IT dev work. Which now applies to "web services" too. I've long been befuddled by the rise of "agile". It's not meant for product dev, right? Well stupid me took forever to realize that most work is actually IT (aka data processing) and not product dev.
  - robertlagrant 3y ago
    > I've long been befuddled by the rise of "agile". It's not meant for product dev, right? It...is?
    - specialist 3y ago
      Is "agile" meant for product dev? IMHO, no. Very loosely, "product dev" projects have concrete deliverables, deadlines, and high cost of change (updates). So therefore are ameniable to PMI-ish critical path like methodologies. (Avoiding the evergreen unresolvable sophistry wrt "waterfall".) The original motivation for "agile" was to protect the dev team from terrible customers (clients). Those who cannot or will not commit to requirements, actively resist any kind of formalism, have no clue what "done" even means. Meaning most IT (data processing) efforts. And now most web stuff. "Agile" is totally rational in those unwinnable situations. Because the dev team would always have something to show for their suffering. Lessening the likelihood of being the scapegoat come the inevitable failure. Unfortunately, "agile" became a fad, a belief system, an identity. Curtailing any kind of introspection. Only in the last few years have we been able to have calm, frank discussions about "agile". Mostly because some of its progenators have broken ranks and done mea culpas.
      - robertlagrant 3y ago
        > Very loosely, "product dev" projects have concrete deliverables, deadlines, and high cost of change (updates). Why? A web based product can iterate, for example. We see the most experimentation in places like Amazon, where they're constantly deploying updates and experiments. Why should such a product have a high cost of change?
bluGill 3y ago
The problem is there are a lot of detail that is different just for the sake of being different and those will suck your soul. There are interesting problems in billing. However most of the issues are another government has a law that is essentially the same as every other government, but some small detail is trivially different so you need to figure out which subset of customers that government covers and then apply those details correctly to them. Nothing hard about this, just the same old tax but the details are annoyingly different. Note that you need to get the above details 100% correct in all cases. They can put you in prison for mistakes (almost always they will just fine the company a lot of money, but they have the right to apply prison and you never know when they will want to make an example of someone)
doctor_eval 3y ago
Despite what jerf said, which I whole heartedly agree with, there are plenty of interesting billing problems for a good engineer to sink their teeth into. But there is also a long, long tail of boring problems that you won’t have time to do properly. To put it a different way: even after you’ve solved the “mathematical” problems of billing, you still need to solve the operational stuff. Like payments integration, GL integration, invoice formatting, tax, reports, etc etc. I think most engineers underestimate both the difficulty of the “mathematical” problems, and the length of the long, relatively boring tail.
jes5199 3y ago
I’ve spent the last 12 years doing payments-and-billing-focused engineering for various companies. Most engineers, in fact, do not want to do this work. It’s like specializing in plumbing for septic tanks, most people have an innate sense of revulsion of self-protection that keeps them from doing it. You screw up the money pipes, and you have a Real Problem. However! The problems are interesting, the challenges are endless, and it’s possible in some orgs to get recognized as the person who is keeping the money flowing. I do have a sense of frustration that every company seems to start off with a bad design for billing, so I’m always cleaning up after negligence… but it pays the bills. Sometimes I think I want to build an open-source billing engine. To show off what it looks like if you do it right. But would that be killing the golden goose? Currently there’s endless demand from people who don’t know.
- 6510 3y ago
  My vision just now was to create a sand box with a DSL (that doesn't use floats) and have others write the rules into it. VAT.include(country, type, amount){ if(type == "high" && country == "NL"){ return percentageOf(price, VAT.NL.high) + amount; } throw new Error("Error in VAT.include: VAT not found."); }

by q3k 3y ago

arnon 3y ago

Don't do it

q3k 3y ago
Now I'll also do it out of spite! :)
- arnon 3y ago
  Don't say I didn't warn you

jerf 3y ago

Naw, you still don't want to, at least not in a context in which you're billing enough to be a real workout, because the non-engineering aspects will still get you. Like this: https://news.ycombinator.com/item?id=37557989 https://news.ycombinator.com/item?id=37557989 which, in short, refers to the fact that nobody in the company considers billing a system to be designed in the first place, so it gets approached with a truncated Waterfall that doesn't even have a requirements analysis phase, so you'll have no support whatsoever for your attempt to bring higher quality to billing. Also, with all due respect to those working on billing I have seen that it is generally handed to engineers who are, shall we say, adequate for the task but no more, and unless you're 100% greenfielding you're going to be dealing with their stuff no matter what. From another cynical point of view, it is a situation where you can fail miserably and bring great pain to the company that is traced directly to you, but there is no success; a functioning billing system is just what is expected. It's all downside and no upside for you personally. I have a billing system (a component of the larger whole) and I'm pleased to be able to hand it off next month. I've not enjoyed my stay there. Though it was miles better than when I brushed the data lake/data analysis world. If I had to maintain this system for another few years I could and I wouldn't scream if I had to do it again someday. Dealing with the data analysis world beyond just throwing them some data is a "never again".

specialist 3y ago
> ...miles better than when I brushed the data lake/data analysis world The data pond, puddle, and lakeside cottage methodology would have spared you that pain. More seriously, my experience with that world reinforced my view that it's all monkey motion (much effort, negative value). Otherwise, spot on summary of IT dev work. Which now applies to "web services" too. I've long been befuddled by the rise of "agile". It's not meant for product dev, right? Well stupid me took forever to realize that most work is actually IT (aka data processing) and not product dev.
- robertlagrant 3y ago
  > I've long been befuddled by the rise of "agile". It's not meant for product dev, right? It...is?
  - specialist 3y ago
    Is "agile" meant for product dev? IMHO, no. Very loosely, "product dev" projects have concrete deliverables, deadlines, and high cost of change (updates). So therefore are ameniable to PMI-ish critical path like methodologies. (Avoiding the evergreen unresolvable sophistry wrt "waterfall".) The original motivation for "agile" was to protect the dev team from terrible customers (clients). Those who cannot or will not commit to requirements, actively resist any kind of formalism, have no clue what "done" even means. Meaning most IT (data processing) efforts. And now most web stuff. "Agile" is totally rational in those unwinnable situations. Because the dev team would always have something to show for their suffering. Lessening the likelihood of being the scapegoat come the inevitable failure. Unfortunately, "agile" became a fad, a belief system, an identity. Curtailing any kind of introspection. Only in the last few years have we been able to have calm, frank discussions about "agile". Mostly because some of its progenators have broken ranks and done mea culpas.
    - robertlagrant 3y ago
      > Very loosely, "product dev" projects have concrete deliverables, deadlines, and high cost of change (updates). Why? A web based product can iterate, for example. We see the most experimentation in places like Amazon, where they're constantly deploying updates and experiments. Why should such a product have a high cost of change?

bluGill 3y ago

The problem is there are a lot of detail that is different just for the sake of being different and those will suck your soul. There are interesting problems in billing. However most of the issues are another government has a law that is essentially the same as every other government, but some small detail is trivially different so you need to figure out which subset of customers that government covers and then apply those details correctly to them. Nothing hard about this, just the same old tax but the details are annoyingly different. Note that you need to get the above details 100% correct in all cases. They can put you in prison for mistakes (almost always they will just fine the company a lot of money, but they have the right to apply prison and you never know when they will want to make an example of someone)

doctor_eval 3y ago

Despite what jerf said, which I whole heartedly agree with, there are plenty of interesting billing problems for a good engineer to sink their teeth into. But there is also a long, long tail of boring problems that you won’t have time to do properly. To put it a different way: even after you’ve solved the “mathematical” problems of billing, you still need to solve the operational stuff. Like payments integration, GL integration, invoice formatting, tax, reports, etc etc. I think most engineers underestimate both the difficulty of the “mathematical” problems, and the length of the long, relatively boring tail.

jes5199 3y ago

I’ve spent the last 12 years doing payments-and-billing-focused engineering for various companies. Most engineers, in fact, do not want to do this work. It’s like specializing in plumbing for septic tanks, most people have an innate sense of revulsion of self-protection that keeps them from doing it. You screw up the money pipes, and you have a Real Problem. However! The problems are interesting, the challenges are endless, and it’s possible in some orgs to get recognized as the person who is keeping the money flowing. I do have a sense of frustration that every company seems to start off with a bad design for billing, so I’m always cleaning up after negligence… but it pays the bills. Sometimes I think I want to build an open-source billing engine. To show off what it looks like if you do it right. But would that be killing the golden goose? Currently there’s endless demand from people who don’t know.

6510 3y ago
My vision just now was to create a sand box with a DSL (that doesn't use floats) and have others write the rules into it. VAT.include(country, type, amount){ if(type == "high" && country == "NL"){ return percentageOf(price, VAT.NL.high) + amount; } throw new Error("Error in VAT.include: VAT not found."); }