Sign Up Today
☀️ 🌙

Arch-Engineer

Does your software have conceptual integrity?

Software Design Tip: Conceptual Integrity

If you're writing software that models the US Tax Code, there's only so much you can do to make it simple: the tax code and its commentary total 70,000 pages. But, as software developers, we often do get control over what we're building. So, to eliminate special cases in the code, we must try to eliminate special cases in the product.

It's a bit of a read, but I highly recommend Daniel Jackson's essay Towards a Conceptual Design for Software, or at least his slides. Software implements various concepts such as "posts" and "users" for a forum or social network, "labels" and "contacts" for an E-mail client, or "access policies" and "handlers" for a web server. To obtain usable systems and clean code, we should strive for a one-to-one correspondence between concepts and purposes. When there are two concepts for the same purpose, you get GMail's tags and categories, two competing ways of filtering E-mail that have left users confused. There's now also design pressure to make them usable in the same ways (e.g.: both usable in search), forcing us to write twice the code and creating "hidden coupling" between them, or to flout that and leave the user confused. One concept with two purposes isn't so great either, and leads to cases where implementing a "natural" feature will require quite tricky code, and its omission will confuse users, like in Daniel's Fuji x100s, which is missing options thanks to some unnecessary coupling between menu settings and JPEG headers.

Conceptual design diagram

You know what software violates these principles? Git. It makes you want to commit early and often so you can save your work, but you also want to wait to make a logically coherent commit. Branches let you work on features in parallel, but having uncommitted work blocks you from switching branches. Jackson and his student Santiago De Rosso argue that the concepts underlying Git are "operational misfits" to their purpose, which motivated them to create Gitless, a skin of Git that changes the concepts of branching and committing. It's simpler to explain, and I bet the implementation is simpler too.