Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why enterprise software is bloated

mailbox.my

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Why enterprise software is bloated

#91

Post by PeterisP »

mwcampbell wrote: post #64

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'd say it's a moral imperative, and that's why it's a legal requirement. I'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 bec…

A big difference is that most of enterprise software is designed for a limited set of internal users, not the general public. If you have a 1000 employees and one of them is blind, then the software used by the department where that person works needs to be accessible to blind people as a reasonable accommodation, but you don't need to make e.g. a random accounting tool used by five specific users accommodate something that none of those five people have. The same applies for physical work such as in a manufacturing environment - you may have to accommodate a particular workbench/tools so that they are usable from a wheelchair (e.g. lowering certain things) but you don't have to redesign all your workplaces for that, that would be bad as it would make them less usable for their current users.

Also, "accessibility" is not a single feature; different aspects of accessibility - for different needs - are quite different, unrelated, separate features.

Re: Why enterprise software is bloated

#92

Post by akitzmiller »

oriolid wrote: post #83
ok123456 wrote: post #38

His "solutions" is to work in "pockets of the industry" that don't have "bloat". (Among one of them is use more cloud services. Which makes me wonder if he's seen some of the engineering disasters people are churning out. This makes me want to just summarily dismiss the whole piece.) The real solution is to systematically address technical debt as part of your development process. Did that feature that someone swore…

For that real solution you need to have a manager who approves spending time on removing unused cruft. Otherwise you'll end up smuggling refactoring inside other tasks, which is terrible for quality control.

I think this is really the crux of the matter. More generally, STABLE management that drives software quality. Even if you're lucky enough to be part of a team that starts of with good management, reorgs, mergers, and turnover are just way too frequent to provide the year-over-year improvements needed for really good, efficient code.

Re: Why enterprise software is bloated

#93

Post by smallerfish »

I think the better question is "why [is] enterprise software so bad?" I'm sure we can come up with a million reasons too.

For examples, just click around the admin interfaces to O365, GApps, or AWS, and I'm sure you can find many annoying issues and/or bugs.

Re: Why enterprise software is bloated

#94

Post by igouy »

teakettle42 wrote: post #69
valw wrote: post #63

Reminder that the Computer Languages Benchmark Game itself recommends against using it to draw general conclusions about performance of languages in real-world apps: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > 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…

> I challenge you to find a major bloated software where the main source of overhead is Python interpretation In every piece of non-trivial software I’ve written in python, the main source of overhead has been Python interpretation. I don’t think it’d be hard at all to meet your challenge.

If it wouldn't be hard at all, we're left to wonder that you don't seem to have tried.

Re: Why enterprise software is bloated

#95

Post by kaba0 »

foobarian wrote: post #80
ihateolives wrote: post #32

In a lot of companies, feature development trumps optimizing, refactoring or removal of legacy code. Dev: Hey Steve, I'm working on issue #4546, but it just occured 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: No. Work on #4546. Dev: Sure, #4546 will be done soon, but it'd be really easy fix, it just occurred to me…

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…

Testing is a thing.

Re: Why enterprise software is bloated

#96

Post by mamcx »

someguydave wrote: post #81
mamcx wrote: post #28

Is easy to blame the wish of people for this (and IS true), but the major point is this: A enterprise NEEDS ALL. I work in this niche (mostly for small companies), and what I see for this past +25 years is that even the most "small" 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…

Why don’t devs and management try to consciously trim that list?

I WANNA. You bet on it.

But I need to install that stuff so I can run the integration, do the tests, see how they work, add a little code of it, etc.

For example, I need to install https://www.elevatesoft.com/products?category=dbisam because just ONE of my customer use it.

Then I need to add ODBC to OSX.

Then I need to install FreePascal, and make some DLL on it so I can decode just ONE field that whole depend on the binary representation that exist there. More fun? That field is where is store the "price" of the product.

Why the heck that developers decide to dump unportable binary, from a certain version of FPC, on that field, hell I know...

Re: Why enterprise software is bloated

#97

Post by Spivak »

redleggedfrog wrote: post #67

The article didn't mention what I have observed as the worst cause of bloat - what I call the "New Toys" problem. 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/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 th…

Look, I obviously don't know the specifics but I think you swung too far on the other side and also just stitching together existing components. A single box running cron is quick and easy but I would be wary of hinging anything non-dev facing on that.

* You can't fearlessly patch the cron box without knowing when the jobs run, I don't want any special cases. Also how would I even know when you have jobs scheduled looking at a fleet -- read your out of date docs? Ew no. So a messaging system, guess the devs were already familiar with Kafka, is necessary to process the jobs across multiple nodes.

* Individual nodes are unreliable and you don't have any durable persistent storage. Most people don't like storing data in Kafka even though it's possible so they went with a database.

* Cron doesn't have any mechanism to give you a history of jobs that isn't built into your script or parsing logs. Ditto with failure notifications. You also can't reprocess failed jobs except manually. Guess you just wait another 4 hours?

* You now also can't duplicate the server because they're both going to try and do the export every 4 hours and step on one another. Woop, you made a system where an assumed safe operation "adding something" breaks stuff.

This kind of thing is a nightmare if you already have queues and a database because why would you stand up another thing but if you had none of that to begin with then yeah... makes total sense.

Like this is the reality of ops and running something "production ready" it's a lot of big ole complex HA platform so that you can run your 5 lines of code and not have to worry about any of the hard problems like availability, retrying, resource contention, timing, data loss, locking.

Re: Why enterprise software is bloated

#98

Post by squarefoot »

In my not very long but significant experience, it often boils down to having no intention to allocate time/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/libraries in place.

Been there done that; there was this 3rd party software module "Y" that exchanged data packets over the network between "X" and "Z", 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't have the sources of that Y module, I could see that it was just passing around packets without performing any functions that couldn'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 "software bureaucracy", which probably boosted even further my decision to run only Open Source software wherever I can.

Re: Why enterprise software is bloated

#99

Post by Karellen »

timkam wrote: post #74

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.

> What is Software Bloat? > > Bloated software uses much more resources than necessary to do its job, the most important resources being CPU time, memory, I/O, and disk space. Furthermore, software with lots of features can also be called bloated since it is harder to learn and use, and naturally requires more resources than software with only the desired features would.

Re: Why enterprise software is bloated

#100

Post by xadhominemx »

kaba0 wrote: post #95
foobarian wrote: post #80

Earlier quoted context omitted.

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…

Testing is a thing.

Ok, but now your “time boxed” half day refactor is two man weeks of testing, bug fixes, back and forth, etc
Post reply on HN