4 ms·

Abstractions, I think, should not be forced. They should evolve, parameter by parameter, as more and more configuration is needed in the original application, u

Abstractions, I think, should not be forced. They should evolve, parameter by parameter, as more and more configuration is needed in the original application, until they can be effortlessly lifted to another application. Everytime I've thought: "I'll abstract this so I can one day use it elsewhere" it's ended in failure--a working but overengineered, complex solution that I'd rather leave where it is and start afresh rather than reuse.

rossdavidh 6y ago
I was once told: never make the abstraction to something, until you're ready to make the 3rd instance of it. The reason is, that until you're ready to make the third one, you not only don't know if it will ever really be needed, but you also don't really know which parts of the thing really need to be different/customizable. If you abstract it before then, even if you do end up needing another someday, you will find that the way you abstracted it is the wrong way, and you will need to rewrite all the associated code anyway. Until you're making your third one (of whatever), don't make an abstraction for it.
- tarkin2 6y ago
  Good and pithy advice. I’d expand it slightly: “Until you’re making it a third time, don’t abstract, because you won’t yet know the what or the how.”
- chongli 6y ago
  That’s sound advice for the day-to-day of programming but I think it still misses much of the power of abstraction. If you choose a different abstraction you might find a completely different way to express your solution which could be orders of magnitude less code. Perhaps the most absurd example of such a thing I can think of is when people figure out they can replace some gigantic mapreduce cluster with an awk one-liner and have it actually run faster.
officehero 6y ago
Is this related to the "build things that don't scale" motto? That one was conceived for startups in general if I remember correct. Is this same thing but in more detail?

rossdavidh 6y ago

I was once told: never make the abstraction to something, until you're ready to make the 3rd instance of it. The reason is, that until you're ready to make the third one, you not only don't know if it will ever really be needed, but you also don't really know which parts of the thing really need to be different/customizable. If you abstract it before then, even if you do end up needing another someday, you will find that the way you abstracted it is the wrong way, and you will need to rewrite all the associated code anyway. Until you're making your third one (of whatever), don't make an abstraction for it.

tarkin2 6y ago
Good and pithy advice. I’d expand it slightly: “Until you’re making it a third time, don’t abstract, because you won’t yet know the what or the how.”
chongli 6y ago
That’s sound advice for the day-to-day of programming but I think it still misses much of the power of abstraction. If you choose a different abstraction you might find a completely different way to express your solution which could be orders of magnitude less code. Perhaps the most absurd example of such a thing I can think of is when people figure out they can replace some gigantic mapreduce cluster with an awk one-liner and have it actually run faster.

officehero 6y ago

Is this related to the "build things that don't scale" motto? That one was conceived for startups in general if I remember correct. Is this same thing but in more detail?