3 ms·
There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to an
by rectang 10y ago
There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to anticipate how often an API will be used.
- allendoerfer 10y agoThat is why there is versioning.
- forgotpwtomain 10y ago> There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to anticipate how often an API will be used. I think in antirez's case there is little 'underestimation' :) Returning to the more general practice - I agree, it's easy to spend several days building a nice abstraction for something that is not extended again, or something that is extended in a way different from what was anticipated and the abstraction doesn't help. From my experience what has worked the best in terms of internal structure, is to write a basic and working version (this is when you don't know that there are any other users) and to refactor it into a nice abstraction when you reach the point that it needs to be extended - also a huge positive is once it needs to be extended, you know what the abstraction is going to be used for.
- davidjnelson 10y agoI think that's really smart. That's what I do too. When you do the YAGNI way and start seeing it over and over refactor it to an abstraction. Challenging in the agile world though. Businesses don't want to pay for refactoring.
- simula67 10y agoNot to mention there is no way to tell how an API will be used. People may find uses for your software that you never thought of. These use cases may turn out to be more important than the original ones.