Why enterprise software is bloated • Hacker News Board

Re: Why enterprise software is bloated

#101

Post by mwcampbell » Thu, Mar 03, 2022, 5:03 PM UTC

PeterisP wrote: post #91

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 somethi…

> 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

What if that team then wants to hire a sixth person, and one of the qualified candidates is blind (or has some other disability that's relevant for software)? If accessibility isn't the default, it's too easy to pass on qualified candidates in a category where many struggle to find work.

Re: Why enterprise software is bloated

#102

Post by b3morales » Thu, Mar 03, 2022, 5:05 PM UTC

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…

Absolutely. At root, this is the management version of xkcd: Standards https://xkcd.com/927/ Possibly no human endeavor is immune to it without deliberate steps.

Re: Why enterprise software is bloated

#103

Post by geodel » Thu, Mar 03, 2022, 5:24 PM UTC

adambyrtek wrote: post #39

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…

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.

IME in SAFE® Agile™ world developers are fully empowered to not take decision on things which are domain of enterprise architects/ Product manager or leadership calls.

Re: Why enterprise software is bloated

#104

Post by projektfu » Thu, Mar 03, 2022, 5:25 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…

Except in XP the developer will refactor before and after implementing the feature, the customer doesn’t get to say how things get done, and there is no “manager” role.

Not to say that people don’t operate completely differently and call it XP. That’s always a problem. But it isn’t “No True Scotsman”, it’s literally just not following the recipe and expecting the cake at the end.

Re: Why enterprise software is bloated

#105

Post by FpUser » Thu, Mar 03, 2022, 5:29 PM UTC

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

Re: Why enterprise software is bloated

#106

Post by kodah » Thu, Mar 03, 2022, 5:46 PM UTC

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…

Managers should never drive technical decision making. This is one of the key offenses some companies continue to commit; they let managers think that they're still engineers. A manager, imo, needs to be paired with an engineer that has the same scope and adjacent level as the manager so that things like this don't happen.

Re: Why enterprise software is bloated

#107

Post by rightbyte » Thu, Mar 03, 2022, 5:50 PM UTC

ihateolives wrote: post #27

rightbyte wrote: post #21

Earlier quoted context omitted.

I thought the example was convincing until I got a child myself. The hard part is getting the legs and arms in. The 10 buttons are easy.

> The 10 buttons are easy. Yes, until you reach the 9th buttonhole, but you've already used up all the buttons.

Perfection is the enemy of good.

Re: Why enterprise software is bloated

#108

Post by goto11 » Thu, Mar 03, 2022, 6:04 PM UTC

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…

Dev: If we just rewrite everything in Ruby on Rails and Coffeescript, our productivity will go through the roof after a short time investment.

Manager: Sounds great, let me know when you are finished.

Re: Why enterprise software is bloated

#109

Post by ozim » Thu, Mar 03, 2022, 6:15 PM UTC

ziml77 wrote: post #4

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

Funny thing happens when you start asking real money for features ... suddenly it turns out that customers can make changes in their workflows.

Re: Why enterprise software is bloated

#110

Post by imbnwa » Thu, Mar 03, 2022, 7:07 PM UTC

The problem in Enterprise is that the environment is designed to fracture the Engineering team as much as possible so that it isn't capable of collective bartering. This is the point of most de facto Agile SCRUM applications: if I, a manager, can'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 train you into providing the estimates and deliverables I so desire, which have nothing to do with efficiency.

Because of this leverage, technical debt quickly stacks up as everyone is policing themselves and others to not do the unanimously agreed upon 'right thing' to deliver a more cohesive software infrastructure; my god is cohesion 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 'everything-at-once-per-quarter' releases instead of CI, the distinct aggregation of 'flags' over parsing data structures, etc.

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 'shut up and dribble'. 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.

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.