Earlier quoted context omitted.
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
No post body was provided.
Why enterprise software is bloated
111–120 of 144 posts
Re: Why enterprise software is bloated
#112Earlier quoted context omitted.
While I agree with you, some managers micromanage and freak out for any change that isn't directly related to doing or fixing X. They will reject the change and it becomes painful to keep working like that because they hold it against you. Toxic workplaces exist.
And in a market where developer skills are in incredibly high demand and a new job can be lined up in a couple of weeks, such workplaces should cease to exist due to lack of developers.
To the average hackernews, lucrative tech jobs may grow on trees, but that is not the case for everyone, even those with technical skill. It usually takes me between three and six months to get a new job.
Re: Why enterprise software is bloated
#113Earlier quoted context omitted.
Magnets are dangerous for children of they swallow them. Unless it is a magnet strip I would prefer buttons.
The magnets are well embedded in the clothes so there's little danger there. The reality is it doesn't do much more or less than normal onesies but costs an insane amount more. Also sticks to the side of the wash machine lol.
That sounds handy. Parent sticks the baby on the side of the washing machine and can now load it using two hands.
Re: Why enterprise software is bloated
#114In 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…
Left a job in 2020 over exactly that. Our customers loved when we could fix/build features in a week, but after 18 months the bloat made it impossible to ship a new feature in the same month. I actually went behind my manager's back and did a full re-write (~25k sloc down to ~15k) at the 8 month mark, but the 2nd time he put his foot down and said absolutely not. I left within a 6 months of that discussion.
What do you mean by the 2nd time? Did you rewrite the whole thing again some amount of time later?
Re: Why enterprise software is bloated
#115The 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…
I don't think "stitching" is the problem per se; taking off-the-shelf parts can be a good thing or a bad thing depending on the parts and how they're used. I mean, is there any difference between stitching together cron and a couple shell scripts vs stitching together kafka and node, other than how many components are and how well suited they are to the job and environment? It sounds like your problem is with people who have new-shiny syndrome and try to force their latest interest into their work regardless of whether it makes sense.
Re: Why enterprise software is bloated
#116His "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…
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.
Re: Why enterprise software is bloated
#117The 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 lo…
You're proving my point. None of those bullets are even considerations - they're problems in search of money. The initial solution was implemented by someone who didn't bother to notice everything else on this system was using scheduled tasks (or services and Quartz) to do their work. The didn't bother to notice that there was already Serilog setup to do reporting to another system that the customer was already using to monitor processes. They didn't bother to look for the local storage that was available. Instead they purchased a Kafka instance at the company's cost and threw tech at it. Oh, and then quit and got a different job, before writing any docs.
My solution integrated with current tech, didn't have any of the problems outlined in those bullet points, and has required 0 maintenance and or updates for over 4 years. I don't want to even think about how many Kafka and couch releases there have been since then.
Re: Why enterprise software is bloated
#118In 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…
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 consequence of that bug was able to go unnoticed for a long time in production and then the result was disastrous isn't really a very compelling counter-argument.
If you subsequently hold weeks of post-mortems, meetings, process improvements and outright terminations, the person who made the otherwise useful change that had a bug should be among the last to get called out, somewhere after the entire management chain who utterly failed to competently organise critical development and operations activities, everyone responsible for QA who couldn't spot such a critical problem early, and everyone involved in the data science who ran such a hazardous experiment without taking better precautions around validity.
Re: Why enterprise software is bloated
#119Re: Why enterprise software is bloated
#120Earlier 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…
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.