[tra3]

In my experience, a quick decision is often a poor decision. Most of the time it’s suboptimal but occasional it’s outright damaging. Most places I’ve worked at, claim that decisions are reversible, but they aren’t. Unless a process or a piece of software is actively and visibly misbehaving, nobody refactors it.

There’s gotta be a balance between waterfall and fake agile, but I haven’t found it yet.

[callmeal]

>Unless a process or a piece of software is actively and visibly misbehaving, nobody refactors it.

Which kind of begs the question: "if a piece of software is not actively and visibly misbehaving, why does it need refactoring?"

[Nemi]

I am a big advocate of refactoring bad code, but what you say is SO important. Badly written code that is non-critical or rarely used or simply where all the known issues are known and easily worked around, is not a good candidate for refactoring. What a lot of refactoring advocates fail to mention (or sometimes realize) is that the act of refactoring has hidden costs. There is an inherent risk taken on that when refactoring something you are going to break something. If you are lucky, it breaks “hard” and it is obvious. If you are unlucky, it soft-breaks and only shows up occasionally or years later on edge cases. This all must be taken into consideration when deciding whether to refactor a bit of code. Deciding to refactor should not be a casual decision.

[tra3]

I’m working with a distributed monolith right now. The system is misbehaving as a whole, but it’s difficult to point to one individual piece and say — this is the culprit.

A number of reversible decisions over the course of the years resulted in a terrible architecture.

Something is broken but nobody knows exactly what it is and there’s no organizational will to get it fixed.