It’s been just over two years (wow!) since the publication of The Essence of Software. In that time, engaging with readers, consulting and teaching to students and practitioners has given me a new perspective.
In addition to having a better sense of what matters most, I think I have a greater appreciation of the obstacles that make concept design seem (at the same time!) trivial to some and obscure to others.
So I’m embarking on a new project to explain the key ideas of concept design as simply and directly as possible, with as little technical baggage as I can get away with.
Here’s my first installment: a very short talk about software innovation, and a tutorialthat explains the idea in more detail.
Comments welcome! I’d especially like to hear from you if you have examples of how thinking in terms of concepts has helped you in your work.
I personally find the ideas behind concepts more helpful than the details of their structure and formalization but that might be a personal bias since I’m more interested in analysis than the actual representation of the software.
The ideas I founds most helpful:
Levels of design and how the UI and code are representations of the concepts
Stop thinking in terms of nouns in the domain (what is) and think in terms of verbs (what it does)
Purpose specificity, especially avoiding overloading.
Concept independence (interface/generic class)
However, because those are ideas and not tools, they are hard to communicate. In my experience, most software engineers still approach a design problem as a problem of modeling reality. I face indifference most of the time when I bring up the idea of purpose.
The idea that resonates the most with other engineers is avoiding overloaded concepts. I believe this is because it is a very common problem. We have a tendency to build “simple models” that are easy to understand so we try to limit the number of concepts and inevitably overload them. However, when you try to break down the monolithic “concept” into multiple parts, you’re often accused of over-engineering and/or making the interface too complicated.
I really enjoyed the talk and the book you cite, the Heart of Innovation. Interestingly, I started doing little diagrams similar to yours when reading the book to explain the conversation between the different actors (persons and technologies). I wonder if there is an idea for a simple analysis tool in those diagrams to work out a situation and identify opportunities.
Maybe a simple tool that embeds the ideas behind concepts could help spread those ideas better.
I think there’s a paradox at the core of your (excellent) observations, which you acknowledge. It’s that you find the ideas of concepts compelling, and the formal notation less so—but you note that ideas alone are very hard to communicate.
I take this is a challenge! I’m thinking about this a lot. I do think concepts need to have a very concrete form so that the ideas can be conveyed easily. But the language I’ve used so far (which isn’t really anything new–mostly just reusing standard formal methods notation) is undoubtedly off-putting and unfamiliar to many people. So what I think is needed is a simpler, more direct and more diagrammatic form.
That’s what I’m trying to start doing with these scenarios in the article and talk. I’ve also been experimenting with the idea of combining a kind of action sequence diagram with a graphical data model, but the resulting diagrams are too complicated. Here’s an example (which attempts to summarize the Android Camera API): Android Camera API | The Essence of Software.
I loved the TED talk very much, and the 4 examples you gave. I found the idea that software was about conceptual discoveries – rather than technology – very compellingly put forward, and that is fascinating.
I wonder if a diagrammatic notation is the missing point. There are so many great products which don’t have any problem of features and accessibility, but a go-to-market one… And here the domain of software methods seems to me such a difficult market ! There is one point where Ivar Jacobson remarks that there are as many methods as development teams around the world…
So I am curious how you would answer the following:
1- How would you define success? which audience segment do you target, what would be the form of buy-in you would like to see (eg using informally like @benfle does, using formally (which would be measure by the growing catalog of concepts), using a tool?..) This looks more difficult to me to measure than a programming language like Alloy was.
2- What would be the channels to get to this audience? education and training i.e. teaching the teachers (might take a while) ? industry venues and forums? consultants? large software companies? tools like requirement management software?
3- How much investment is required to make this work? I tracked a bit Jacobson’s effort on his “Essence” cards, and I realized it has been 10 years he is on it. By investment I mean building a tool, as suggested (but how and where to distribute it?), building a team of evangelists, going to industry forums, etc.
What great questions! I really welcome them, as it feels very hard to get ideas like concept design out there. Here are some observations:
Accessibility. Just getting people to even take a look is hard. Perhaps my book tries to address too broad an audience, and I should just have started with product managers, eg, who are perhaps the ideal people to exploit concepts. @leaverou told me that she thinks the term “software design” is confusing and that PMs think that they do “product design” and not “software design”. My new series (gentle intro) aims to address this.
Too hard. I think that concept design requires a shift of perspective that’s challenging, and it doesn’t fit neatly into existing categories. I gave a keynote at a conference last year and the person who thanked me after told the whole audience that they’d read my book and that it was really hard! I don’t think they meant it badly, but as you can imagine it was a shock to hear that. But I suspect there’s some truth in it. When I look at many of the most successful books on UX, for example, such as Don’t Make Me Think, they’re very straightforward and easy to grasp. Maybe I just need to try harder!
Community. What I’m most keen to do is create a community around these kinds of ideas. The ideas of concept design are deeply intertwined with many other strands of software design work that other people are working on. And people are doing research that either addresses issues in concept design explicitly, or addresses related issues in a way that resolves flaws in concept design. And as I argued in the book, I think the best designers do concept design implicitly (like Moliere’s Monsieur Jourdain who found that he’d been speaking prose all his life). This forum is my attempt to do that, but it needs something more. I’ve suggested in the past that it could be a place for people to get feedback on design problems they’re working on. Or maybe something else?
Investment. My sense is that if a tool is useful enough, it will spread without too much effort. But perhaps that’s naive. Alloy took over ten years to really get going. A good example of an approach that really took off (deservedly, I think) is Eric Evans’s DDD. Interestingly, the key ideas in DDD are very similar indeed to ideas in OMT and JSD decades before, but most people don’t know that.
Key points of leverage. One of the interesting questions is which aspects of concept design to try and explain and promote. I currently see three as most promising. One is the idea in my TEDx talk that concepts characterize the essence of an app; the second is that concepts allow a new kind of modularity (and that’s something that we’re pushing on in my research group as a way to exploit LLMs to build code for entire apps more easily); and the third is the idea that most functionality that people work on is actually completely well understood and familiar, and that most of the design work we do could just be avoided by saying “include here the familiar concept X”.
Anyway, that was more than anyone wanted :-), but thoughts on all of this are most welcome.
Thank you for the thoughts. I think the “toolification” of concepts may be the right way to make things more easy. Your audience should have no intellectual issue grasping your ideas – your anecdote surprises me! – , but probably they prefer doing so by tinkering with tools. Then if it is new tool, the best way is to integrate it smoothly with tools they already use.
Therefore a couple of ideas / questions:
How about transforming the semi-formal notation you used throughout your book into a fully-fledged specification language? Why didn’t you go directly that way from the start? (or maybe you did?.. )
You could then provide “compilers” into other specification languages, such as diagram generators in UML, or programs in Z, Alloy, etc.
The reverse way, do you think you could provide “concept checkers” trying to make sense of Z / UML specs, or even directly code, in terms of concepts? The user would need to provide some hints at what she was trying to achieve. AI could be very good at this. It would then flag redundancies, gaps, ambiguities, etc.
You mention AI at the end of your reply. Yes, I believe that you could make concepts an integral part of an AI-driven specification and programming method. – And maybe advertise the method as AI programming rather than concepts (surf the PR wave ). Today AI is mostly sold as “code completion”. We should develop a method where human and AI co-specify what is needed, the human providing informal concepts (the conceptuel architecture of her application) – the machine making them explicit in your notation, and then translating them into code (the compilation moment).
Maybe that is science fiction. But it is exciting times…
Yes, I’m actually working with my students on several of these things! Nikolai (a visiting student from Denmark) is working with me on an extension of Alloy 6 that would make it easy to model concepts (and then simulate and analyze them automatically). And Barish (an undergraduate researcher) and Diana (a masters student) are devising ways to generate concept and sync code automatically.
Haven’t thought so much about reverse engineering of concepts. My gut sense is that concepts can help you structure your design in a much simpler way, and that if you start out with the concepts intertwined, concepts are going to be less helpful. But I think there might be an opportunity for LLM-based brainstorming that uses a concept catalog to guide ideation.
By tool I didn’t mean a software system but something like a simple notation or process to go through to guide us to ask the right questions. For example, I often use decision matrix when designing because this helps me lay out options and relevant criteria to compare them. It is not very sophisticated but it helps me to think about the problem in a useful way. This talk does a good job at presenting this little tool.
In software design, I feel that most of our current “thinking tools” are ontology-focused. Mainstream OOP encouraged us to ask questions like “What are the nouns of the domain?” While I am very sympathetic to the idea of understanding the domain, I don’t think the nouns of the domain are a sound foundation for the concepts of the software itself. If your domain has the concepts of Customer and Product, should you put the “buy” operation on the Customer or on the Product? This kind of unanswerable question signals to me that this domain-driven approach may not be appropriate.
Hi @benfle: I love your idea of a tool akin to the decision matrix—a simple representation that would capture some critical aspects of concept design. I wonder if the scenario diagrams that I introduced in that piece could play that sort of role. You could annotate the actions with info about what makes an action annoying or difficult (rather than just using the red color).
)
). Today AI is mostly sold as “code completion”. We should develop a method where human and AI co-specify what is needed, the human providing informal concepts (the conceptuel architecture of her application) – the machine making them explicit in your notation, and then translating them into code (the compilation moment).