Not Uber related, but as soon as ERP systems or warehouse management or logistics and supply chain management are concerned I sometimes have the impression that a lot of "start-ups" are falling in the same trap. There is simply no way to beat the likes of SAP, Microsoft or even Oracle in the sheer man hours, resources and research spent on their systems. And yes, they are cumbersome and UX sicks. But then they are extremely powerful out of the box, and completely auditable. Maybe it was necessary back when Amazon started due to limitations with webshop integration (or existaznce as far that is concerned). Nowadays not so much.

I can definitely speak to that (having done multiple go-lives for third-party ERPs and WMSes and such for my current employer). There are definitely tradeoffs between going with something off-the-shelf v. developing in-house v. something in-between (e.g. a system that's ostensibly "off-the-shelf" but expected to be heavily customized), and the vast majority of the time you're gonna be best served by something closer to the "off-the-shelf" end of that spectrum, no matter how much you think your "special" business needs warrant it.

That said, a lot of these sorts of systems are notorious for being pretty awful, too. Yes, there are many millions of man-hours poured into them, but that doesn't mean they're good; those man-hours could very well be spent on trying to implement every bell and whistle under the sun while entirely neglecting bug fixes, for example (and - speaking from experience - that is a disturbingly-common example). Also, having a bad UX can (and often is) a fatal problem for such a system (sometimes even in a tragically-literal sense, e.g. with EMR/EHR systems and other medical software); the whole point of business software is to optimize user productivity, so the last thing you want is to make the user's life harder.

So yeah, tradeoffs. If you're gonna fall into the DIY trap, the key would be to not try to replace the entire ERP or entire WMS in one go, but rather to build smaller tools that optimize specific business processes, and make sure those tools stay small and maintainable; any expansion of features should happen through interoperability between tools rather than trying to build a giant bloated tool. If you're thinking "wow, that sounds like the Unix philosophy" and/or "wow, that sounds like microservices", that thought ain't exactly a coincidence.

> completely auditable

The biggest thing that people who try to roll their own fail on is this right here.

Auditable includes financial auditing. It should be possible and simple to reconstruct the state of a customer account at any point in time. What products they had, what discounts and promotions were in place, how they were purchased and what was owed at that exact point in time.

It is scary how many systems cannot be audited this way because the engineers and business owners had no understanding of basic accounting concepts like double entry book keeping.

Systems that are not designed to be easy to financially audit are either going to overbill or underbill customers. It isn’t a matter of if, but when...

Curious, can you elaborate on what “completely auditable” means?

In short: the system should log every operation performed within, and that log should be readily accessible to (authorized) end-users.

For example: let's say you have a warehouse management system, which tracks inventory movements in a warehouse / fulfillment center that ships, say, toothbrushes to customers. Multiple customers call in with complaints about getting blue toothbrushes when they ordered red toothbrushes. Seeing as how this is clearly not an isolated incident (multiple people are upset about not getting the right toothbrush!), it's up to you to find out where in the whole lifecycle of that toothbrush in your warehouse - all the way from when it was received to when it was shipped - that error might be happening. If your warehouse management system is completely auditable, then you'll be able query the transaction log (given perhaps the affected order and item numbers) to work backwards to investigate where the fault occurred, be it in shipping, picking, replenishment, receiving, the vendor, or what have you.

The "incumbent" off-the-shelf ERP and WMS vendors tend to support this sort of comprehensive audit trail much more thoroughly than those writing new ones (whether as an in-house project or as a startup attempting to disrupt the space), simply because those incumbents have already had their hard-earned lessons on why literally every transaction must be thoroughly logged (whereas the newcomers and DIYers typically have not, or are in the process of learning as they encounter more and more situations where that audit trail is necessary).

That. Also the financial aspect of any transaction is important. Just this week I had a chat concerning point-of-sales systems with an accountant in Germany. Tax authorities require that any record has to be impossible to alter afterwards. Same goes for ERP systems, every transaction has to be able to be backtracked, every change has to the books has to be recorded.

Any system, e.g. SAP, that has a proofen track record in that, that is SOX compliant, is a huge benefit in that regard. Also for the company itself, IMHO, as the company is forced to work in compliant ways that just make life a lot easier.

where I am, it means “so-and-so took such-and-such an action with these permissions at this time” which can be correlated with things like “this was the exact configuration of the entire system at the time” with reliability and immutability, across multiple versions.

On the other hand this probably is a huge advantage that Amazon has.

Bazel is a ground-up rewrite. Its not related to Blaze apart from naming. There was a skylark project aiming to combine the two over time, not sure how the progress is going on for it.

Bazel is the open-source name of Blaze. It's the same codebase. Blaze has a few Google-specific modules (e.g. integration with internal tools, some legacy Google-specific rules).

Skylark (renamed Starlark) is the extension mechanism. It's exactly the same in Blaze and Bazel.

Source: I work on Blaze/Bazel, and I'm the lead for Starlark.

Could you talk about why Blaze was renamed? I'm guessing it was for SEO reasons so you actually got correct responses outside of moma or whatever it's called.

For legal/trademark reasons.

> Its not related to Blaze apart from naming.

And functionality (and architecture?); I started my career at Google, and am now at a mid-size place that uses Bazel and it's almost identical from an interface perspective

"Blaze" is littered all around the code base [0].

[0] - https://github.com/bazelbuild/bazel/search?q=blaze&unscoped_...