131–140 of 144 posts
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
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.
Yes, the general rule for me is if I see something completely whack on the ticket I'm working on, I'll clean it up as long as I know there won't be collateral damage. The problem comes when these systems become so complex and so old and the people working on them don't really know what changes will affect other systems down the chain.
Or a Chekov's Gun.
The problem is that you can almost never tell which is which. And sometimes they're both.
Have you looked at some the VM footprints of the text editors people are using?
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…
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?
When a private citizen buys software, the question is "does it do enough, for the price, for me to buy it?" 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 ?"
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…
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.
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…
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…
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…
IME things do improve after taking those steps. But with large code bases there are a lot of layers of products over time and it's difficult (and expensive) to make sure everything is covered. And it's also a moving target.
> Also, the original task is described as a "refactor", so the numbers should not be affected - was was it not just a refactor?
IME the most useful tech debt interventions are where some legacy module is deleted or some unused code retired. Unfortunately those are often not provably without side effects and sometimes even with a diligent investigation side effects can be missed, especially when the components involved are old and original creators and product managers have left the company.
At the end of the day cleaning up tech debt has non-zero risk, guaranteed cost, and very often, in the eyes of management, negligible reward. So on average it grows and thus enterprise codebases are born.