Thoughts on abstractions

Author's image
Tamás Sallai
1 min
Photo by Aaron Burden on Unsplash

The choice of abstractions have a huge impact on productivity and whether working with a system feels frustrating or not.

Imagine a system where you can track the position of a car fleet. What is the good level of abstraction here? You can say that since all you're tracking are cars, they can have licence plate numbers, registration numbers, and one person who is driving them. Is that a good abstraction?

Alternatively, you can say that you track "things" and they can be anything: animals, packages, trucks, people. In this case, your abstraction can't include things like license plate numbers, as an animal does not have one.

The first choice makes it easy to deal with cars: the high-level contains all the information relevant for cars. The data model, the APIs are all close to how people talk. But when you need to start tracking packages? This is when hacks like "license plate is the package number if the type of object is package" comes from. And then everything becomes way harder.

Going with the more generalized approach? It handles these different cases well, but what if 90% of the clients are actually tracking cars? You just make them go through hoops unnecessarily as your API and data model does not match their business requirements. There is no license plate field that guarantees that this data is always present so they have to deal with potentially missing data that is actually not missing in their case.

Choosing the right abstraction is part of the long-term planning and have an outsized effect on the developer UX. This is one of "work multipliers" where if you save some time in the beginning you'll need to work a lot more later. So it's a good investment coming up with the right level.

March 3, 2025

Free PDF guide

Sign up to our newsletter and download the "Foreign key constraints in DynamoDB" guide.