Why enterprise software is bloated

An important factor is new manager syndrome.<p>You start with some new head honcho somewhere. A CxO, an Enterprise Architect,... These tend to swap every 3 to 5 years.<p>Head honch sees horrible bloat, and decides to Act with some Master Plan. This entails buying some expensive software, deployed by a random external team, that will solve everything.<p>In practice, expensive software tends to barely work. Also, the deployers have no idea what the company is doing. But, anything that might be bad news is career ending, so things get deployed swiftly.<p>Then comes integration. External team chooses some integration point, probably somewhere in the last head honcho&#x27;s expensive software, as that&#x27;s the only thing where the design is not yet completely forgotten. There will be impedance mismatch, i.e. bad news, i.e. unspeakable. So people do something, anything to forcibly connect A to B.<p>Someone presses start, then the deployers run away in 2 weeks tops. All kinds of weird crimes are done by the new expensive software. Bad news is still not welcome, but things start to hurt more and more over the next few months. Staff was already overworked, so does some quick and dirty fixes. Head honcho falls out of grace, a reorg destroys every shred of knowledge gathered in the exercise, and a new new head honcho floats to the top. The cycle starts again.

<i>In a lot of companies, feature development trumps optimizing, refactoring or removal of legacy code.</i><p>Dev: Hey Steve, I&#x27;m working on issue #4546, but it just occured to me that that if I could just refactor that one method in SuperFactory it&#x27;d make code much cleaner and easier to reuse. Just a quick fix!<p>Manager: No. Work on #4546.<p>Dev: Sure, #4546 will be done soon, but it&#x27;d be really easy fix, it just occurred to me yesterday that there&#x27;s a better way to build things with SuperFactory.<p>Manager: No! We already closed that issue!<p>Dev: No problems. But I thought that now that I have some extra time until...<p>Manager: Look, Dave, it&#x27;s working as intended, the solution was reviewed and accepted. I will not create another task. You&#x27;ll take #7839 next!<p>[...]<p>Manager: Hey, Dave, I recall you had some ideas about SuperFactory. It&#x27;s been acting up lately, they keep creating tickets.<p>Dev: Nope. None. All gone now.<p>Manager: But you had, right?<p>Dev: Yes, but I&#x27;d have to start digging in again and I don&#x27;t have time for that.<p>Manager: Oh, ok, you&#x27;re right.

The article didn&#x27;t mention what I have observed as the worst cause of bloat - what I call the &quot;New Toys&quot; problem.<p>For example, you need a process to export data every 4 hours, with some visibility of success and failures. I could have written a cron job&#x2F;scheduled task in 4 hours and be done. What I found instead is Kafka with node.js and couch.db. Yes, for that one export. Not only that the were paying monthly for the Kafka. Soooooo, it got replaced.<p>I&#x27;ve seen this a lot more in the last 10 years. I call them &quot;stitcher programmers.&quot; They are near useless at providing solutions unless they can stitch together some byzantine Frankenstein&#x27;s monster from existing tech, usually with extreme overkill. On the front end is the worst with React and thousands of dependencies for simple forms.<p>Right sizing a solution is not in their vocabulary.

His &quot;solutions&quot; is to work in &quot;pockets of the industry&quot; that don&#x27;t have &quot;bloat&quot;. (Among one of them is use more cloud services. Which makes me wonder if he&#x27;s seen some of the engineering disasters people are churning out. This makes me want to just summarily dismiss the whole piece.)<p>The real solution is to systematically address technical debt as part of your development process. Did that feature that someone swore up and down would be your money maker three years ago not pan out? Delete. Is that abstraction leaky and not that useful? Delete. Are there code paths that never get used and are more or less untested? Delete or assert they never happen.

