Hacker News Reader

Comment by majormajor | Hacker News Reader

Devil's advocate: if nothing bad happens resulting from the path chosen with that 10-minute-decision solution, is it fair to call it poor from the business perspective? Or even if something "mildly bad" happens, if the flip side was spending 3 weeks doing research until finally arriving at a 24% better approach, which of those costs is higher?

If the team/org is too high-ego to actually treat 2-way decisions as 2-way decisions after they get made, I think that's a bit of a different problem. The org has to invest in the "so we can change it" part of the plan.

View on HN

I mean, if it was a good decision, it was a good decision. But there are a lot of ways for a decision to be bad without legibly causing a legible problem—and the "business" might be happy with that—but that doesn't make it a good idea!

A common pattern I've seen is a team or organization getting in the habit of collecting little papercuts where no individual problem is bad enough to register but, over time, the codebase becomes slow and painful to work on. What's especially dangerous is that the state of the system informs people's expectations: what's easy, what's hard, what's possible at all. You get to the point where changes that should be easy are seen as inherently difficult and people start making strategic decisions that implicitly compensate for this, masking the accumulated problems even further.

Currently working on a project like this.

It's a 20 year old codebase, so it's gotten so bad that we spend 2 weeks planning something that could take me 1 week to write in the current codebase or 1 day to write in a sane codebase, on a product that I could probably re-write from scratch in a month.

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.

>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?"

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.

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.

While I agree with the sentiment, I can see 2 counter-points:

- "Nothing bad happens" might be the accumulation of risk until something _very_ bad happens.

- Something bad might actually be already happening, only silently. For example, teams suffering unnecessary difficulty whenever they need to work on some part of the codebase, but it's considered "normal" because that's life now.

Well now this is what we call a false dichotomy.

The version that I’ve always experienced in practice is “we spent six months fixing bugs and it’s still broken, because we did not read the first page of the docs. No we do not want to read the docs now. Look I found a stack overflow post where some unknown, unqualified fool who is also incapable of reading the docs says to do it this way”.

Weeks of bug fixing can save you literally hours of planning.

> if something "mildly bad" happens, if the flip side was spending 3 weeks doing research until finally arriving at a 24% better approach, which of those costs is higher?

The flip side is often to ask the people doing the work for input, there's a good chance they know what's best. There's often a group that can make decisions and implement the decisions, and another group that can only make decisions, and so naturally we divide the work so that those who cannot implement the decisions make the decisions and those who can do both don't ever get to make decisions.

It was a good decision. And a technical two way but political one way door.

Should good decisions sometimes be reversed? Of course! They were a good decision based on information available at the time.

Reply on news.ycombinator.com