3 ms·

> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. I agree. I thin

> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. By default, good code tends to be modular and easy to replace, while bad code is excessively coupled and hard to get rid of. So bad code has a disproportionate impact on long-lived codebases. I wonder if one way around this is to force modularity, even when it's unnatural. Functional programming seems to be one way of doing this, microservices are another. A related principle would be not to take DRY too seriously, favoring decoupling over deduplication.

lloeki 10y ago
> I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. Indeed, what matters isn't writing bad code, but doing so in a way that affects the whole codebase (whether through coupling or by volume). Accepting that bad code happens helps a lot in locking it down behind containment measures, both in space and time. I can liberally accept bad code as long as it doesn't imply bad architecture, so that it's easily removable and understandable, but I'm hell bent on refusing any form that means we can't dig ourselves out of a hole we've dug ourselves into (this includes slowly drifting yourself into a hellhole by accretion, bad code must come with an expiration date, which means immediately creating an issue in your favourite bug tracker upon commit/merge). Decoupling is key, and duplication is often needed to see the true generalisation patterns emerge, not the ones you expect to be there sometime in the future[0]. [0]: noop-noop-noop maneuver (video+slides) http://www.thedotpost.com/2016/10/katrina-owen-the-scandalous-story-of-the-dreadful-code-written-by-the-best-of-us http://www.thedotpost.com/2016/10/katrina-owen-the-scandalou...
- SatvikBeri 10y ago
  This is a great talk. I find that this pattern comes up over and over again: first add new code in a safe way that makes the codebase a bit messier without modifying anything, then move all functionality to the new code and neuter the old stuff, then delete the old stuff. Eg this style of pattern is how to do schema migrations safely.
dahart 10y ago
> I wonder if one way around this is to force modularity, even when it's unnatural. There's probably no denying this is a good idea. :) The most successful very large systems seem to be made of independent modules that each strive to do one thing well. They can also be more easily removed, refactored, or replaced, due to their small size, and perhaps most important you can do one at a time. > I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. Yeah, it's true, emphasis at any given moment is on what list of things we want to see, and what list of things we don't want. The author even started with one. Problem is, code styles also change over time. What some people call reasonable or good code, other people call bad; "bad" is subjective. Hire a brilliant engineer to help make your decent application awesome, and her first reaction may be "oooh, this code is pretty bad. let's make some changes". I honestly wouldn't be able to count how many times I've seen the newest member of a project complain about the mess while nobody else seems to mind that much. (And I count myself in that list, I've done it too.)

lloeki 10y ago

> I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. Indeed, what matters isn't writing bad code, but doing so in a way that affects the whole codebase (whether through coupling or by volume). Accepting that bad code happens helps a lot in locking it down behind containment measures, both in space and time. I can liberally accept bad code as long as it doesn't imply bad architecture, so that it's easily removable and understandable, but I'm hell bent on refusing any form that means we can't dig ourselves out of a hole we've dug ourselves into (this includes slowly drifting yourself into a hellhole by accretion, bad code must come with an expiration date, which means immediately creating an issue in your favourite bug tracker upon commit/merge). Decoupling is key, and duplication is often needed to see the true generalisation patterns emerge, not the ones you expect to be there sometime in the future[0]. [0]: noop-noop-noop maneuver (video+slides) http://www.thedotpost.com/2016/10/katrina-owen-the-scandalous-story-of-the-dreadful-code-written-by-the-best-of-us http://www.thedotpost.com/2016/10/katrina-owen-the-scandalou...

SatvikBeri 10y ago
This is a great talk. I find that this pattern comes up over and over again: first add new code in a safe way that makes the codebase a bit messier without modifying anything, then move all functionality to the new code and neuter the old stuff, then delete the old stuff. Eg this style of pattern is how to do schema migrations safely.

dahart 10y ago

> I wonder if one way around this is to force modularity, even when it's unnatural. There's probably no denying this is a good idea. :) The most successful very large systems seem to be made of independent modules that each strive to do one thing well. They can also be more easily removed, refactored, or replaced, due to their small size, and perhaps most important you can do one at a time. > I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. Yeah, it's true, emphasis at any given moment is on what list of things we want to see, and what list of things we don't want. The author even started with one. Problem is, code styles also change over time. What some people call reasonable or good code, other people call bad; "bad" is subjective. Hire a brilliant engineer to help make your decent application awesome, and her first reaction may be "oooh, this code is pretty bad. let's make some changes". I honestly wouldn't be able to count how many times I've seen the newest member of a project complain about the mess while nobody else seems to mind that much. (And I count myself in that list, I've done it too.)