3 ms·

For what it's worth, I agree with you. I think premature abstraction can cost a business a great deal. This article comes across as vapid - there is no silver b

by bm1362 10y ago

For what it's worth, I agree with you. I think premature abstraction can cost a business a great deal. This article comes across as vapid - there is no silver bullet and it varies from org to org. I went from a big tech co where we had the resources to abstract and deliver ideal solutions, to an existential startup that is hacking features together to win contracts. My biggest frustration is new engineers joining and overcomplicating simple tasks by trying to create generic solutions to every single feature request we get. The worst is that this comes across as 'investment' to management but it hardly ever bears fruit and we're just slowing down delivery to massage the developer's anxieties about technical debt. The reality is that the product may not really need that feature, or the customer may never use it, or it's good-enough, etc. I think in this environment we should ship simple features, that are hacky, until we gather enough data about it's value and use.

chrisbennet 10y ago
There is even a "rule" for what you espouse: YAGNI - You Ain't Gonna Need It If all you ever going to deal with is humans in your class/API, there is no need to make it generic enough to work with all animals. The Clever Boy in all of us probably wants to implement this bit of "future proofing investment" but we need to resist the temptation.
- AstralStorm 10y ago
  The counterpart is YWNI - You Will Need It. Usually considering the parts of abstraction that will reduce coupling and make understanding easier, or allow making an implementation high performance or secure. You know, things nobody really states in requirements but everyone wants in the end. Most of the time internationalization and localization are also needed but not stated outright. Also consider things that are essentially impossible to bolt on later or inordinately expensive.
- chrisweekly 10y ago
  YAGNI is great one. I wish STTCPW (Simplest Thing That Could Possibly Work) made for a better acronym. Also related: KISS (which I prefer to interpret as "Keep It Stupid-Simple").
  - mrec 10y ago
    STTCPW has problems aside from its acronym; back when I was working in an XP-ish team we had any number of arguments which I eventually realized came from a fundamental ambiguity in this principle: does it mean 1. Make the simplest incremental change to the existing system to satisfy requirements, or 2. Make the simplest overall system which satisfies requirements? The first is fine for prototyping when you're moving fast and breaking things, but guarantees technical debt out the wazoo over the longer term. The second makes for much better code but you may waste a lot of time on refactoring churn if you do too much of it before requirements have really stabilized.

by bm1362 10y ago

chrisbennet 10y ago

There is even a "rule" for what you espouse: YAGNI - You Ain't Gonna Need It If all you ever going to deal with is humans in your class/API, there is no need to make it generic enough to work with all animals. The Clever Boy in all of us probably wants to implement this bit of "future proofing investment" but we need to resist the temptation.

AstralStorm 10y ago
The counterpart is YWNI - You Will Need It. Usually considering the parts of abstraction that will reduce coupling and make understanding easier, or allow making an implementation high performance or secure. You know, things nobody really states in requirements but everyone wants in the end. Most of the time internationalization and localization are also needed but not stated outright. Also consider things that are essentially impossible to bolt on later or inordinately expensive.
chrisweekly 10y ago
YAGNI is great one. I wish STTCPW (Simplest Thing That Could Possibly Work) made for a better acronym. Also related: KISS (which I prefer to interpret as "Keep It Stupid-Simple").
- mrec 10y ago
  STTCPW has problems aside from its acronym; back when I was working in an XP-ish team we had any number of arguments which I eventually realized came from a fundamental ambiguity in this principle: does it mean 1. Make the simplest incremental change to the existing system to satisfy requirements, or 2. Make the simplest overall system which satisfies requirements? The first is fine for prototyping when you're moving fast and breaking things, but guarantees technical debt out the wazoo over the longer term. The second makes for much better code but you may waste a lot of time on refactoring churn if you do too much of it before requirements have really stabilized.