Why enterprise software is bloated • Hacker News Board

Re: Why enterprise software is bloated

#121

Post by Silhouette » Thu, Mar 03, 2022, 8:37 PM UTC

foobarian wrote: post #120

Silhouette wrote: post #118

Earlier quoted context omitted.

Allowing technical debt to accumulate like that will , with near 100% certainty, damage your development activity sooner or later. The only exception is if you've already damaged it critically in some other way. Some contrived example where you might lose significant money because you made a generally good change but it had a bug and that bug was somehow missed by your entire review and testing process and the conseq…

Well. It's not a counter-argument to anything, it's an illustration of how we end up with bad codebases, and why specifically in big enterprises. The incentives are set up exactly in the way that lead to it, particularly by making it expensive to clean up tech debt.

Fair enough if that was the point you wanted to make, though in that case I'd argue that the kind of disaster scenario you described isn't specific to big enterprises but to disastrously bad software development organisations. A lot of small organisations think they're operating at enterprise scale and make the same kinds of mistakes!

Re: Why enterprise software is bloated

#122

Post by Silhouette » Thu, Mar 03, 2022, 8:42 PM UTC

commandlinefan wrote: post #71

adambyrtek wrote: post #39

Earlier quoted context omitted.

I know this is just an anecdote, but a good developer wouldn't ask the manager to approve every small refactoring or expect them to understand the importance of "one method in SuperFactory". They would have instead made a judgement call and taken the responsibility of doing the quick fix.

> wouldn't ask the manager to approve every small refactoring It becomes an issue if it takes more than a day. Scrum, Kanban, RUP, XP, waterfall - whatever "methodology" they say they're following, it boils down to "tell me how long this is going to take and I'll check to see how close what you said was to the time it took". If you can make a change in an hour, sure. If it takes a day, it's going to break your "commi…

Or... Management could choose not run their software development organisation with the kind of micromanagement strategy that requires everything to be allocated in units of one day or less. It's another red flag that has become disturbingly common in the industry and suggests managers more interested in "visibility" and "metrics" than actually doing a good job, sustainably, by trusting their technical people to do theirs.

Re: Why enterprise software is bloated

#123

Post by ok123456 » Thu, Mar 03, 2022, 9:19 PM UTC

yjftsjthsd-h wrote: post #116

bombcar wrote: post #44

Earlier quoted context omitted.

My suspicion is that any "cloud service" that isn't some proof-of-concept one-off is also filled to the brim with bloat, you just don't see it as a customer. "Delete" is the solution, but that is a tool they don't want to use, because every feature somewhere is used by some paying customer, who will complain loudly - and may even move to a competitor. Often the pain of updating and the pain of migrating are similar.

> My suspicion is that any "cloud service" that isn't some proof-of-concept one-off is also filled to the brim with bloat, you just don't see it as a customer. Hey, encapsulation is a decent mitigation to complexity issues.

uh yeah until you need to modify it, then it becomes another complexity issue. Or in the case of 'microservices', now you have to solve a distributed systems problem.

Re: Why enterprise software is bloated

#124

Post by commandlinefan » Thu, Mar 03, 2022, 9:43 PM UTC

Silhouette wrote: post #122

commandlinefan wrote: post #71

Earlier quoted context omitted.

> wouldn't ask the manager to approve every small refactoring It becomes an issue if it takes more than a day. Scrum, Kanban, RUP, XP, waterfall - whatever "methodology" they say they're following, it boils down to "tell me how long this is going to take and I'll check to see how close what you said was to the time it took". If you can make a change in an hour, sure. If it takes a day, it's going to break your "commi…

Or... Management could choose not run their software development organisation with the kind of micromanagement strategy that requires everything to be allocated in units of one day or less. It's another red flag that has become disturbingly common in the industry and suggests managers more interested in "visibility" and "metrics" than actually doing a good job, sustainably, by trusting their technical people to do th…

> Management could choose not

Sure, they could, but they never have.

Re: Why enterprise software is bloated

#125

Post by netizen-936824 » Thu, Mar 03, 2022, 11:36 PM UTC

commandlinefan wrote: post #70

hyperman1 wrote: post #47

An important factor is new manager syndrome. You start with some new head honcho somewhere. A CxO, an Enterprise Architect,... These tend to swap every 3 to 5 years. 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. In practice, expensive software tends to barely work. Also, the deploye…

> the deployers run away in 2 weeks tops Well, they probably didn't run away - they were probably only paid for two weeks tops. The only constant I've ever observed in 30 years of software development is that the people who make decisions think that saving a few thousand dollars in programmer salaries is worth having a business that nobody really understands, that operates at minimal efficiency, and generates unhappy…

Didn't you get the memo? Profit is more important than life itself

/S

Re: Why enterprise software is bloated

#126

Post by yjftsjthsd-h » Fri, Mar 04, 2022, 1:22 AM UTC

ok123456 wrote: post #123

yjftsjthsd-h wrote: post #116

Earlier quoted context omitted.

> My suspicion is that any "cloud service" that isn't some proof-of-concept one-off is also filled to the brim with bloat, you just don't see it as a customer. Hey, encapsulation is a decent mitigation to complexity issues.

uh yeah until you need to modify it, then it becomes another complexity issue. Or in the case of 'microservices', now you have to solve a distributed systems problem.

No, you're still better off having clearly defined boundaries. I will grant that multiple systems can have emergent effects that are more painful to debug, but to the degree that things can actually be made independent I think it helps.

Re: Why enterprise software is bloated

#127

Post by Chris2048 » Fri, Mar 04, 2022, 3:18 AM UTC

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…

That has nothing to do with giving devs lee-way.

If you work without tests/QA, you are shooting from the hip. The scenario above as-such should not happen. If it ties in with million-dollar processes, even more so. What you are saying is "We don't trust our process, so we do as little as possible outside authorised tasks"; Instead, you should fix the process. If this led to post-mortems and process improvements, as in QA/dev process, not simply bug-fixes, then why is the process not improving and/or better trusted now?

Also, the original task is described as a "refactor", so the numbers should not be affected - was was it not just a refactor?

Re: Why enterprise software is bloated

#128

Post by warmwaffles » Fri, Mar 04, 2022, 3:44 AM UTC

StrangeClone wrote: post #29

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. Only part of software optimisation which should be focusing early should be cross cutting concerns like logging, monitoring, authenti…

> Hardware is quite cheap.

Joe Armstrong (Erlang) always joked that if you wanted your program to run faster, just wait a few years and the computing power will increase. I found it to be a profound statement about shrugging about optimizing things needlessly unless it was absolutely necessary.

Re: Why enterprise software is bloated

#129

Post by jnash » Fri, Mar 04, 2022, 3:47 AM UTC

That'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.

Re: Why enterprise software is bloated

#130

Post by theonething » Fri, Mar 04, 2022, 3:59 AM UTC

thedonkeycometh wrote: post #24

exabrial wrote: post #19

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 "hello, world"... but despite that, I don't think that's the root cause. 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…

This is just pure hyperbole. The modular system of javascript is designed explicitly to ensure features can be made when needed. And I'm not sure where you breathlessly pulled 5GB of modules from, to write "Hello World" but I bet its dark and smelly.

> but I bet its dark and smelly.

I'm going to steal that from you and use it for a rainy day if you don't mind. :)