by MailNerd on 3/3/22, 12:48 PM with 137 comments
by hyperman1 on 3/3/22, 2:35 PM
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 deployers have no idea what the company is doing. But, anything that might be bad news is career ending, so things get deployed swiftly.
Then comes integration. External team chooses some integration point, probably somewhere in the last head honcho's expensive software, as that'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.
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.
by ihateolives on 3/3/22, 2:15 PM
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 yesterday that there's a better way to build things with SuperFactory.
Manager: No! We already closed that issue!
Dev: No problems. But I thought that now that I have some extra time until...
Manager: Look, Dave, it's working as intended, the solution was reviewed and accepted. I will not create another task. You'll take #7839 next!
[...]
Manager: Hey, Dave, I recall you had some ideas about SuperFactory. It's been acting up lately, they keep creating tickets.
Dev: Nope. None. All gone now.
Manager: But you had, right?
Dev: Yes, but I'd have to start digging in again and I don't have time for that.
Manager: Oh, ok, you're right.
by redleggedfrog on 3/3/22, 3:10 PM
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 the Kafka. Soooooo, it got replaced.
I've seen this a lot more in the last 10 years. I call them "stitcher programmers." They are near useless at providing solutions unless they can stitch together some byzantine Frankenstein'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.
Right sizing a solution is not in their vocabulary.
by ok123456 on 3/3/22, 2:22 PM
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.
by mamcx on 3/3/22, 2:08 PM
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 next-gen tech in their stacks.
Is like a developer that instead of being only "LAMP" + editor, is one that:
- Support Mysql, Postgres, Sql Server, Sqlite, FoxPro, Firebase, DBISAM, redis and in terrible days mongo
- N-variations of csv and alikes, json, toml, yalm, .ini, binaries formats...
- Talk to cobol, web services (SOAP, JSON, RPC, GraphQL), pipes of commands
- Deal with python, java, swift, obj-c, .net, c, c++, c#,, f#, go, rust, js, typescript, css, html
- Test on chrome, safari, firefox, ie (OLD ie)
- Windows, Linux, Mac, iOS, Android, Web
- bash, cmd, powershell
- VS Studio toolchain, LLVM toolchain, OSX toolchain, Android toolchain
- Docker, normal deploy, CI
- Sublime, VS Code, Xcode, IntelliJ, Notepad++, Notepad (as-is), nano and in very bad days, vim
- Have Hardware: M1 laptop, Lenovo Windows machine, iPhone, iPad, Android phone
WHO can be the lunatic that deals with all of this?
ME.
(if you wanna understand why I so grumpy about C, C++, Js, Android, the state of shells, terminals, rdbms, nosql, now you know)
I don'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:
Not matter how SMALL a "company" is, it
NEEDS ALL.
by ziml77 on 3/3/22, 1:21 PM
by evancoop on 3/3/22, 1:35 PM
When an enterprise procurement office buys software, the question is "is there anything it does NOT do that will cause someone to fire me for having purchased it ?"
by squarefoot on 3/3/22, 4:55 PM
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.
by mwcampbell on 3/3/22, 3:05 PM
Edit to add: The article did also mention that accessibility is a must-have feature, though I can't remember now if that bit was there in the original. Sorry if it was.
by exabrial on 3/3/22, 1:58 PM
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 "if we don't do it now, we'll never get the chance to do it!" and edge cases are chased down, delaying the move to production.
by timkam on 3/3/22, 3:42 PM
by VHRanger on 3/3/22, 1:16 PM
Next question
by valw on 3/3/22, 2:57 PM
Er, wasn't it Donald Knuth? https://wiki.c2.com/?PrematureOptimization
by est on 3/3/22, 2:28 PM
by mathattack on 3/3/22, 3:35 PM
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)
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.
by FpUser on 3/3/22, 5:29 PM
by Spooky23 on 3/3/22, 2:05 PM
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/validated annually by somebody. That $90 probably costs is $500.
But… We subscribe to office. Adding teams required zero effort, because of the bundling effect. Slack at the time was going through a PoC/vetting process, but why bother if I have a 80% product. The pitch was that Teams was “free”… although mysteriously the price of Office was revised upward.
by StrangeClone on 3/3/22, 2:10 PM
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.
by mschuster91 on 3/3/22, 1:26 PM
This describes Atlassian stuff just perfectly.
> As the code base gets large, bugs will creep in and become harder to fix.
And this is why automated tests - even if it's "just" end-to-end functional tests - are so important. But most managers aren't willing to give developers the extra budget do set up proper testcases...
by jnash on 3/4/22, 3:47 AM
by imbnwa on 3/3/22, 7:07 PM
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.
by valw on 3/3/22, 3:04 PM
> 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?
Now, I challenge you to find a major bloated software where the main source of overhead is Python interpretation. IME it's always something else, like the surrounding UI framework.
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's any indication recommends against using low-level languages.
by tonyedgecombe on 3/3/22, 2:57 PM
Needless to say more staff seemed to correlate with more bloat.
by pc86 on 3/3/22, 1:47 PM
by Dave3of5 on 3/3/22, 4:41 PM
by browningstreet on 3/3/22, 2:57 PM
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.
by smallerfish on 3/3/22, 4:47 PM
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.
by kazinator on 3/4/22, 6:19 AM
Have you looked at some the VM footprints of the text editors people are using?
by flerchin on 3/3/22, 2:20 PM
by thedonkeycometh on 3/3/22, 1:59 PM
In terms of using "bloated platforms" 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++/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++/Rust before a project has started then you're under the spell/threat of rockstar employees without a care for long term support.
The problematic Enterprise Applications I'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, "this should have been written in xyz", its almost always that the domain knowledge has gone, and alongside it, the source code.
If you'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.
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.
Finally, I've been coming across a lot of developers pining for the "old days" 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're long gone. They got away with it because software was not as ubiquitous, and the internet wasn't around to spread 0-day vulnerabilities, and had very little oversight.