Happy new year, everyone! I just came across an excellent post by Lea Verou which argues for building software on more general and composable abstractions.
In short, I see several different ideas at play in her piece:
Use cases lead to overfitting and it’s better to design more coherent and general increments of function;
More complex and domain-specific functionality can often be obtained as an instantiation or composition of more abstract and general functionality;
Even if you don’t implement the more general and abstract functionality, it might be better to design it and think of your implementation as partial;
You can use progressive disclosure in the UI as a bridge between more common domain-specific functionality and more general functionality.
These ideas seem to have a lot in common with concept design. Maybe her eigensolutions are concepts? What do y’all think? Also, I really liked the critique of use cases, which connects to our discussion last year of Bertrand Meyer’s piece.
Hi @dnj, thank you so much for that excellent summary of my post! I’ve included it at the end, as I think that is very insightful framing and adds value to the concepts discussed.
I think there is definitely overlap between concepts and eigensolutions, though I don’t think it’s 1-1. I suspect it may be a subset: eigensolutions are concepts, but not all concepts are eigensolutions.
Thank you for the link. This is a great article and very relevant to my current work on the Stripe API where we’re trying to introduce the layering that Lea talks about in the article. Like many startups we did “higher-level abstraction” first
I share the point of view on use cases. I have always been bothered by tools like those because I did not see how they help you build good software. For example, I don’t think that VisiCalc was designed by writing down user stories like “as a user I want to enter a formula in a cell with relative reference to other cells in order to …”
That’s why I liked the idea of concepts with purposes because they work for the whole continuum of software that Lea mentions from transactional process to creator tools. I agree with the above comment that not all concepts are eigensolutions. I can see how you could come up with overly-specific concepts. The same way we sometimes create overly-specific “abstractions” in programming.
And, not surprisingly, we have the same set of ideas in programming. For example, the idea of building programs as a set of “small” languages rather than “inflexible” hierarchies is one of the core ideas in Structure and Interpretation of Computer Programs. See Levels of language for robust design
In my experience, great designers are the ones able to come across N problems and have a feeling that they’re all instances of a more general problem. Then there is some analysis work to do to separate what is general and what is specific to each use case + some creativity sometimes.
Another one of my favorite reading on this topic is David P. Reed’s essay, Get the verbs right. It’s more philosophical but arrive at the same conclusion in my opinion: get the verbs right to get conceptual efficiency.
Finally, creating higher-level abstractions that compose the lower level primitives is one way to make the software easier to use. But at the cost of some loss in leverage for the user and extra complexity for the implementer. Another way is to build and organize the primitives so that the user can figure out for themselves how to put the parts together to reach their goal. And the holy grail of design is when the user comes up with use cases the designer did not anticipate (like the spreadsheet).
