3 ms·

I can’t find the blog/article anymore, but its message was that “when you see something suboptimal in the code, do not assume incompetence”. As people who wrote

I can’t find the blog/article anymore, but its message was that “when you see something suboptimal in the code, do not assume incompetence”. As people who wrote the code may have had tight deadlines, different priorities set for them and other factors that may have prevented the developers from “doing the right thing” immediately…

lambdaxyzw 2y ago
There's also chesterton fence - maybe this dumb thing in code actually was important some time ago. Or, even worse, maybe it is still an important for a rare edge case and you just don't see how, yet.
- brazzy 2y ago
  That as well is "not doing the right thing", namely adding a comment that explains the need for it.
- kqr 2y ago
  The Chesterton fence in my book is only about something that is still meaningful only in non-obvious ways. In evolutionary theory I believe "used to have a sensible explanation but no longer does due to changing circumstances" is known as discordance.
  - MrJohz 2y ago
    The fence is about all things that you might want to change, whether or not they're still useful. Both of the characters in Chesterton's parable are reformers, and the assumption is still that the goal should be reform. The question is more about the motivation for reform. The first character wishes to remove the fence because they don't see a good reason for it. The second takes a different approach: first show that it isn't necessary, then remove it. Plenty of things are made useless over time. But there are also lots of things that look useless but aren't. We don't know, a priori, which is which, hence the need to be cautious. (That said, I think there are also cases where ignoring Chesterton, removing the fence, and seeing what will happen is the best option. It just requires good planning and good testing so that you can be confident that a bull doesn't suddenly appear out of nowhere!)
- npsimons 2y ago
  > you just don't see how Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).
  - YZF 2y ago
    I would soften this to always consider that possibility. The probability that something is just wrong, or the requirements have evolved in a way that makes it wrong, is probably not that different than the probability the original author had a very strong reason for doing something a certain way and that really did survive the test of time. Considering everything preexisting to be perfect is overly conservative and almost certainly wrong in most real world software engineering scenarios. The history of software engineering is full of examples of things that got replaced with much better things because the original was just not good enough.
pornel 2y ago
Even if the code has been absolutely perfect at the time of writing, growth of the codebase, and changing requirements could make it bad. e.g. if you have 10 items to store, then a simple file may be a pragmatic choice. When it grows to 10,000 items you may need a database. But if you started with a database for just 10 items, people would complain it's overengineered. If you have 2 classes, an if/else can do, but at 20 you need some Factory pattern, which would be an architecture astronautics if done from the start. And when you try to anticipate such growth, you'll create overcomplicated code whenever you guess wrong. A continuously developed project will systematically keep outgrowing itself.
- NBJack 2y ago
  Or just that errant refactoring automation that moved a proverbial (or literal) bit out of place. It's good to learn from our mistakes. But if there's one thing I have learned from working across teams and orgs, it is that basically everyone works with imperfect information. And oftentimes, you just have to make do, write the code, and try to make room to course correct in the future.
1penny42cents 2y ago
fwiw I’ve written about that here: https://camhashemi.com/posts/building-through-uncertainty/ https://camhashemi.com/posts/building-through-uncertainty/

lambdaxyzw 2y ago

There's also chesterton fence - maybe this dumb thing in code actually was important some time ago. Or, even worse, maybe it is still an important for a rare edge case and you just don't see how, yet.

brazzy 2y ago
That as well is "not doing the right thing", namely adding a comment that explains the need for it.
kqr 2y ago
The Chesterton fence in my book is only about something that is still meaningful only in non-obvious ways. In evolutionary theory I believe "used to have a sensible explanation but no longer does due to changing circumstances" is known as discordance.
- MrJohz 2y ago
  The fence is about all things that you might want to change, whether or not they're still useful. Both of the characters in Chesterton's parable are reformers, and the assumption is still that the goal should be reform. The question is more about the motivation for reform. The first character wishes to remove the fence because they don't see a good reason for it. The second takes a different approach: first show that it isn't necessary, then remove it. Plenty of things are made useless over time. But there are also lots of things that look useless but aren't. We don't know, a priori, which is which, hence the need to be cautious. (That said, I think there are also cases where ignoring Chesterton, removing the fence, and seeing what will happen is the best option. It just requires good planning and good testing so that you can be confident that a bull doesn't suddenly appear out of nowhere!)
npsimons 2y ago
> you just don't see how Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).
- YZF 2y ago
  I would soften this to always consider that possibility. The probability that something is just wrong, or the requirements have evolved in a way that makes it wrong, is probably not that different than the probability the original author had a very strong reason for doing something a certain way and that really did survive the test of time. Considering everything preexisting to be perfect is overly conservative and almost certainly wrong in most real world software engineering scenarios. The history of software engineering is full of examples of things that got replaced with much better things because the original was just not good enough.

pornel 2y ago

Even if the code has been absolutely perfect at the time of writing, growth of the codebase, and changing requirements could make it bad. e.g. if you have 10 items to store, then a simple file may be a pragmatic choice. When it grows to 10,000 items you may need a database. But if you started with a database for just 10 items, people would complain it's overengineered. If you have 2 classes, an if/else can do, but at 20 you need some Factory pattern, which would be an architecture astronautics if done from the start. And when you try to anticipate such growth, you'll create overcomplicated code whenever you guess wrong. A continuously developed project will systematically keep outgrowing itself.

NBJack 2y ago
Or just that errant refactoring automation that moved a proverbial (or literal) bit out of place. It's good to learn from our mistakes. But if there's one thing I have learned from working across teams and orgs, it is that basically everyone works with imperfect information. And oftentimes, you just have to make do, write the code, and try to make room to course correct in the future.

1penny42cents 2y ago

fwiw I’ve written about that here: https://camhashemi.com/posts/building-through-uncertainty/ https://camhashemi.com/posts/building-through-uncertainty/