4 ms·

For no matter how good or bad the Agnostic’s code is, why did the Librarian rewrite the Ascetic’s code? Because rewriting code that looks ugly is one of the wa

by gambler 13y ago

For no matter how good or bad the Agnostic’s code is, why did the Librarian rewrite the Ascetic’s code? Because rewriting code that looks ugly is one of the ways people use to begin to identify with the codebase and make it easier to understand for themselves. The example in the article is clearly made up to show how stupid it it to change things that "just work". Except in reality those things are usually ugly, large and complicated, and eventually need to be changed anyway. The way to deal with them is make people responsible for their own code, so that they add tests or at least some comments that explain why and how things are the way they are. Simply being fearful of change and blaming the last person who touched the codebase for all its problems is not a viable long-term strategy.

dsego 13y ago
I think you missed the point. It isn't to show how stupid it is to change things that already work. It is to show how often the motivation for trivial changes is just to make your code appear sophisticated and stand out.
- gambler 13y ago
  The point isn't very clear from the article. Frankly, I've never seen anyone changing working code simply for the sake of showing off their sophistication, so it feels like a straw-man argument. What does happen quite often is what I described above: people changing code to make it more comprehensible for themselves. If that happens a lot to your code, the answer isn't felling butt-hurt (which seems to be the case with the author) and blaming it on "dysfunctional" personalities of other coders. The answer is to write comments, do better job naming stuff, be clearer about things in general.
  - dsego 13y ago
    The point is very clear. For example, changing a library written in a functional style to a hierarchy of classes and interfaces might be totally reasonable to someone who lives and breathes OOP. To them, the first style is not comprehensible and therefore "wrong". But does it actually solve any problem?
humbledrone 13y ago
> * Because rewriting code that looks ugly is one of the ways people use to begin to identify with the codebase [...] Surely you must see that if more than one person is working on the same codebase that this approach does not scale. If everyone on a 6 person team is constantly rewriting the code so that they each understand it better, and each of them has a different way of understanding code, well, that's going to be quite the clusterfuck.

by gambler 13y ago

dsego 13y ago

I think you missed the point. It isn't to show how stupid it is to change things that already work. It is to show how often the motivation for trivial changes is just to make your code appear sophisticated and stand out.

gambler 13y ago
The point isn't very clear from the article. Frankly, I've never seen anyone changing working code simply for the sake of showing off their sophistication, so it feels like a straw-man argument. What does happen quite often is what I described above: people changing code to make it more comprehensible for themselves. If that happens a lot to your code, the answer isn't felling butt-hurt (which seems to be the case with the author) and blaming it on "dysfunctional" personalities of other coders. The answer is to write comments, do better job naming stuff, be clearer about things in general.
- dsego 13y ago
  The point is very clear. For example, changing a library written in a functional style to a hierarchy of classes and interfaces might be totally reasonable to someone who lives and breathes OOP. To them, the first style is not comprehensible and therefore "wrong". But does it actually solve any problem?

humbledrone 13y ago

> * Because rewriting code that looks ugly is one of the ways people use to begin to identify with the codebase [...] Surely you must see that if more than one person is working on the same codebase that this approach does not scale. If everyone on a 6 person team is constantly rewriting the code so that they each understand it better, and each of them has a different way of understanding code, well, that's going to be quite the clusterfuck.