4 ms·

"3.- Use abstractions only when necessary (YAGNI and KISS)...You Are Not Going to Need It (YAGNI)..." I would revise this to say "Use abstractions only when yo

by flooha 17y ago

"3.- Use abstractions only when necessary (YAGNI and KISS)...You Are Not Going to Need It (YAGNI)..." I would revise this to say "Use abstractions only when you can see a valid future use." I've spent days and weeks literally just thinking about how to architect a solution and wrapping my mind around all the possibilities. Months later, after making those decisions and writing the code, I inevitably need to add new functionality. Often, I can accomplish my new goal with a ridiculously small amount of code and it really gives me joy for the rest of the day. I could have taken the easy route initially and just done "what was necessary", but I would have paid for it ten fold later...and sometimes do when I take the shortcut (which is thankfully rare.)

akeefer 17y ago
The flip side of that question, though, is how often you add in abstractions that you either never use or to code that you don't really need to change. Planning for the future, as it were, is only a win if the amount of time you save when you guess right is larger than the amount of time you pay when you guess wrong and do unnecessary work (or make things more complicated than necessary, thus slowing down all related work, etc.). I'm all for properly refactoring code, but there's something to be said for the fact that trying to guess what you'll need in the future usually equals guessing wrong, unless "the future" is really close in time (i.e. a week or two away). Personally I've had plenty of those "glad I abstracted it this way" or even "I wish I'd abstracted it initially" moments, but also plenty of the "wow, good thing I didn't sink too much time into this 4 months ago because I would have never guessed I'd need to change it this way" moments too.
nostrademons 17y ago
I'd restrict that further. "Use abstractions only when you can see a valid present use." I've also spent days and weeks thinking about how to architect a solution, and then been wonderfully gratified when I can add new functionality with just a couple lines. More often, however, I find that the new function ends up being something totally unexpected, which I would never have thought of at the time I was writing the code. And then I have to throw away all those carefully crafted abstractions, because they just get in the way and slow me down while the software changes in unexpected ways. It's easy to remember the successes. But more often, initial overarchitecting just results in lost time and wasted effort. Worse, it can be actively counterproductive if you don't have the courage to throw away dead code that's no longer useful.
- tetha 17y ago
  In fact, even at the danger of being annoying, I would rephrase that once again. "USE abstractions when you can see a valid present use". Not listening to your code asking for a common abstraction of several things which already exist just for the sake of not using an abstraction ("well, because!") will result in an even bigger mess than most abstractions cause.

by flooha 17y ago

akeefer 17y ago

The flip side of that question, though, is how often you add in abstractions that you either never use or to code that you don't really need to change. Planning for the future, as it were, is only a win if the amount of time you save when you guess right is larger than the amount of time you pay when you guess wrong and do unnecessary work (or make things more complicated than necessary, thus slowing down all related work, etc.). I'm all for properly refactoring code, but there's something to be said for the fact that trying to guess what you'll need in the future usually equals guessing wrong, unless "the future" is really close in time (i.e. a week or two away). Personally I've had plenty of those "glad I abstracted it this way" or even "I wish I'd abstracted it initially" moments, but also plenty of the "wow, good thing I didn't sink too much time into this 4 months ago because I would have never guessed I'd need to change it this way" moments too.

nostrademons 17y ago

I'd restrict that further. "Use abstractions only when you can see a valid present use." I've also spent days and weeks thinking about how to architect a solution, and then been wonderfully gratified when I can add new functionality with just a couple lines. More often, however, I find that the new function ends up being something totally unexpected, which I would never have thought of at the time I was writing the code. And then I have to throw away all those carefully crafted abstractions, because they just get in the way and slow me down while the software changes in unexpected ways. It's easy to remember the successes. But more often, initial overarchitecting just results in lost time and wasted effort. Worse, it can be actively counterproductive if you don't have the courage to throw away dead code that's no longer useful.

tetha 17y ago
In fact, even at the danger of being annoying, I would rephrase that once again. "USE abstractions when you can see a valid present use". Not listening to your code asking for a common abstraction of several things which already exist just for the sake of not using an abstraction ("well, because!") will result in an even bigger mess than most abstractions cause.