I’ve listened to the webinar twice, and read the book once. Thoroughly enjoyed both. But I’m still having trouble coming up with a succinct, convincing explanation to my software development colleagues for why “concept” is not, at least in some case, just an unnecessary new word for “feature”. And notwithstanding the short summary (here on the forum) section on “feature-oriented development”, which I don’t disagree with, I still can’t see why, for example, “upvoting” is not a feature. @dnj can you clarify?
1 Like
@TalkAboutQuality: For me, the difference is between what something is, in terms of the artifact, and what something is for. I think of the latter as tied to integrity of the conceptual model that is intended to be evoked in the delivery of features. One would like the cases to be harmonious and, again as it seems to me, one can’t achieve that without addressing the concept. Think about the specific nature of a feature even though it is conceptually consistent (or maybe not, depending on how use of the feature is recognized in practice).
I’m interested in how @dnj clarifies also. Consider how “likes” and “upvoting” are different, and from “rating” too. I just gave 2/5 stars in a review on Amazon. I had to provide a review in order for the rating to be accepted. And the review was then accepted by whatever that machinery is. Since the reviewed item has over 85% 5/5 stars, I am in a considerable minority in that case, yet my review might be helpful to some similarly-interested folk. It is also rare for me, as an Amazon reviewer, to find something so lacking.
@TalkAboutQuality: Thank you so much for this question! I’ll try to answer it carefully at some length, as I think it’s an important one.
TL;DR Most (or even all) concepts could be represented as features. But most features are not concepts, and it is the special properties of concepts, and the new way they give you to think about software, that bring benefits.
Novelty in restriction. One of the paradoxes of software is that we often make progress by restricting things, and consequently new things may be “just” subsets of old things. So an abstract data type is just a kind of module; an immutable object is just a kind of object that can’t be modified; a REST API is just a kind of interface; a microservice is just a kind of process; pipe-and-filter is just a communication architecture; an append-only log is just a…; well, you get the idea.
Restriction and properties. What makes all these notions useful is that the restrictions make new things possible. You can think about it in terms of sets. Given a set S, you can define a subset S’ such that every element of S’ satisfies some property P. Then every S’ is an S, but any S that is not an S’ does not satisfy P.
Concepts vs. features. And so it is with concepts and features. Let’s grant for now that all concepts are features (but more on that later). Two key properties, explained in detail in EOS, characterize concepts: that they are independent and that they are purposive. Most features lack these properties, because they depend on other features, or because they do not have a unity of purpose (from the user’s perspective).
In particular, this means that non-concept features generally won’t be reusable across applications. This illuminates a fundamental difference in the goals behind these notions. Features were invented as a way to organize all the variants of a product family, and a major concern was which combinations of features were compatible. Concepts were invented primarily as a way to capture commonalities of user-facing behavior across apps. Features are more about organizing code; concepts about organizing behavior.
Upvote example. Let’s look at the example you proposed, the Upvote concept. The purpose is to rank items by popularity, and the independence is clear (since the concept is used in countless apps for different types of targets). This concept could be represented as a feature. But what’s more relevant for understanding concepts is that some closely related features would not be concepts:
-
A feature may be too small to be a concept. You could implement Upvote in two parts: (1) the mechanism for clicking upvotes and downvotes, and (2) the algorithm for determining ranking of items based on these clicks. These could be separate features, but they couldn’t be separate concepts. The purpose of the Upvote concept can only be fulfilled if it includes both the clicking and the ranking. Every concept has to be “end to end” with respect to its purpose, as demonstrated by the operational principle.
-
A feature may be too big to be a concept. In HackerNews, you can’t downvote a post until you have received some number of upvotes for your own posts. Suppose this behavior were included inside Upvote. This would be a mistake, because the resulting concept would have two distinct purposes: determining ranking (which is the purpose of the Upvote concept) and tracking good user behavior (which is the purpose of a separate concept that we might call Karma). Merging these two concepts into a single concept would not be good, first because the resulting concept is rather idiosyncratic and not likely to be suitable in other contexts. Also, by separating out the Karma concept, it would be easier to evolve the notion of karma (eg, by rewarding other kinds of actions).
The concept lens. More broadly, the notion of concepts makes it possible to explain more systematically than before why some designs are good and some are bad. The EOS book is full of such examples. This is my most provocative claim: that if you look at a design through the lens of concepts, you will be able to understand it more deeply, and more easily see opportunities for improving it. For example, thinking of the behavior of HackerNews as a composition of distinct Karma and Upvote concepts lets you see immediately ways in which the functionality might be enriched or adjusted, and also suggests how to modularize the code.
Concepts for base functionality. Earlier I hinted that not all features might be concepts. In concept design, there is no distinction between the base functionality of an app and augmentations. So in a question-and-answer app (like Quora or StackExchange, for example), the base functionality would be defined using concepts such as Q&A, Comment, User, Tag. In informal usage, this base functionality is not generally described as comprising “features,” although in more mathematically based feature frameworks (such as Batory’s AHEAD), the empty app is considered valid, so the base functionality can be constructed by applying the base features to the empty app.
Let me know whether this makes sense!
3 Likes
Hi @dnj thanks for your thorough reply. Though there may be a few points I’m not satisfied with here, I’ll focus on the main one, which is the need for this new entity type name “concept”, when “feature” already exists. Of course, if your assertion, copied here, is true, then you’ve explained why:
“Two key properties, explained in detail in EOS, characterize concepts: that they are independent and that they are purposive. Most features lack these properties, because they depend on other features, or because they do not have a unity of purpose (from the user’s perspective).”
Before I read your book, had I been asked whether “independent” and “purposive” were essential properties of a properly-defined feature, I would have replied:
“purposive”? Of course – that’s what defines “feature”: I add a feature with some purpose in mind. No purpose, no feature. If one had asked me further, as you require for your concepts, whether each feature must have one and only one purpose, I would have said, “well, that would be ideal, and exemplify clear thinking”. “In fact,” I would have volunteered, “the feature name should succinctly express the purpose”.
“independent”? I would have replied that that would be highly desirable, and no reason why a feature should not have that property, because separation of concerns is an important design principle for ease of modification.
Thus it seems to me that the only remaining justification for bringing a new term “concept” would be if this qualitative statistical assertion is true:
“Most features lack these properties, because they depend on other features, or because they do not have a unity of purpose.”
Here in your reply you invented some examples, understandably, to explain your point, of what I would simply call poorly (or at least suboptimally) defined features. In the webinar you brought 3 real life examples of poorly implemented features. I rate the implementations as poor because their usage was error-prone. The root cause may have been poor design, and possibly (though I’m not sure), the manner in which design was poor is that the features’ definitions lacked single purpose or independence.
But that leaves “feature”, in your assertion, with the bad reputation of “most”. “Most features lack these properties …” If it’s “most”, examples should be in the majority and easy to come by. Hidden (from me) in plain sight, as it were.
I know you mentioned a few such features (various font and style menus) in the book, with full detail. But until shown otherwise, I have to assume you picked those examples to elucidate your thesis, without needing to show that these examples were representative of a majority of features.
Towards convincing me (and I’ll be happy to be convinced) that such deficient features are in the majority,
would you be able to throw out 5 - 10 examples – just the names – no detail needed, of well-known features in major software packages today that are not single-purpose or not independent?
Note that I have not ignored your historical comment about how “features” may have been tasked primarily with deploying compatible behavior subsets, but my experience has been that that’s more about the term “feature” used in codebase configuration (feature flags) and not about “feature” as a basic fulfillment of a purpose to satisfy a user.
It doesn’t seem productive to argue about whether I should have used the word “feature” instead of “concept”. I could have written the whole book and done my entire project for the last ten years using that word instead, and the research would have been no different, and it would have been about how to think if an app’s design in terms of features, and what the difference is between a good feature and a bad feature.
In fact, for a while, I considered exactly that. But I was drawn to the word “concept” for several reasons. First, it was more often the term used by people searching for a notion of integrity for units of functionality. Second, I wanted it to include the base units of functionality in an app (such as the paragraphs of Microsoft Word, or the slides of Keynote, or the status updates of Facebook) and people generally didn’t use the word “feature” for such things, preferring it for additions to an app’s functionality, or to highlight differences from other apps. And third, the term “concept” hadn’t already been used in software design for something very specific: it was up for grabs, as it were. The word “feature”, in contrast, had already been used very specifically in feature-oriented programming with the intent of precisely allowing features to have dependences on one another, and so it didn’t seem wise to overload the term with a different meaning, even it aligned with how many users of software think about the word.
I’m not sure much is to be gained by checking how people use the word “feature” but I did a few quick searches for features of some apps that came to mind. The Backblaze “features” in this list are mostly not even increments of functionality; the Word “features” in this list are mostly not independent; the Keynote features in this list are concept like, though.
Your criticism of my Karma/Upvote example makes it seem as if I was trying to say that most features of apps are bad. On the contrary, most features of apps (in the sense that you seem to want to use the term) are actually good, because they’ve evolved over time (and the best survive). My aim is to try and explain some design principles that can help us design good features or concepts, whatever you want to call them.
Regarding being purposive: I think you’re being a bit dismissive here. Of course anyone who builds anything has a reason to build it, and in that sense a “purpose”. What concept design tries to do is enrich that notion of purpose, to help us find greater clarity and modularity in our designs. I have found that by making purposes very explicit, and working hard to articulate them, I often discover confusions in my thinking.
This idea first arose, btw, in our study of Git (and see Greg Wilson’s nice review), when we were trying to make sense of the index/staging area concept, and finally came to realize that what was so confusing about it was that it didn’t have a clear purpose, and that when asked what its purpose is, Git experts tend to give a list of disparate uses.
1 Like
@dnj Thanks very much for explaining your reasons for adding the term “concept” to the vocabulary of thinking about software design. And in your reply, you’ve given me the material I will explore and absorb, to begin to feel that which “concept” adds.
1 Like
As someone trying to operationalize these ideas professionally, I’d also mention that concepts feel more foundational than features - e.g. many features can be built on top of the same concepts, and concepts tend to evolve more slowly than features. From an organizational design perspective in a sufficiently complex application suite, concepts tend to be cross-cutting; the harmony of product suite depends on consistency between concepts. Often, teams will end up re-implementing “convergent concepts” which then create usability problems because power users of one app don’t know how to use the concepts in a peer application. I’ve often seen a “feature” in one app become ratified into a “concept” that underpins multiple features and spans multiple apps. In our internal knowledge management system, we have an ontology of “Components” made up of “Features” which is used for bug filing and software dependencies, and we also have an ontology of “Concepts” which end up being things that users have to understand in order to use all the features. In our system, these concepts each have a reserved icon, name, description and documentation URL, and tend to be things that we cover in user training; concepts tend to be most prominent in product documentation (how to use the product in general) while features end up being very prominent in workflow documentation (how to use the product to achieve an end-to-end flow).
Prior to reading these papers, we used the word “primitives” but have updated our internal lexicon to match EOS.
I would consider @dnj to be the authority, of course, but I do think that there is a practical and qualitative difference - as kuhn says, the best paradigm isn’t true, but rather more effective for problem-solving, and I’d say that the Concept idea has helped us solve a lot of problems more effectively and have a shared lexicon for expanding and evolving the foundational aspects of the product.
2 Likes
Thanks again, @dnj. Here is the summary I constructed for internal use, excerpting and paraphrasing from your response.
Daniel Jackson added “Concept” to the vocabulary of design thinking, rather than trying to refine people’s understanding of the term “feature” because:
Concept
…was more often the term used by people searching for a notion of integrity for units of functionality.
[could] include the base units of functionality in an app (such as the paragraphs of Microsoft Word, or the slides of Keynote, or the status updates of Facebook) and people generally didn’t use the word “feature” for such things, preferring it for additions to an app’s functionality, or to highlight differences from other apps.
… hadn’t already been used in software design for something very specific.
And main insight from my summary (paraphrased quote):
Making purposes very explicit, and working hard to articulate them, highlights confusions in our thinking.
1 Like
Now that I’m beginning to absorb the idea of “concepts”, I think I saw an example yesterday of a “feature” which is not a “concept” – in WordPress administration.
Of course “post” is a concept for blogging platforms. But when I returned to WordPress to open a new blog, many years after opening a previous blog, I discovered that they had simplified the administration interface and I was missing “features” like being able to adjust a post’s date, or add tags. This capability “ability to manually adjust attributes of a post, after posting” is certainly a “feature” (and I found it in their “WP Classic” admin view), but it’s not a “concept”. Either because it is “too small” (a small part of “post”, and in fact of the subset “post administration”), or because it is clearly not independent (the feature is meaningless without the concept of a post).
Thanks @pwilczynski for the interesting comments!
Ultimately what matters, in my view, is not what names we use and whether we can defend them but whether we can find new ways to talk about software design that actually help in practice.
And while I hope my concept design work offers some novel ideas, the goal (as I explain in the intro to EOS) is not to upend all our current ways of working, but to find structure and language to deepen and systematize understandings that we already have.
1 Like
@TalkAboutQuality : That’s a great example! I’d agree with you that the increment of functionality that just allows you to modify the date of a post (and nothing more) is more like a feature than a concept. I might even call it a “feature” of the “post concept”. We can tell that it isn’t a concept because it doesn’t have a compelling purpose or operational principle.
But we can ask a different question: what would this feature look like if it became a full-fledged concept? That is, we can focus not on using the idea of concepts for classifying functionality but also to suggest design moves.
In this case, two moves (“conceptualizations”?) come to mind:
-
We could generalize the date field to a Metadata concept, where the purpose is to classify items, and the operational principle says that if you set a metadata field F of item X to the value V, you can then find X again by filtering all items on F=V.
-
We could expand the functionality of the date field to a TimedPost concept (say). The purpose of this concept is to let you build a publishing space in which you include posts that only appear at certain dates and times; the operational principle might be that if you give a post a publication date of D and an expiry date of D’, then the post appears only on dates between D and D’. This is of course exactly what happens with blog post dates in many blogging platforms. In static website builders like Hugo, it’s even nicer, because the concept is applied uniformly to all pages (see explanation here). Another symptom that this is a concept is that it presents some interesting design challenges. For example, what happens if item X has a link to item Y, and item X is live but item Y is not? In Hugo, you just get a 404, which is reasonable, but perhaps not what all users would expect. There’s also a question of whether the draft status of an item should be part of this concept or should be independent.
1 Like
I like the idea of “design moves”. It makes design like a game, where you have to figure out your next move.
Just playing/practicing with your second example here, seems to me that Status (draft, published) is a separate concept, whose purpose is to separate between “the content is not finished yet”, and “the content is finished”. The publish date (attribute of a Post) if expanded to a PublishedPeriod concept, is orthogonal, with a purpose of determining when content, that is already finished, is made available to viewers. A third concept involved is Permissions, deciding who can view content. This line of thought also brings up questions, such as whether “view” vs “edit” are values of some parameter of Permissions, or, for example, in the world of Zero Trust security, should “what you can do with an item” be very separate from “can you know an item exists?”
1 Like
@TalkAboutQuality : you’re absolutely right that Status and PublishedPeriod (as you call them) should be separate concepts, because they indeed have very distinct purposes! And Permission is certainly a separate concept (or several concepts in general, such as RBAC, ACL, etc).