And this is why you decouple your systems as good as possible. The humans in your company need to be able to just prolong premium times manually. When the customer pays in diamonds. Or you want to say thank you to someone and add half a year for free. Ir you decide to accept payments in bitcoin tomorrow.

Never build the payment system tight coupled to the rest. Humans need to be able to overrule anything, anytime.

This should be a rule of thumb for everything.

Yup, this was a lesson I learned the hard way when I built out billing for our SaaS product. I had spent weeks thinking about user accounts, team accounts, subscription, integration with Stripe, how the UI would look, how I would verify VAT numbers for European customers, etc etc etc. In the end I threw all the code away because not a single customer that we had would have used self-checkout billing anyway, everything happens via email, purchase orders, billing portals like Ariba, etc. Monthly subscriptions are far and few between, pay-per-use is something that almost no customer would be interested in. Some customers actually wanted multi-year subscriptions, which Stripe doesn't even support.

It's emails and spreadsheets all the way down if you're building a product for an Enterprise audience.

Based upon this series of postings, it sounds like the problems in the original tweet are the result of decoupled enterprise payment systems, rather than the opposite. As if someone somewhere forgot to manually flip some flag or that they paid wasn't properly distributed throughout the byzantine distributed system.

The GGP used the wrong term. What he describes is a system that is overridable, not decoupled.

You are right in that decoupled systems aren't good.

I agree, but herein lay the rub.

For every exception, you need someone on top of it. You have a limited pool of people to distribute this knowledge to, and the responsibility for maintaining this knowledge to even if that just invoves knowing where to look to figure something out.

Overrides are tricky to accomodate, standardize, and organize if you don't nail dpwn the appropriate data model for the process.

I think this class of issues partly comes from that sales people have much relaxed, politics focused cognition compared to engineers, and are in disregard of non-human entities. They don’t have distinction between MUST or SHALL or SHOULD, everything is MAY or at best RECOMMENDED, and everything you may say or do must be attributed to a person.

So when told there is this thing which must be done by sales that prevents machines doing what that affects customers, it’s interpreted as either an IT guy is making incomprehensibles or hypotheticals because machines cannot be subject of a sentence, and as an empty demand with no return because neither party gains credits from the conversation.

And we’ll end up in “I told you! You had to!” “Told you what? You didn’t say anything”.

> Humans need to be able to overrule anything, anytime.

This needs to be a guiding principle of anyone who builds any sort of software.

This. "I can't do this, the computer doesn't let me" ought to be as absurd a statement as "I can't do this, the intern doesn't let me".

I'm not sure this is necessarily a good rule of thumb. There are plenty of times humans need to be protected from themselves--that's why regulation exists to prevent fraud, etc. It'd be ludicrous for a single sales employee to override payments right into their personal account.

It is SOFTware so it can always be changed. The question becomes who can do the changes and when (which ends up being much trickier to answer)

Especially in avionics...

Saab sells a plane where moving the controls manually does not disable the autopilot....

This is all well and good if you build your product from the beginning with the vision that it will some day be sold by sales people to huge companies. But if your expectation is that it will always be self service, a bunch of design and engineering work to make it flexible just looks like wasted effort. If you guess wrong in either direction in your early development you'll have problems. Either get to market more slowly because you spent time up front building for a future that may never come, or get to market quickly and deal with the repercussions later.

It can be both. AWS and Google in particular (Microsoft was obviously always an enterprise company) started out the individual credit card route and I'd argue a major reason they've been able to grow--AWS better than Google modulo GSuite--is that they recognized they actually needed an enterprise sales force and the things that are associated with it.

Google has been exceedingly difficult to work with from an Enterprise standpoint. We spend millions with them for Google Workspace and I don't even know our account executive's name, nor have we ever talked with them if we even have one. Everything is done through our VAR.

In the meantime I'm well aware of and speak to our Microsoft rep regularly, they know our business and what we need, and have been helping round up resources for upcoming projects and initiatives. It's night and day between MS and Google.

It seems like Google thinks their products are so perfect and infallible that they can cut out the human element entirely. That may work for personal Gmail accounts and such but not so great when you spend millions with them.

Isn’t it the point of a VAR that the VAR, not the vendor, owns the client relationship?

Yes but we still have relationships directly with our other vendors (Microsoft, AWS, Oracle, Red Hat, Cisco, VMware, the list goes on).

Despite buying all those through a VAR we still have account managers/executives, dedicated systems engineers that we work with directly at the vendor, except Google.

"Sometimes there will be bugs."

Having human overrides to correct or change data is equally useful for just fixing what you get wrong yourself, as it is for special cases.

This sounds terrifying in its own way, but one of the best decisions I made at a tiny (5 person) startup a few years ago was sitting the smart, non-technical CEO down and teaching him SQL. All our data lived in a Postgres database, and he was amazed by the sort of questions he could ask the database. I showed him some SQL desktop tool (and helped him set it up). And showed him some different sql queries he could run and how to export data into CSV for excel. He instantly understood the “single source of truth” idea and why data modelling was important. He was gleeful about being able to change content on the website without asking someone else to do it for him.

I’m sure he’ll make a mess of something down the line, and I hope someone after my time added audit logs (to track what he inevitably changes and breaks). But there’s something deep and important in empowering other aspects of the business to interact with the computing silo. There’s a time for automation. And there’s a time before that where custom tooling isn’t worth building yet. And just changing records manually is the right approach.

And then bunch of naive idealists build system for payments without most important feature - reversibility. Of course, it's used only for speculation and illegal stuff.

So who decided to get "new leadership"?

The board of directors replaced a founder CEO with an external CEO, new CEO hired a new exec team. Edit: To clarify, things were going well, but the company was scaling and the founder did not want to be CEO of a large company because he wanted to mostly focus on product stuff. So he worked with the board to bring in a "professional" CEO.