Is easy to blame the wish of people for this (and IS true), but the major point is this:<p>A enterprise NEEDS ALL.<p>I work in this niche (mostly for small companies), and what I see for this past +25 years is that even the most &quot;small&quot; of all companies have a HUGE array of needs, apps, data to work, laws to comply, demands of suppliers AND their customers (that RECURSIVELY add bloat!), both ancient, current, modern, and next-gen tech in their stacks.<p>Is like a developer that instead of being only &quot;LAMP&quot; + editor, is one that:<p>- Support Mysql, Postgres, Sql Server, Sqlite, FoxPro, Firebase, DBISAM, redis and in terrible days mongo<p>- N-variations of csv and alikes, json, toml, yalm, .ini, binaries formats...<p>- Talk to cobol, web services (SOAP, JSON, RPC, GraphQL), pipes of commands<p>- Deal with python, java, swift, obj-c, .net, c, c++, c#,, f#, go, rust, js, typescript, css, html<p>- Test on chrome, safari, firefox, ie (OLD ie)<p>- Windows, Linux, Mac, iOS, Android, Web<p>- bash, cmd, powershell<p>- VS Studio toolchain, LLVM toolchain, OSX toolchain, Android toolchain<p>- Docker, normal deploy, CI<p>- Sublime, VS Code, Xcode, IntelliJ, Notepad++, Notepad (as-is), nano and in very bad days, vim<p>- Have Hardware: M1 laptop, Lenovo Windows machine, iPhone, iPad, Android phone<p>WHO can be the lunatic that deals with all of this?<p>ME.<p>(if you wanna understand why I so grumpy about C, C++, Js, Android, the state of shells, terminals, rdbms, nosql, now you know)<p>I don&#x27;t mean I fully deep dive to ALL of this, but I need to at least HAVE it or install, or touch it here and there. Is like I say:<p>Not matter how SMALL a &quot;company&quot; is, it<p>NEEDS ALL.

Because every customer needs different features. No one wants to make their workflow follow what the software dictates, they want the software to support the workflow the business uses

When a private citizen buys software, the question is &quot;does it do enough, for the price, for me to buy it?&quot;<p>When an enterprise procurement office buys software, the question is &quot;is there anything it does NOT do that will cause someone to fire me for having purchased it ?&quot;

In my not very long but significant experience, it often boils down to having no intention to allocate time&#x2F;resources for optimization (just convince the customer their hardware is obsolete, and possibly be the one who scores a sale of new hardware) and contracts with other parties that force developers to keep old software modules&#x2F;libraries in place.<p>Been there done that; there was this 3rd party software module &quot;Y&quot; that exchanged data packets over the network between &quot;X&quot; and &quot;Z&quot;, supposedly doing complex operations, and my company was developing both X and Z. I was in the Z developers team. We had all protocols documentation, so although I didn&#x27;t have the sources of that Y module, I could see that it was just passing around packets without performing any functions that couldn&#x27;t be easily integrated in either X or Z, I mean really 2 hours of work in a government project that lasted years, so I asked about the opportunity to some colleagues who confirmed that getting rid of that module was a no-no because by contract we were forced to partner with that company, therefore we had to keep their module that essentially did nothing but passing packets (and money). I recall my immediate thought was &quot;software bureaucracy&quot;, which probably boosted even further my decision to run only Open Source software wherever I can.

The article strikes me as being dismissive about accessibility, merely describing it as a legal requirement and source of bloat. For a lot of software, I&#x27;d say it&#x27;s a moral imperative, and that&#x27;s why it&#x27;s a legal requirement. I&#x27;m afraid that the treatment in this article will encourage developers to ignore accessibility in useful applications that could in principle be accessible, and these applications will then become required for jobs, education, etc., thus erecting new barriers for disabled people. But now that someone has directly linked accessibility to bloat, I guess I should make sure that my own in-development solution for cross-platform GUI accessibility [1] can never be described as bloated.<p>Edit to add: The article did also mention that accessibility is a must-have feature, though I can&#x27;t remember now if that bit was there in the original. Sorry if it was.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;AccessKit&#x2F;accesskit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;AccessKit&#x2F;accesskit</a>

One only needs to look at the language he suggested, Javascript, to see an example of incredible bloat with the 5gib of modules it brings it to do print &quot;hello, world&quot;... but despite that, I don&#x27;t think that&#x27;s the root cause.<p>It has to do everything with poor management of features and lack of leadership. Software _should_ be developed as features are needed. Average humans are absolute crap at predicting things like markets or what will actually be used in production. The translates to developers wasting tons of time on features that provide little value. Lack of leadership and communication of a clear business vision contributes to a panic mentality &quot;if we don&#x27;t do it now, we&#x27;ll never get the chance to do it!&quot; and edge cases are chased down, delaying the move to production.

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

Because checking off features matter more than usability when a manager is the one buying it instead of the person using it<p>Next question

&gt; Sir Tony Hoare famously said: “Premature optimization is the root of all evil.”<p>Er, wasn&#x27;t it Donald Knuth? <a href="https:&#x2F;&#x2F;wiki.c2.com&#x2F;?PrematureOptimization" rel="nofollow">https:&#x2F;&#x2F;wiki.c2.com&#x2F;?PrematureOptimization</a>

