After my ACM Tech Talk last Weds (Dec 1), I promised to answer all the questions that came in in writing that I didn’t get to in the session. So here are my responses, with a post for each question so that we can follow them up individually.
Thank you all for the great questions! To my amazement, there were apparently 1400 people in the session! And thank you again for Yan Timanovsky for hosting me, and George Fairbanks for moderating.
What about the role played by clients who don’t actually know what they need, just what they think they want?
Concepts might help with this in two ways. First, by encouraging requirements to be developed by starting with existing concepts, which clients are familiar with and more likely to be able to assess accurately; and second, by the focus on purpose. A client might say they want a “like button” for example, but as I explained in the talk, there are at least three very different concepts that all have a like button and appear superficially similar but actually have different purposes.
How does concept design impact unit testing?
By making functionality more modular, concepts should make units tests easier to formulate. Also, if you’re implementing a standard concept, prior knowledge of that concept suggests tests you might not have considered.
By making functionality more modular, concepts should make units tests easier to formulate. Also, if you’re implementing a standard concept, prior knowledge of that concept suggests tests you might not have considered.
You can go systematically through each of the concept’s actions to make sure they are available in the interface, and analyze the concept state to make sure that each of its components is accessible in the interface.
Neil O asks: Of the three puzzles/defects you presented, it seems that what was actually defective was the naming of the GUI widget/function, and the failure to correctly inform/document for the user what the functions do, and could have been fixed by naming and telling the user. What about fundamental design defects where the functionality provided is bizarre or pathological, as with a lot of services from the big name companies?
Actually, I don’t think that’s true. In the very first puzzle (the Dropbox one) the problem is about the underlying concept and its behavior and structure. Of course it wasn’t “pathological”—it’s built on the Unix directory concept. But it still has serious usability problems, which incidentally are encountered in other apps that use the Unix file system (as explained in the book). The problems you’re referring to I would associate more with apps that have no coherent concepts at all: Adobe Acrobat was like this in its early days for example, when it was really just a kitchen sink of tools for manipulating PDFs without a coherent conceptual design (but was later much improved). Concept design helps in both kinds of systems: in the first because the issues can often be readily diagnosed as standard conceptual design flaws (such as the over-sync problem I discussed for Google Calendar) and in the second because clarity can be brought by introducing robust concepts (preferably familiar ones, until proven inadequate).
Bashar N asks: Great ideas Daniel - can you comment on the relationship or boundary between traditional software “requirements” and concepts?
Thank you! And nice to hear from you.
Concepts allow you bring a new modularity to requirements. In a social media app, for example, they would give you a clean separation between posting, commenting and upvoting functionality, all of which might be addressed together in a traditional development (eg, because they’re all functions associated with posts). Identifying reusable concepts should allow you to reuse their requirements, and to make describing requirements more like parameterizing than formulating. For example, if you were writing the requirements for access control, you might first pick a concept—-say personal access tokens—-and then decide which features of that concept you wanted (expiry? revocation? fine-grained control?). The impact of all this, I believe, would be more efficient and effective requirements engineering in terms of concrete functionality, leaving room to focus on questions that concept design does not (yet!) address, about the overall purposes and motivations of an app (for example, the kind of social engagement you might want to create).
Juan A asks: Will a user always need a tutorial to understand a concept?
I agree with prevailing design wisdom that ideally a system should not need a user manual or tutorials. But that generally only works when the user is already familiar with the concepts that the system uses. For example, a well-designed online store shouldn’t need a manual because we all know concepts such as “shopping cart” well, and we’re not surprised that when you click on an item to buy it, you’re not actually buying it yet. If the user doesn’t know the concept, there’s no way round it: they’ll need a tutorial of some sort (which might of course be embedded in the UI). In practice, software developers often underestimate the novelty and complexity of their concepts, and it would help users if they explained the concepts directly rather than just providing help facilities that atomize the explanation into lots of little pieces for the many different things you might want to do. This is perhaps why “X for dummies” books sell so well, because they often do actually explain the concepts.
Stefania A asks: What is the difference between the Upvote and Karma concepts?
Aside from a superficial similarity — they’re both a form of crowd-sourced rating, Upvote typically for a social media post and Karma for a person — they have different purposes and different behaviors. Simplified models of both appear in the talk slides. I’ve posted a full draft catalog entry for Upvote at https://forum.essenceofsoftware.com.
Juan A asks: How hard is it to organize software around concepts if it’s already been developed?
Great software designers naturally tend to introduce concept like structures and modularization. If the code is very monolithic, with all the concepts intertwined, refactoring would be necessary to make it concept-structured. But the benefit of viewing the design in terms of concepts can be obtained without changing the structure of the implementation!
Howard T asks: The Upvote concept introduces a feedback loop. If higher ranked items appear first, users are less likely to see lower ranked posts and upvote them.
Great point! This is a fundamental design flaw in the standard form of the Upvote concept. There are variants of the concept that partially address this. For example, in Hacker News, the number of upvotes alone does not determine the rank, but the age of the post is used too, so newer posts get a boost.
Jeremy D asks: I read Design by Concept where you presented many of these ideas. I found that as I read the book, I started to see concepts as an additional level in the pattern hierarchy. We have design patterns and architectural patterns. I’m seeing concepts as the next level up in patterns. Essentially, another layer of heuristics. Do you see it that way?
Yes, I think you could see concepts as providing a higher level of pattern, closer to the user’s experience and offering an encapsulation of all the functionality associated with a particular feature. Design patterns and architectural styles tend to be much more code-focused though, and don’t give you a way to structure behavior independently of the implementation.
Peter S asks: Would you suggest identifying Concepts as a useful way of designing an Interface into a system? Am thinking of REST APIs and wondering if Concepts are related to Resources?
Yes, I think concept design would apply well to the design of web services and service interfaces more generally. A concept may sometimes be associated with a single resource (type), but I think you’d find that a concept often involves several.
Peter S asks: Would you suggest identifying Concepts as a useful way of designing an Interface into a system? Am thinking of REST APIs and wondering if Concepts are related to Resources?
Yes, I think concept design would apply well to the design of web services and service interfaces more generally. A concept may sometimes be associated with a single resource (type), but I think you’d find that a concept often involves several.
Alex V asks: More of a comment than a question: I misread the title and thought this was about the OMG Essence standard on the essence of software engineeeing. Does make me wonder, though, whether the ideas presented here should be included as an alpha that represents the business of clarifying and designing the concepts?
I don’t know much about the OMG Essence Standard, I’m afraid. I do think that concept design should be a major part of the early phases of design, both for better reuse of design ideas, and for better modularity of function, and AFAIK, neither of these is a feature of the OMG standard.
Dennis M asks: Is it possible that there are “fatal interactions” between concepts? (cases where two concepts conflict so much that they can’t be implemented in the same system?)
I think this is unlikely, because concepts are generally independent of one another until you compose them, and then you have a lot of control about how much to synchronize them. I could imagine you getting into trouble if you tried to use two different concepts for the same purpose, for example using RBAC and MLS as access control concepts in the same system, without carefully dividing up responsibility. If you over synchronize concepts, you can certainly get into trouble (as my Calendar example illustrated), and there are other examples of synchronization problems in the book.
Stephen S asks: From your experience view point, do you think inclusion of FMs in the early stages of system development with could eliminate failure. If yes, kindly explain
Formal methods can’t eliminate failures, but they can help reduce them. I believe FMs can be made more powerful and more affordable if they are applied in the context of concept design, with the most critical concepts being defined and analyzed formally. Note also that in a critical system, preventing failure requires explicit modeling of the environment. I believe this can be done with concepts, but I haven’t looked into it much yet.
Anthony J asks: How is a concept and its purpose, state, actions, and its operational principle, best captured/implemented in python for example as a set of classes and functions - is there a baseline pattern for this?
The purpose is not something you’d capture in code. The actions could be implemented as functions, backed by a database or by classes that implement the data types of the state.
Carlos V asks: Does the downvote “wait for” the rewards to build up? In CSP, communication is synchronous, but nothing else can happen in a process until the communication is enables and actually happens…
In CSP, a process only blocks on an action if no other action is available. So if downvote can’t happen, but upvote can, then upvote is not blocked.
Estiben B asks: Did Twitter discover that flaw and correct it? How long did this process take?
Yes, Twitter did eventually realize that the Upvote concept was not suitable for saving tweets you wanted to revisit later, and they eventually added a separate Bookmark concept in 2018.
Meghna B asks: Was the Dropbox case also a synchronization problem too?
Yes, I only told part of the story: the difficulties people have with understanding Dropbox arise from both the Sync concept and the Unix folder concept. In the example I open with in my book, someone deleted files on their laptop, not realizing they were synced with Dropbox. Just moving the files to the trash on the Mac moved them out of the Dropbox folder, and the next sync caused them to be deleted in the Dropbox cloud. Luckily, Dropbox also uses the Trash concept, so she was able to restore her files. Things don’t always end so well though. Later in my book, I give an example of a problem of losing files due to the sync concept in Google Drive.