The Agaram Paradox: to get to better interfaces, expose your implementations.

Discuss!

Suggestive! Not sure it's related but in a projectional editing context I increasingly think of exposing configuration as choosing some projection of the source implementation admitting bidirectional transformation.

Ok, I guess it was a bad idea in this case to say, "responses in thread plz" 😄 This idea is basically at the heart of everything I write or do about Mu. Typically we tend to emphasize interfaces, identify them with 'good practice' and therefore they become a means of signalling among programmers. But at the start a new sub-system often has just one caller. Even if it's a function, it doesn't necessarily form a good abstraction. You often don't have a sense for what other callers may need yet. Prematurely thinking of it as an interface makes us reluctant to modify it, because that would signal that we didn't know what we were doing before. (This is particularly true if we also packaged up the function prematurely into a 'package'. Now signature changes require incrementing the major version, which is more visible to others.) The alternative, better approach is to admit up front that we're all fools together and think of functions at the start as just loose bags of implementation rather than an interface. Then we're more willing to modify it, less likely to package it. As a result the interface has a chance to change. It gets time to grow into what it needs to be. And it stabilizes when it makes sense for it to stabilize. Abstractions should be names for algorithms so we don't have to think about the details all the time. Abstractions should rarely turn into frozen interfaces that we pass on to others so they never have to think about the details. That turns a useful technical idea into a social artifact. We need to be a lot less promiscuous about getting into social counterparty relationships. (I wrote about this long ago: http://akkartik.name/post/libraries, http://akkartik.name/post/libraries2. Hopefully I've gotten better at describing it over the years.)

That rings quite true in my experience. It's one of the reasons I'm so happy to be the only programmer on my team, and one with a strong case of NIH at that — all my interfaces are as permeable as I want them to be, since I own all code inside and out.

On my cynical days I think interfaces were invented by hired-gun programmers to spread responsibility around so that screwups can't have accountability or consequences.