My experience is enterprise software is not really engineering-problem solving, more like an organizational-relationship glue. And it&#x27;s a fragile and moving target and makes developers feel less accomplishing.

Funding models are important too.<p>If only “capabilities” or “functionality” gets engineering budget, then improvements without a business sponsor don’t get done. It’s also easier to find funding for a project that has a great dollar benefit to one payer than an improvement with a broader and fuzzier purview. Sometimes this happens under the guise of “turning tech spending from fixed cost to variable.” (The irony is this usually increases costs)<p>The best orgs get around this by putting a tax on technology budgets. “No matter what you spend, we need one dollar out of 5 more to pay for then sins and debt of our predecessors.” Or call it Kaizen or Continuous Improvement if you need. If they don’t trust you to spend that money wisely, they shouldn’t trust you to build anything new either.

I have witnessed quite a few enterprise software projects. My take on it is that quite often - the decisions that should&#x27;ve been made on tech level are being made by company politicians instead and the general tendency to hire at mediocre level.

Easy. A marginal purchase of software in an enterprise is expensive in human terms. Adding a feature and notching the price up is trivial.<p>Case in point, I manage an org with a $200M budget. I have a budget line for a $90 software item for some VIP somewhere that has to be justified&#x2F;validated annually by somebody. That $90 probably costs is $500.<p>But… We subscribe to office. Adding teams required zero effort, because of the bundling effect. Slack at the time was going through a PoC&#x2F;vetting process, but why bother if I have a 80% product. The pitch was that Teams was “<i>free</i>”… although mysteriously the price of Office was revised upward.

Hardware is quite cheap. Even with bloated software companies are making ton of money. Software developers like to optimise resource but never have enough time for this as business requirements itself keep changing. Time to market and engineering resource required are bottlenecks here.<p>Only part of software optimisation which should be focusing early should be cross cutting concerns like logging, monitoring, authentication, etc. Business logics should be separated from these and optimised only when required. Consuming more resource is better than rewriting business logics and fixing bugs.

&gt; Usually only the minimal amount of work will be done to get an integration to work, skipping the refactoring or code changes to internal data structures or algorithms, so the “new” product will be the sum of its parts also from a resource consumption point of view.<p>This describes Atlassian stuff just perfectly.<p>&gt; As the code base gets large, bugs will creep in and become harder to fix.<p>And this is why automated tests - even if it&#x27;s &quot;just&quot; end-to-end functional tests - are so important. But most managers aren&#x27;t willing to give developers the extra budget do set up proper testcases...

That&#x27;s an easy one: follow the money. Enterprise developers are not rewarded for making beautiful, fast, and user friendly software. Enterprise developers are rewarded for getting functionality needed by the business done NOW. Nobody making money decisions care about the actual users. The fact that it takes forever to do even simple things in the software is irrelevant. As long as the business gets done.

The problem in Enterprise is that the environment is designed to fracture the Engineering team as much as possible so that it isn&#x27;t capable of collective bartering. This is the point of most de facto Agile SCRUM applications: if I, a manager, can&#x27;t get the estimate I want from you, I can get it from someone else or I can coerce you into the estimate I want indirectly by shoving the burndown chart, or any other weaponized metric, into your face to <i>train you</i> into providing the estimates and deliverables I so desire, which have nothing to do with efficiency.<p>Because of this leverage, technical debt quickly stacks up as everyone is policing themselves and others to not do the unanimously agreed upon &#x27;right thing&#x27; to deliver a more cohesive software infrastructure; my god is <i>cohesion</i> the least likely property of enterprise stacks, at least in my experience, hence: all the local heroes, the mounds of manual testing and lack of automation, the &#x27;everything-at-once-per-quarter&#x27; releases instead of CI, the distinct aggregation of &#x27;flags&#x27; over <i>parsing data structures</i>, etc.<p>It is impossible that people are working in such circumstances and are just entirely unaware that things could be better; there is an immense amount of pressure from all sides to essentially &#x27;shut up and dribble&#x27;. But that also facilities an environment where individuals or teams are just implementing whatever in their own little kingdom so long as it gets in before the sprint is done. My org alone has three different ways of doing the same exact thing amongst three different teams.<p>Engineering teams should be reviewing the product roadmap as an independent entity and deliberating on how to approach that collectively. A Director of Engineering is the tie breaker. Estimates come from the team, not individuals, or even individual teams.

