3 ms·

Inside DHH's arguments is also a general argument against what I call frameworkitis - the desire to overgeneralize an application in the vague hope that the cod

Inside DHH's arguments is also a general argument against what I call frameworkitis - the desire to overgeneralize an application in the vague hope that the code will get used in a different way in the future. In my middle career I was prone to that but in the last 5 years or so I've been trying to resist that impulse. I now try to write the application and if another similar application comes around I might pull out reusable portions. On the whole this approach has been a win for me. Not that Beck or Fowler are advocating anything different but I think DHH is the one with his finger on the pulse of current development trends.

encoderer 12y ago
I'm a full YAGNI convert as well. And I've developed a strong belief that some amount of duplication is almost always better than the wrong abstraction.
- codeulike 12y ago
  some amount of duplication is almost always preferred to the wrong abstraction This. This concisely expresses something I've learnt in the last few years but have struggled to write down. Generalising is great until you generalise in the wrong direction, then it creates extra complexity in all the other directions.
  - mreiland 12y ago
    I agree, see my reply to the post you were replying to.
- mreiland 12y ago
  absolutely. I'm also a big believer in not making decisions until you have more information. Being honest enough to say "I don't know how this will evolve in the future", so implement/duplicate/whatever until you have a better idea. then generalize as needed (if it's needed at all). You save time and effort by choosing not to make a definite decision on which way to jump with that abstraction.
hibikir 12y ago
When we modularize something, we should do it for the needs we have today, not for the ones we foresee for a long term future. We are very bad at figuring out what the future requirements will be. Now this is a place where functional programming tends to help. Unnecessary FactoryProviderObjectServices just make code unreadable, because they aren't really talking about the task at hand, but about our own internal abstractions, which become useless quickly. Functional decomposition makes throwaway abstractions a whole lot easier to throw away.

encoderer 12y ago

I'm a full YAGNI convert as well. And I've developed a strong belief that some amount of duplication is almost always better than the wrong abstraction.

codeulike 12y ago
some amount of duplication is almost always preferred to the wrong abstraction This. This concisely expresses something I've learnt in the last few years but have struggled to write down. Generalising is great until you generalise in the wrong direction, then it creates extra complexity in all the other directions.
- mreiland 12y ago
  I agree, see my reply to the post you were replying to.
mreiland 12y ago
absolutely. I'm also a big believer in not making decisions until you have more information. Being honest enough to say "I don't know how this will evolve in the future", so implement/duplicate/whatever until you have a better idea. then generalize as needed (if it's needed at all). You save time and effort by choosing not to make a definite decision on which way to jump with that abstraction.

hibikir 12y ago

When we modularize something, we should do it for the needs we have today, not for the ones we foresee for a long term future. We are very bad at figuring out what the future requirements will be. Now this is a place where functional programming tends to help. Unnecessary FactoryProviderObjectServices just make code unreadable, because they aren't really talking about the task at hand, but about our own internal abstractions, which become useless quickly. Functional decomposition makes throwaway abstractions a whole lot easier to throw away.