Ultimately you have two choices: you refactor the architecture as needed as part of implementing the current feature...or you end up drowning in technical debt farther down the line.
A properly architected code base makes it easy to make the kind of changes you want to make. A badly architected code base (as you describe) makes it nearly impossible. I've found it's usually by far the quickest thing to fix the architecture and then implement the new feature sanely. (And no, you don't ask permission; you just make everything clean. As I noted above, if your boss doesn't like this kind of thinking, you need a new boss.)
Of course, I'm one of those guys Graham mentions who works by himself most of the time.....YMMV.
Yeah, I completely agree with you. I might be a bit "scarred" by my previous team. We were working on CMS websites for a fairly large number of different clients. Every task was estimated by the hour, and if we went over that estimate it usually meant we were working for free. I mean I still got paid but my company didn't. It didn't help that all the solutions were either developed by Juniors or inherited from other departments/companies. Literally every moderately popular frontend tech was represented. React, Vue, AngularJS, jquery, nextjs, svelte, and more. Let's just.make our lives as difficult as possible eh, what should we use next? The back ends were all the same CMS luckily, but of course some genius had to go and add Sanity to the mix to pad their resume.
So I frequently had to learn a new js framework while dealing with shitty, unreviewed and untested code that barely worked or just kind of seemed to work, while under time pressure.
In that environment, my disdain for bad code really just didn't work out. Though I feel like I was a bit unfairly treated at times as well.
There was this one app that had an integration against a third party API. They had used a library to interact with the API, this library was purchased for a fairly significant amount of money from some university and it was complete garbage. All it did was get data twice a day and store it in a db, then the CMS had a daily scheduled job that would get the data from that db and build the content in the actual CMS db. It was like 30k loc, a lot of which was dead and the rest of it was shitty and redundant manual xml parsing and completely unnecessary db interaction. Not to mention the (probably minor) cost of running this pointless db.
So there's a problem with it and I spend days bughunting, I can't figure out what's wrong. I try telling the team that I think I can build a better solution from scratch faster than I can fix this bug. No bueno. So over the weekend, on my own time, (really just a few hours) I throw together a quick POC. I don't need the intermediate DB, the CMS can just get the data from the API once a day during the scheduled job. So 90% of the work is just making DTOs to deserialize the xml into, using whatever xml serialization library i found.
I finish it, hook it up, it's not totally done but it pretty much works already. On Monday I tell the team what I've done and just get completely shut down. They don't even want to see it, just nope.
So that code is gone and they're still maintaining that piece of shit library for no reason. Oh well, luckily it's not my problem any more.
Sorry about the rant, and thanks for the support. It's nice to know I'm not alone in seeing the value of quality.
A properly architected code base makes it easy to make the kind of changes you want to make. A badly architected code base (as you describe) makes it nearly impossible. I've found it's usually by far the quickest thing to fix the architecture and then implement the new feature sanely. (And no, you don't ask permission; you just make everything clean. As I noted above, if your boss doesn't like this kind of thinking, you need a new boss.)
Of course, I'm one of those guys Graham mentions who works by himself most of the time.....YMMV.