3 ms·

> premature abstraction leads to heartbreak Could you please elaborate on that? I'm not sure to understand.

• idontwantthis 3y ago
  The devastation of realizing that the days you spent working out the perfect class hierarchy or other complex design to handle every case was a complete waste of time and what you made is an over complicated mess that no one else can understand or use, and you could have just copied a method from one place to another and added a couple of ifs or arguments
• sargstuff 3y ago
  Buisness world startup equivalent would be know your market audience. Start out to broad and wind up wasting resources that could be put to better use. Start out to narrow focus without knowing where need/$$ to keep going is and wind up wasting resources. Idealy, the narrower focus permits getting to the 'wasting resources' point faster. Hiding the details via abstraction when details are still in development/need to be viewable & readily available defeats the purpose of abstraction making things simpiler/easier.
• gitgud 3y ago
  In my experience abstracting before you know all the use cases is generally the problem. Write the simplest abstraction first, then as the system develops combine similar use cases into useful abstractions for clarity