3 ms·

> Codebases are often evolved rather than designed, and just are the way they are without persistent reasons for things. A common reason would be "because it wa

> Codebases are often evolved rather than designed, and just are the way they are without persistent reasons for things. A common reason would be "because it was this other way before." Yes and no, I think. Codebases represent a collection of point-in-time decisions, and each one of those decisions had a reason. There's always a 'why' even if it's not captured. > Imagine all the stuff that's probably in MS office, for which the reason is totally lost. There were reasons, but they're not really retrievable. True - and that's Really Bad. That means you're stuck not able to improve or change certain things, because you don't know why they were done that way - and when you have a userbase the size of Office, you can't just say 'f it' and break things - at least not lightly, as a code-level decision.

throwawayjava 8y ago
The worst "why?" answers often go like this: 1. Green field+0 years: This particular portion of the system was designed in this way as a cargo cult. 2. Green field+2 years: Because that portion of the system was designed in that way, we had to modify this other portion of the system to achieve X. 3. Green field+3 years: Because of the change in 2, and this new constraint Y, we had to make this other change in a third portion of the system. 5. Green field+(3 to N) years: repeat steps 2 and 3. 6. Green field+N+M years: Wow 5 (or previous 6) has created a mess and exposed a serious architectural flaw from step 1 or previous 6. All of the logic in the various iterations of 2+3 are refactored as best as possible. So, the "why" basically grounds out in "the refactoring we could afford to do in order to correct a mess that resulted from a cargo cult or previous refactoring of even older cargo cult". Is that "why" functionally helpful? Usually not for me -- in either case, I can't really assume a lot and I have to proceed with laborious "just watch what the code does" debugging/logging that I would've done without the "why?". But this is probably a ymmv situation.
- sli 8y ago
  The worst why that I regularly hear is, "the client changed their mind and it's the best we could do." Which, of course, has two negative implications. Not just one.
  - throwawayjava 8y ago
    Yes, that's the root cause of 2+3.

throwawayjava 8y ago

The worst "why?" answers often go like this: 1. Green field+0 years: This particular portion of the system was designed in this way as a cargo cult. 2. Green field+2 years: Because that portion of the system was designed in that way, we had to modify this other portion of the system to achieve X. 3. Green field+3 years: Because of the change in 2, and this new constraint Y, we had to make this other change in a third portion of the system. 5. Green field+(3 to N) years: repeat steps 2 and 3. 6. Green field+N+M years: Wow 5 (or previous 6) has created a mess and exposed a serious architectural flaw from step 1 or previous 6. All of the logic in the various iterations of 2+3 are refactored as best as possible. So, the "why" basically grounds out in "the refactoring we could afford to do in order to correct a mess that resulted from a cargo cult or previous refactoring of even older cargo cult". Is that "why" functionally helpful? Usually not for me -- in either case, I can't really assume a lot and I have to proceed with laborious "just watch what the code does" debugging/logging that I would've done without the "why?". But this is probably a ymmv situation.

sli 8y ago
The worst why that I regularly hear is, "the client changed their mind and it's the best we could do." Which, of course, has two negative implications. Not just one.
- throwawayjava 8y ago
  Yes, that's the root cause of 2+3.