What do you think?
Rate this book
The Essence of Software: Why Concepts Matter for Great Design
A revolutionary concept-based approach to thinking about, designing, and interacting with software
As our dependence on technology increases, the design of software matters more than ever before. Why then is so much software flawed? Why hasn’t there been a systematic and scalable way to create software that is easy to use, robust, and secure?
Examining these issues in depth, The Essence of Software introduces a theory of software design that gives new answers to old questions. Daniel Jackson explains that a software system should be viewed as a collection of interacting concepts, breaking the functionality into manageable parts and providing a new framework for thinking about design. Through this radical and original perspective, Jackson lays out a practical and coherent path, accessible to anyone―from strategist and marketer to UX designer, architect, or programmer―for making software that is empowering, dependable, and a delight to use.
Jackson explores every aspect of concepts―what they are and aren’t, how to identify them, how to define them, and more―and offers prescriptive principles and practical tips that can be applied cost-effectively in a wide range of domains. He applies these ideas to contemporary software designs, drawing examples from leading software manufacturers such as Adobe, Apple, Dropbox, Facebook, Google, Microsoft, Twitter, and others. Jackson shows how concepts let designers preserve and reuse design knowledge, rather than starting from scratch in every project.
An argument against the status quo and a guide to improvement for both working designers and novices to the field, The Essence of Software brings a fresh approach to software and its creation.
As our dependence on technology increases, the design of software matters more than ever before. Why then is so much software flawed? Why hasn’t there been a systematic and scalable way to create software that is easy to use, robust, and secure?
Examining these issues in depth, The Essence of Software introduces a theory of software design that gives new answers to old questions. Daniel Jackson explains that a software system should be viewed as a collection of interacting concepts, breaking the functionality into manageable parts and providing a new framework for thinking about design. Through this radical and original perspective, Jackson lays out a practical and coherent path, accessible to anyone―from strategist and marketer to UX designer, architect, or programmer―for making software that is empowering, dependable, and a delight to use.
Jackson explores every aspect of concepts―what they are and aren’t, how to identify them, how to define them, and more―and offers prescriptive principles and practical tips that can be applied cost-effectively in a wide range of domains. He applies these ideas to contemporary software designs, drawing examples from leading software manufacturers such as Adobe, Apple, Dropbox, Facebook, Google, Microsoft, Twitter, and others. Jackson shows how concepts let designers preserve and reuse design knowledge, rather than starting from scratch in every project.
An argument against the status quo and a guide to improvement for both working designers and novices to the field, The Essence of Software brings a fresh approach to software and its creation.
336 pages, Paperback
Published June 20, 2023
76 people are currently reading
396 people want to read
About the author
Daniel Jackson
6 books14 followersDaniel Jackson is professor of computer science and associate director of CSAIL, MIT’s largest lab. His software research won an Impact Award and Outstanding Research Award from the Association for Computing Machinery, and he is an ACM Fellow. He is lead designer of the Alloy software modeling language. He led a National Academies study on software dependability, and has collaborated on software projects with NASA on air-traffic control, with Massachusetts General Hospital on proton therapy, and with Toyota on autonomous cars.
Jackson is also a photographer. His book Portraits of Resilience, which combines stories and images of people who've experienced mental health challenges, was featured on PBS's Newshour and NPR’s Here and Now.
Jackson is also a photographer. His book Portraits of Resilience, which combines stories and images of people who've experienced mental health challenges, was featured on PBS's Newshour and NPR’s Here and Now.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 13 of 13 reviews
December 8, 2021
The name of the book is quite a large claim, but I think Daniel Jackson has pretty much fulfilled it, although he does say he’s attempting to start a conversation here, not finish one. The final chapter is a list of future questions and directions.
The book is about using “concepts” as a way of designing software, from the high level strategist looking for market openings, to programmers building it and writers authoring technical or product documentation. Jackson’s formulation of concepts is almost as simple as user stories, but they are rigorous enough to be load bearing. Importantly, how various concepts are fit together into a larger product is directly addressed, and one of the key themes.
Part of the motivation of concepts is communication, with the user and between all the people building the software. The goal is to have a communication tool, in concepts, that is clear and rigorous enough to help everyone align their mental models. There are threads of this in domain driven design (DDD), but that is much more complex and the focus of DDD is much narrower.
One of the compelling things about concepts, reading this as a software engineer, is how concepts provide a clear framework for achieving modularity. My gut reaction reading this was, at times, that all the “rules of thumb”, like SOLID, cohesion, DRY, etc, are now obsolete. This is a much stronger framework to think about these things.
Another thing that appeals to me about this idea is how there’s a clear sliding scale of rigor, from informal “back of the envelope” (similar to user stories) all the way to formal modeling. Jackson only alludes to the latter, but he created the Alloy modeling language and in one or two places, he shows what is an outline of a valid alloy spec for a concept. I can imagine a stage in concept based software design where the informal discussions are turned into formal models and checked for security and consistency problems.
Finally, something that makes the book entertaining is all the examples drawn from real world software. Jackson doesn’t just talk abstractly about a mental framework, he draws examples from Dropbox, Google Drive, Gmail, Keynote, Textedit, Powerpoint, Adobe Lightroom, Photoshop, and many others. I don’t think there’s more than two consecutive pages without a real life example in the main text. Even the endnotes, which constitute about half the book, are packed with examples from real software.
The book is about using “concepts” as a way of designing software, from the high level strategist looking for market openings, to programmers building it and writers authoring technical or product documentation. Jackson’s formulation of concepts is almost as simple as user stories, but they are rigorous enough to be load bearing. Importantly, how various concepts are fit together into a larger product is directly addressed, and one of the key themes.
Part of the motivation of concepts is communication, with the user and between all the people building the software. The goal is to have a communication tool, in concepts, that is clear and rigorous enough to help everyone align their mental models. There are threads of this in domain driven design (DDD), but that is much more complex and the focus of DDD is much narrower.
One of the compelling things about concepts, reading this as a software engineer, is how concepts provide a clear framework for achieving modularity. My gut reaction reading this was, at times, that all the “rules of thumb”, like SOLID, cohesion, DRY, etc, are now obsolete. This is a much stronger framework to think about these things.
Another thing that appeals to me about this idea is how there’s a clear sliding scale of rigor, from informal “back of the envelope” (similar to user stories) all the way to formal modeling. Jackson only alludes to the latter, but he created the Alloy modeling language and in one or two places, he shows what is an outline of a valid alloy spec for a concept. I can imagine a stage in concept based software design where the informal discussions are turned into formal models and checked for security and consistency problems.
Finally, something that makes the book entertaining is all the examples drawn from real world software. Jackson doesn’t just talk abstractly about a mental framework, he draws examples from Dropbox, Google Drive, Gmail, Keynote, Textedit, Powerpoint, Adobe Lightroom, Photoshop, and many others. I don’t think there’s more than two consecutive pages without a real life example in the main text. Even the endnotes, which constitute about half the book, are packed with examples from real software.
January 10, 2024
Like many strong works of theory, The Essence of Software provides a language for talking explicitly about a topic that heretofore has remained tacit. I came across EoS after grasping for something similar during ~8 years of running increasingly large software development teams, and because it provides a very helpful mental model for how to think about the design process, it has become required reading for many people I work with.
Similar to other books about software architecture (e.g. Design Patterns, Domain-driven Design, Effective Java) EoS is focused on the nature of software itself. But unlike those books, it focuses much more heavily on the user experience and the process of learning that must occur in the mind of a user in order to be able to successfully use the software as opposed to the structure of the source code. This book, therefore, is not just for developers - it applies cross-functionally for anyone designing novel experiences (especially designers).
Perhaps the most overlapping idea in the literature is the idea of progressive disclosure - using the interface itself to represent increasing levels of complexity as the user navigates through a nested pathway of menus and experiences. Rather than focusing on the interface, EoS focuses on concept design - the way that software designers create new concepts which must be transmitted almost pedagogically to their users. These concepts live in the interstitial space between source code and user experience and are traditionally understood informally by the teams that design them.
Steve Jobs famously said "software is a bicycle for the mind" - the type of concept design advocated in EoS is about designing the bike to be ridden, and helping teach people how to ride it. As such, EoS exudes an emancipatory aesthetic in which users can actually surpass the intent of the designer by stringing together well-designed concepts to construct emergent workflows rather than being stuck on the happy path that the designer anticipated (a la the Unix Philosophy).
If there's one thing missing from EoS, it's a model for how concepts evolve - the delicate interplay between the genetic (source code) and phenotypic (concept map) aspects of a given software program. He discusses this in various asides, but as of now, his conceptual theory is like the "statics" of 7 powers - necessary for describing an application, but insufficient for designing one. He needs to further explore the "dynamics" of concept mapping next.
Edit: Dr. Jackson and I worked together with Taylor Gregoire-Write to explore this topic in a recent paper that's available here: https://arxiv.org/abs/2304.14975#
Similar to other books about software architecture (e.g. Design Patterns, Domain-driven Design, Effective Java) EoS is focused on the nature of software itself. But unlike those books, it focuses much more heavily on the user experience and the process of learning that must occur in the mind of a user in order to be able to successfully use the software as opposed to the structure of the source code. This book, therefore, is not just for developers - it applies cross-functionally for anyone designing novel experiences (especially designers).
Perhaps the most overlapping idea in the literature is the idea of progressive disclosure - using the interface itself to represent increasing levels of complexity as the user navigates through a nested pathway of menus and experiences. Rather than focusing on the interface, EoS focuses on concept design - the way that software designers create new concepts which must be transmitted almost pedagogically to their users. These concepts live in the interstitial space between source code and user experience and are traditionally understood informally by the teams that design them.
Steve Jobs famously said "software is a bicycle for the mind" - the type of concept design advocated in EoS is about designing the bike to be ridden, and helping teach people how to ride it. As such, EoS exudes an emancipatory aesthetic in which users can actually surpass the intent of the designer by stringing together well-designed concepts to construct emergent workflows rather than being stuck on the happy path that the designer anticipated (a la the Unix Philosophy).
If there's one thing missing from EoS, it's a model for how concepts evolve - the delicate interplay between the genetic (source code) and phenotypic (concept map) aspects of a given software program. He discusses this in various asides, but as of now, his conceptual theory is like the "statics" of 7 powers - necessary for describing an application, but insufficient for designing one. He needs to further explore the "dynamics" of concept mapping next.
Edit: Dr. Jackson and I worked together with Taylor Gregoire-Write to explore this topic in a recent paper that's available here: https://arxiv.org/abs/2304.14975#
March 23, 2022
"Good design has a quality of inevitability about it."
We all know what good design feels like, and it's the designers job to make stuff that is enjoyable, learnable and effective for the user, no matter what their goals might be.
Daniel Jackson argues that 'concepts' characterize apps, from gmail to Microsoft Excel and everything in between. We should build software that is made up of lots of concepts that have clear, user driven purposes and that work well together. The theory really resonates with me as a software designer, and it's certainly fresh, considering a lot of design discourse these days is focused on tech (design systems, components), ethics or process and methods.
There are a ton of examples, and the author admits they get tedious at points, but are probably needed to explain the importance of concepts and where they can go wrong. It would have been good to see a few examples from radically different areas of software like Enterprise resource planning or something like that. My other concern is product design is so often constrained by tech limitations, org complexity, business models and goals, it would be rare to get 'free reign' or the influence to design as 'cleanly' as Daniel urges.
We all know what good design feels like, and it's the designers job to make stuff that is enjoyable, learnable and effective for the user, no matter what their goals might be.
Daniel Jackson argues that 'concepts' characterize apps, from gmail to Microsoft Excel and everything in between. We should build software that is made up of lots of concepts that have clear, user driven purposes and that work well together. The theory really resonates with me as a software designer, and it's certainly fresh, considering a lot of design discourse these days is focused on tech (design systems, components), ethics or process and methods.
There are a ton of examples, and the author admits they get tedious at points, but are probably needed to explain the importance of concepts and where they can go wrong. It would have been good to see a few examples from radically different areas of software like Enterprise resource planning or something like that. My other concern is product design is so often constrained by tech limitations, org complexity, business models and goals, it would be rare to get 'free reign' or the influence to design as 'cleanly' as Daniel urges.
October 21, 2024
- the examples are really really good. Trash and Dropbox and the discussion of Gmail in particular really serve to illustrate the core ideas behind "Concepts". I've found myself referring to them in conversations similar to how I use Don Norman's discussion of stove controls in Design of Everyday Things. The examples also made me way more aware of the design of lots of products I use today.
- I've been pushing my team a bit on Domain Driven Design and specifically some ideas from Domain Driven Design Made Functional by Scott Wlaschin. I've seen a couple of people with lots of OOP backgrounds have trouble with DDD. The idea of Concepts from a user / non-programmer perspective makes it easier to reason about what a "Domain" is. As a Palantirian and "product engineer", it's never sat well with me that the domain is "discovered". [I really like your paragraph in the paper comparing the two]. And unfortunately, lots of DDD material also tends to end up falling back to software development patterns which overcomplicates things, especially in small code bases, which is why I tend to fall back to "what is the domain" rather than "how will we implement the domain". In reality, no, I'm not going to have separate DBs for my separate domains representations of the same underlying object when the schema is 99% identical and I want synchronization 100% of the time. Concepts / EOS seem to get at similar core ideas and is a better book for a cross-functional team book club than DDDMF so I'm looking forward to that at the next job.
- I immediately started using the ideas in the book (though not formally modeling yet) to unravel a problem at work. I'm currently at Photon where we pretty much get prescriptions from the doctor to the pharmacy by putting the patient at the center. Our core data model (read, Concept) is currently "Order" which is a list of "Prescriptions" (A Prescription is a medication and dosage + how many times it can be refilled). An "Order" is overloaded as a concept, serving simultaneously as "a list of prescriptions written during the course of a single doctor visit", "a list of prescriptions a patient wants to pick up at once", and "a list of prescriptions we track as a unit". This immediately breaks down when there's an issue with one prescription in an order (for example, Drug A is out of stock but B is in stock). I've mostly been using DDD to think about the problem as "Write", "Place", "Track" but Concepts and EOS gives me other language and approaches that are more readily communicated to the designer and Product people.
Thanks to Peter W for the rec.
- I've been pushing my team a bit on Domain Driven Design and specifically some ideas from Domain Driven Design Made Functional by Scott Wlaschin. I've seen a couple of people with lots of OOP backgrounds have trouble with DDD. The idea of Concepts from a user / non-programmer perspective makes it easier to reason about what a "Domain" is. As a Palantirian and "product engineer", it's never sat well with me that the domain is "discovered". [I really like your paragraph in the paper comparing the two]. And unfortunately, lots of DDD material also tends to end up falling back to software development patterns which overcomplicates things, especially in small code bases, which is why I tend to fall back to "what is the domain" rather than "how will we implement the domain". In reality, no, I'm not going to have separate DBs for my separate domains representations of the same underlying object when the schema is 99% identical and I want synchronization 100% of the time. Concepts / EOS seem to get at similar core ideas and is a better book for a cross-functional team book club than DDDMF so I'm looking forward to that at the next job.
- I immediately started using the ideas in the book (though not formally modeling yet) to unravel a problem at work. I'm currently at Photon where we pretty much get prescriptions from the doctor to the pharmacy by putting the patient at the center. Our core data model (read, Concept) is currently "Order" which is a list of "Prescriptions" (A Prescription is a medication and dosage + how many times it can be refilled). An "Order" is overloaded as a concept, serving simultaneously as "a list of prescriptions written during the course of a single doctor visit", "a list of prescriptions a patient wants to pick up at once", and "a list of prescriptions we track as a unit". This immediately breaks down when there's an issue with one prescription in an order (for example, Drug A is out of stock but B is in stock). I've mostly been using DDD to think about the problem as "Write", "Place", "Track" but Concepts and EOS gives me other language and approaches that are more readily communicated to the designer and Product people.
Thanks to Peter W for the rec.
July 25, 2025
In today's software design, much focus hones in on users' experience with the interface. Teams make large efforts to make that experience as pleasing as possible so as not to drive away customers. However, they don't place as much emphasis on the conceptual nature of software - what concepts users extract from the software and what concepts the software requires for effective use. Since the advent of the GUI, today's software conveys intellectual matter that help users take up and use products effectively. These concepts are what Daniel Jackson, an eminent MIT professor, want to focus on. In this book, he describes how working on software concepts can translate into more effective products.
With its quasi-philosophical approach, this book treads new ground on how designers should think about their software. User-experience experts are now ubiquitous in industry, but Jackson's approach requires thought and philosophical mastery. He'll continue to challenge future designers to think over their designs better. He forces readers to think about software to a degree unmatched in my lifelong reading.
As a limitation, the book can become pedantic at times... as might be expected from an MIT professor. He tries to keep much of the scholarly back-and-forth to hundreds of pages of endnotes, but the book reads like a textbook, not an engaging conversational piece. Because his content takes a new perspective, I don't find this limitation anywhere near fatal, but software folks who like trendy books will find themselves disappointed. In contrast, scholars of software will find themselves excited.
This book will have lasting influence on the field of software design. Graduate school courses can easily use this book to spark discussions, and workplaces should have discussion groups to adapt its insights. Although appreciating its contents requires some degree of intellectual curiosity, anyone from frontline programmers, software architects, user-experiences experts, and philosophers of computing can benefit from this tour de force. It should continue to teach well in coming decades.
With its quasi-philosophical approach, this book treads new ground on how designers should think about their software. User-experience experts are now ubiquitous in industry, but Jackson's approach requires thought and philosophical mastery. He'll continue to challenge future designers to think over their designs better. He forces readers to think about software to a degree unmatched in my lifelong reading.
As a limitation, the book can become pedantic at times... as might be expected from an MIT professor. He tries to keep much of the scholarly back-and-forth to hundreds of pages of endnotes, but the book reads like a textbook, not an engaging conversational piece. Because his content takes a new perspective, I don't find this limitation anywhere near fatal, but software folks who like trendy books will find themselves disappointed. In contrast, scholars of software will find themselves excited.
This book will have lasting influence on the field of software design. Graduate school courses can easily use this book to spark discussions, and workplaces should have discussion groups to adapt its insights. Although appreciating its contents requires some degree of intellectual curiosity, anyone from frontline programmers, software architects, user-experiences experts, and philosophers of computing can benefit from this tour de force. It should continue to teach well in coming decades.
May 14, 2024
The essence of software lies in its ability to translate abstract concepts into tangible solutions. Great design hinges on understanding and applying fundamental principles like scalability, efficiency, and user experience. Concepts like these underpin methodologies like Scrum, which fosters iterative development and adaptability, ensuring software meets evolving needs seamlessly. For more insights on optimizing software development, check out https://attractgroup.com/blog/five-reasons-to-use-scrum/.
July 25, 2024
This is a short book where the author takes a look at a few common desktop applications and their designs. Beyond UI, and beyond software architecture, it tries to examine the mental model of the people who would use the applications. I think it does this well. At the same time, the book feels too narrow. If it discussed a broader range of applications and use-cases, including mobile and other form factors, I think it would've been a lot stronger.
September 16, 2024
The Essence of Software: Why Concepts Matter for Great Design is an essential read for anyone passionate about software development. The book dives into the core principles of design, emphasizing the importance of strong conceptual foundations. Whether you're a seasoned developer or just starting out, this book will change the way you think about software architecture and design, offering lessons for creating elegant, robust systems.
February 21, 2025
The essence of software design lies in a deep understanding of concepts that guide its development. A solid foundation in these principles fosters innovative, efficient, and scalable solutions. Concepts shape design choices, ensuring long-term functionality. For instance, if you're struggling with clear, structured work, consider Academized paper writing service at https://academized.com/term-paper-for-sale for support.
February 13, 2025
Really solid book on the importance of conceptual software design and how to do it well. Many of the (very thorough) examples are kinda just the author ranting about the flaws of certain software, but it's pretty entertaining and well-explained.
I think the examination of the Gmail labels will live in my brain rent-free forever.
I think the examination of the Gmail labels will live in my brain rent-free forever.
April 29, 2025
I'm curious to try this out, though I think most of the value will actually come from digging into the references the author cites.
May 8, 2024
Great!
Now I just have to figure out how to get us to work with concepts at work.
I did use the concept concept successfully for a programming language analysis https://tobega.blogspot.com/2024/01/u...
Now I just have to figure out how to get us to work with concepts at work.
I did use the concept concept successfully for a programming language analysis https://tobega.blogspot.com/2024/01/u...
Displaying 1 - 13 of 13 reviews