Reminder that the Computer Languages Benchmark Game itself recommends against using it to draw general conclusions about performance of languages in real-world apps: <a href="https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;why-measure-toy-benchmark-programs.html" rel="nofollow">https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;...</a><p>&gt; We are profoundly uninterested in claims that these measurements, of a few tiny programs, somehow define the relative performance of programming languages aka Which programming language is fastest?<p>Now, I challenge you to find a major bloated software where the main source of overhead is Python interpretation. IME it&#x27;s always something else, like the surrounding UI framework.<p>The Office suite is written in C++ and is badly bloated, obviously not because of language execution overhead but because of technical debt, which if that&#x27;s any indication recommends <i>against</i> using low-level languages.

Back when I was consulting it always surprised me how broadly similarly sized firms would have massive differences in the size of their IT departments. One company might have 100 developers then you would go down the road to their competitor to find they only needed 10.<p>Needless to say more staff seemed to correlate with more bloat.

The first point tracks with my experience building in-house software for a publicly traded Enterprise healthcare company. I think in our case it was a byproduct of having one person on the business side who &quot;owned&quot; every application. So anything they thought was important, they wanted as a feature in &quot;their&quot; app. It didn&#x27;t matter if that feature existed in this other app, that they also used often. If it wasn&#x27;t in &quot;their&quot; app, they would complain - usually to the VP or SVP level, and let it trickle down the multiple layers until it reached development. It got so bad when we were talking about what we were working on we&#x27;d say &quot;today I&#x27;m working on the $NAME web app and tomorrow on the $OTHER_NAME mobile app.&quot;

Because features trump everything else when it comes to enterprise software. Teams are often working in Parallel on features and so will duplicate work until the whole thing becomes a giant mess.

Working in enterprise software: very curious how many entrenched enterprise solutions don’t have enterprise features (SSO, etc) and look&#x2F;feel 20 years old. Spend a lot of time migrating to replacement platforms that do. Entrenched players do nothing to upgrade basic enterprise feature set. Rinse, repeat.<p>Every customer replacing the legacy solutions is doing the work that the legacy org won’t do. The purpose of a solution is to build once the thing all your customers need. This dynamic is the exact inverse of that.

I think the better question is &quot;why [is] enterprise software so bad?&quot; I&#x27;m sure we can come up with a million reasons too.<p>For examples, just click around the admin interfaces to O365, GApps, or AWS, and I&#x27;m sure you can find many annoying issues and&#x2F;or bugs.

Enterprise software is bloated? What?<p>Have you looked at some the VM footprints of the <i>text editors</i> people are using?

ItsHonestWork.jpg

I think this is quite unfair to Enterprise development. There are several business reasons to not use off the shelf scripts or libraries, namely licensing, governance, security, and support, all of which add perpetual costs and further 3rd party governance to any project, specially those in large Enterprises. Very rarely does any business prepare for this at the planning stage, even more so when the software is siloed within a business unit.<p>In terms of using &quot;bloated platforms&quot; like Javascript and Python, I get a whiff of superiority from OP as there simply is no reason to build for size or speed unless it is part of the deliverable feature set. Nobody in their right mind would be writing serverless functions in C++&#x2F;Rust or a Windows form to enter timesheet information (UX is about design, not platform, and is always seen as a secondary cost). If you are determined to use C++&#x2F;Rust before a project has started then you&#x27;re under the spell&#x2F;threat of rockstar employees without a care for long term support.<p>The problematic Enterprise Applications I&#x27;ve worked on all had the same things in common, a bad maintenance plan or an expectation that the software will last decades without change. It was never, &quot;this should have been written in xyz&quot;, its almost always that the domain knowledge has gone, and alongside it, the source code.<p>If you&#x27;re in a business, expecting to exist in decades time, using a moving target to host your systems, like any OS, you better look at the long game, as well as the short, and factor in versioning, source control and inevitable bit rot. Its not about how old it looks, or how fast it could be.<p>Ultimately, there is a massive desire for businesses to offload development entirely via no-code platforms like PowerApps and absolutely no desire to make code that requires more expensive technical hires to maintain, or add more process to manage.<p>Finally, I&#x27;ve been coming across a lot of developers pining for the &quot;old days&quot; where you could change change things willy nilly and release it, without writing tests or having code reviews. These were the bad old days, and they&#x27;re long gone. They got away with it because software was not as ubiquitous, and the internet wasn&#x27;t around to spread 0-day vulnerabilities, and had very little oversight.