Yeah, that's the 'shiny new toy' fallacy. In every project there are points when it's clear that something wasn't designed right. Some people decide to get deeper into their mess and some people decide to refactor. It's a judgement call and not an easy one.
I don't think I'd want to work with microservices and Docker containers designed by the same people who messed up another codebase.
Considering management has a very large role in most messed up codebases I've seen, even if they fire 100% of the engineering team who coded it you probably are working with (for) the same people who messed up a codebase.
That's a pretty dangerous mindset, and one that seems to be pretty popular around here, that all failure is automatically the fault of management. Yes, management plays a role, that's almost tautological, but it takes two to tango, and at the end of the day, the dev team wrote the messed up code. Grandly messing up in just six months, even if encouraged by management, takes willing participation from the developers.
Also, I've seen plenty of developers who were perfectly capable of screwing up codebases without being induced to do so by management (I've also seen lots of inept management, don't get me wrong. But I wrote the bad code, they didn't.)
Yes, it takes two to tango, which is the correct answer. Any other answer tends to oversimplify the problem.
A lot of engineers also seem to evaluate other engineers by their worst work. This is a toxic attitude. You can even take an engineer performing terribly in a good environment, and put them in a different good environment, and they can perform exceptionally. I've seen it happen more than once.
As I understand it, it's a very common human failing called the Fundamental Attribution Error. I only have a passing familiarity with it, but its very seductive.
It is always the managers fault: they hired bad people, and didn't train them. Or maybe they setup bad expectations (doesn't mater if the people are good or bad). Their job is to know how to hire the right people and get the best out of them.
Note, the engineers have an ethical responsibility to not be bad. However bad is sometimes creating perfect code when something else is called for.
We're using 'management' as a standin for 'business requirements' here, at least in the most cases I've seen that lead to accumulation of 'debt'.
These things generally start with, "We need feature X for customer Y in Z days.". Engineers dive in, and then comments start popping up - usually variations on a theme: "This is a mess, but it works for now - we'll come back later and clean it up."
The unhealthy process that leads to that is a different discussion. But as engineers, our responsibility is to be aware that it's a reality, and work within those constraints.
Yes, there will be time/resource/budget limitations. No, we're not going to fix that overnight. But knowing it going in, we can take a closer look at some of those 'good enough for now' decisions, and do our best to not produce dog shit.
Sometimes dog shit can't be avoided, but if the pattern above is the normal way of doing business in a company, engineers do have the ability (and responsibility) to do the best they can within those constraints.
Often that means pausing and saying, "I know this is going to come back and bite us, what can we do now to make it better?"
Telling yourself that failures are someone else's fault (while, presumably, still taking credit for good work) is a great way to never learn from your mistakes.
What about when management (and financial realities) pushes relentlessly for new options, customizations and deployments? When all time not spent shipping new variants is spent developing features? What then? When is the code going to be refactored? In the developers' spare time?
What about it? Yes, that environment will obviously be less conducive to good code than otherwise. But bad coders will do (a lot!) worse than good coders.
Don't assume that all good code bases out there were written by teams with reasonable, well-defined and stable requirements, plenty of time and money and perfectly enlightened management. Very few projects are like that. Generally, I think you'll find they were written by good developers who kept their heads cool in the face of a range of challenges.
Absolutely, they will also largely not have had bosses that death marched them or changed requirements three times a day - as I said, management do obviously play a role.
Certainly not in spare time. It has to be part of the daily work. I compare it to running a restaurant. Cleaning up the kitchen every night takes time but it has to be done no matter the circumstances. You can't skip it or the health department will come after you. Unfortunately in programming you can get away with taking shortcuts for a long time.
Incidentally, good cooks are extremely tidy, they clean obsessively as they go - and they are under insane pressure, and don't wait for management to allocate time for cleaning.
They clean continously, not primarily to make the end-of-shift cleaning easier, but because it allows them to execute faster, better and more consistently (which in that environment is a necessary condition for executing at all).
Management is a part of the team that messed up the codebase, not only the engineers. That's why I am always wary of managers bringing in new methods (microservices, scrum, whatever). They had a big part in previous failures and if they don't admit their own failures nothing will change.
Considering management has a very large role in most messed up codebases I've seen, even if they fire 100% of the engineering team who coded it you probably are working with (for) the same people who messed up a codebase.
It seems to me you should stop working for managers who are writing code.
Even if they don't write code they can set unrealistic deadlines and actively not allow refactoring. My solution is usually not to tell anybody who doesn't need to know and just refactor but that can be a dangerous path too.
Even if they don't write code they can set unrealistic deadlines and actively not allow refactoring.
I know it might sound glib but if thats the case then you're allowing yourself as a programmer to be set up to fail and be left holding the bag when things go to shit.
Either manage up in those situations or find a new job.
I've definitely cut corners for deadlines in my life but everyone always understands what debt we're accruing and when we'd get stuck paying that debt. If your status quo is "Do shitty work" you really need to find a new gig.
I don't think I'd want to work with microservices and Docker containers designed by the same people who messed up another codebase.