4 ms·

"There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but

"There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication." This is generally how things get over-engineered. The excuse is usually "flexibility", often for some future unknown requirement. (and as an aside - one of the weakest reasons for complexity-causing flexibility is to support mocks/TDD)

asdfman123 6y ago
I'm not trying to hate, and I know Martin Fowler is a great developer, but can anyone else not get past how dry his writing style is? I read all kinds of long things on the internet, but I can never get through stuff he's written, despite his obvious brilliance, because of it. I feel like I'm missing out on the gems like the one you quoted.
- crimsonalucard 6y ago
  I'm not so sure if he's a great developer. He seems to be more of the architect that never codes. I can't be sure. Does anybody know of any great things that he's directly responsible for?
- MauranKilom 6y ago
  Ironically, the quoted part is Martin Fowler quoting Ralph Johnson...
- teh_klev 6y ago
  I find the style just fine and that article is pretty easy to get through, it tells a good story. As an aside I had the pleasure of an afternoon with him and Mary & Tom Poppendieck back in ~2003'ish as an audience member at one of their talks. Super interesting folks with a good stack of war stories to tell.
myth2018 6y ago
100% agree. I've worked in maybe a half-dozen projects where flexibility was a critical concern and, as the result, the end product became harder to understand and maintain. Besides, the vast majority of the flexibilities built into the product haven't came to be exercised along the years those products remained in production. I don't think it's fair for me to criticize those architects, since I have now the privilege of hindsight and might well have taken the same wrong decisions in their place. But I learned some lessons and, with all due respect to the author's credentials, I don't feel convinced. Different kinds of applications are certainly more or less prone to certain sorts of changes, but it doesn't seem to me that engineering most aspects for change should be the default approach.
namelosw 6y ago
I agree that TDD sometimes cause complexity. But TDD done right usually use coarse-grained tests which usually require less flexibility because it's almost end to end, and require less layered architecture. It's more like a description of the desired business behaviour. Even better, TDD done right requires people to write those business cases as test first, then implement with minimalist approach - this enforce people to write straightforward code which happened to just support what the business requires.

asdfman123 6y ago

I'm not trying to hate, and I know Martin Fowler is a great developer, but can anyone else not get past how dry his writing style is? I read all kinds of long things on the internet, but I can never get through stuff he's written, despite his obvious brilliance, because of it. I feel like I'm missing out on the gems like the one you quoted.

crimsonalucard 6y ago
I'm not so sure if he's a great developer. He seems to be more of the architect that never codes. I can't be sure. Does anybody know of any great things that he's directly responsible for?
MauranKilom 6y ago
Ironically, the quoted part is Martin Fowler quoting Ralph Johnson...
teh_klev 6y ago
I find the style just fine and that article is pretty easy to get through, it tells a good story. As an aside I had the pleasure of an afternoon with him and Mary & Tom Poppendieck back in ~2003'ish as an audience member at one of their talks. Super interesting folks with a good stack of war stories to tell.

myth2018 6y ago

100% agree. I've worked in maybe a half-dozen projects where flexibility was a critical concern and, as the result, the end product became harder to understand and maintain. Besides, the vast majority of the flexibilities built into the product haven't came to be exercised along the years those products remained in production. I don't think it's fair for me to criticize those architects, since I have now the privilege of hindsight and might well have taken the same wrong decisions in their place. But I learned some lessons and, with all due respect to the author's credentials, I don't feel convinced. Different kinds of applications are certainly more or less prone to certain sorts of changes, but it doesn't seem to me that engineering most aspects for change should be the default approach.

namelosw 6y ago

I agree that TDD sometimes cause complexity. But TDD done right usually use coarse-grained tests which usually require less flexibility because it's almost end to end, and require less layered architecture. It's more like a description of the desired business behaviour. Even better, TDD done right requires people to write those business cases as test first, then implement with minimalist approach - this enforce people to write straightforward code which happened to just support what the business requires.