Why enterprise software is bloated

Another consideration a lot of people don't really have is that enterprise software needs to answer a ton of other requirements that Joe Rando's Cloud App doesn't really care about.

Employers in the US can face consequences if they use software that doesn't have accessibility features, thus not complying with the ADA.[1] Clients of theirs can also sue.[2]

Some countries have multilingual requirements[3], not to mention the markets an enterprise loses out on by not having translations in dozens of other languages.

Enterprise software often has to be built and sold with the idea of scalability ingrained. Flexibility in scale here is where you get a lot of sales, e.g.: "WidgetSys can scale to support 1 million concurrent users". Some customers legitimately need that. This can also help deal with demand spikes, such as tax season, school registration "season", etc.

Some places have strict compliance requirements that don't make sense for most businesses. Most businesses probably don't care about FIPS-140-2, but some do because of who their customers are. Because of this, many pieces of enterprise software require incredibly fine-grained control over audit data.

Some require the ability to connect to LDAP, AD, and OAuth sources (sometimes all three at the same place).

Just this list represents features that can impact "bloat" but a "lean" app often doesn't have. This can get a business in trouble.

Now, the next question is obviously: Doesn't it make sense to have a user-specific build of the software. For example, if I don't need AD/LDAP access, can't I just get an OAuth only version? This doesn't work for a few reasons but let's assume it could. Now you have X versions * Y features worth of SKUs for your software.

It's also worth noting that while a lot of this stuff is huge on disk (relatively speaking) it often doesn't actually need to load and run all of that code. A lot of well-designed enterprise software is designed to essentially enable/disable functionality in a modular way because of it. They also tend to have many SKUs but segment it out along lines that make sense, e.g.: SQL Server Express edition is pared down SQL Server Standard missing a bunch of these features.

An easy way to look at this from the American perspective is to preface every feature tick box with "will the company be sued if we don't support ..." -- at least that's been my experience.

[1]: https://www.ada.gov/civil_penalties_2014.htm

[2]: https://www.nad.org/2016/09/06/the-nad-and-hulu-reach-agreem...

[3]: https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26164

The question is: what is bloat? Is everything that depends on Electron bloated? I'd say yes, and there's a lot of non-enterprise software that uses electron. So I'd rather say what is special about enterprise software are UI/UX-trade-offs that are unimaginable for consumer software. And these trade-offs are often (not always) reasonable.

You are missing broader point here. If something is in production and burning cash, it can be replaced with optimised code if system are decoupled. But forcing optimisation earlier will make your developers less impactful and loose interest in the project or job. Most business logic code is updated frequently due to change in requirements and spending 100s of hours for feature which will be used by just small set of users is bad investment. This strategy can help you release some feature faster, get it A/B tested and once you have scaled enough you can start focusing on the individual decoupled system to be optimised.

Not totally sure.

https://ubiquity.acm.org/article.cfm?id=1513451

> Every programmer with a few years' experience or education has heard the phrase "premature optimization is the root of all evil." This famous quote by Sir Tony Hoare (popularized by Donald Knuth) has become a best practice among software engineers.

But the reason this happens is because of previous painful experiences like the following:

Dev: Hey Steve, I'm working on issue #2312, but it just occurred to me that that if I could just refactor that one method in SuperFactory it'd make code much cleaner and easier to reuse. Just a quick fix!

Manager: Huh. How much more work is it? If you can time-box it to half a day then go ahead.

Dev: Great, it should take just a couple of hours!

The change is merged and deployed, and several weeks go by...

Data Science: Hi team, we are wondering if you know if anything changed in this module in the past couple of weeks. The numbers from non-English speaking domains tanked.

Manager: Uh oh

Dev: Uh oh

Data Science: We just look at data in aggregate with significance only reached with weeks of collection. But at this point it looks like we lost millions of dollars.

Manager: oh shit

Dev: faints

... followed by weeks of post-mortems, meetings, process improvements, if not outright terminations.