You never worked on old code. It’s never that simple in practice when you have to make changes to existing code without breaking or rewriting everything.
Sometimes the client wants a new feature that cannot easily implement and has to do a lot of different DB lookups that you can not do in a single query. Sometimes your controller loops over 10000 DB records, and you call a function 3 levels down that suddenly must spawn a new DB query each time it’s called, but you cannot change the parent DB query.
Where is this even coming from? The guy above me is saying not to give devs better hardware and to teach them to code better.
I followed up with an example of how using indices in a database to boost the performance helped more than throwing more hardware at it.
This has nothing to do with having worked on old code. Stop trying to pull my comment out of context.
But yes you’re right. Adding indexes to a database does nothing to solve adding a new feature in the scenario you described. I also never claimed it did.
This sounds like the “don’t touch working code” nonsense I hear from junior devs and contracted teams. They’re so worried about creating bugs that they don’t fix larger issues and more and more code gets enshrined as “untouchable.” IMO, the older and less understood logic is, the more it needs to be touched so we can expose the bugs.
Here’s what should happen, depending on when you find it:
grooming/research phase - increase estimates enough to fix it
development phase - ask senior dev for priority; most likely, you work around for now, but schedule a fix once feature compete; if it’s significant enough, timelines may be adjusted
testing phase/hotfix - same as dev, but much more likely to put it off
Teams should have a budget for tech debt, and seniors can adjust what tech debt they pick.
In general though, if you’re afraid to touch something, you should touch it, but only if you budget time for it.
You do accept that bad software has been written, yes? and that some of that software is performing important functions? So how is saying “It needs to be written better in the first place” of any use at all when discussing legacy software?
It’s not, but you’ll still hear it a lot. Funny, no one can agree on what “better” means, especially not the first person who wrote it, who had unclear requirements, too little time, and 3 other big tickets looming. All of these problems descend from management, they don’t always spontaneously come into being because of “bad devs”, although sometimes they do.
You never worked on old code. It’s never that simple in practice when you have to make changes to existing code without breaking or rewriting everything.
Sometimes the client wants a new feature that cannot easily implement and has to do a lot of different DB lookups that you can not do in a single query. Sometimes your controller loops over 10000 DB records, and you call a function 3 levels down that suddenly must spawn a new DB query each time it’s called, but you cannot change the parent DB query.
Where is this even coming from? The guy above me is saying not to give devs better hardware and to teach them to code better.
I followed up with an example of how using indices in a database to boost the performance helped more than throwing more hardware at it.
This has nothing to do with having worked on old code. Stop trying to pull my comment out of context.
But yes you’re right. Adding indexes to a database does nothing to solve adding a new feature in the scenario you described. I also never claimed it did.
Why not?
This sounds like the “don’t touch working code” nonsense I hear from junior devs and contracted teams. They’re so worried about creating bugs that they don’t fix larger issues and more and more code gets enshrined as “untouchable.” IMO, the older and less understood logic is, the more it needs to be touched so we can expose the bugs.
Here’s what should happen, depending on when you find it:
Teams should have a budget for tech debt, and seniors can adjust what tech debt they pick.
In general though, if you’re afraid to touch something, you should touch it, but only if you budget time for it.
That’s why it needs to be written better in the first place
Tell me you never worked on legacy code without telling me…
Kid. Go away
You do accept that bad software has been written, yes? and that some of that software is performing important functions? So how is saying “It needs to be written better in the first place” of any use at all when discussing legacy software?
It’s not, but you’ll still hear it a lot. Funny, no one can agree on what “better” means, especially not the first person who wrote it, who had unclear requirements, too little time, and 3 other big tickets looming. All of these problems descend from management, they don’t always spontaneously come into being because of “bad devs”, although sometimes they do.