[joseph]

> Always talk about a second application. For each abstraction, the “app” is the layer above it. For example, a filesystem is an app for a block device; TCP is an app for IP. You should be able to describe the functionality of a layer without ever referring to the specifics of the app (e.g., you don’t need to know what a file is when talking about an SSD’s internals).

This is so true. It’s very common to see infrastructure being built in terms of the application that will run on it instead of designing the application to run on the infrastructure. A lot of brittle, unmodifiable messes are the result of this.

[paulryanrogers]

Part of the challenge is knowing how to slice the layers and when. Premature optimization is often crossing such layers too soon. Yet there are times when it becomes necessary for performance, such as Oracle bypassing FS to write to block devices or kernel patches for specialized networking cases.

[hamburglar]

I’ve had a lot of success building good abstractions with a version of this “second app” idea. The delta between designing for 1 app and designing for 2 apps is vast, but once you’ve designed for 2, you are generally very close to being able to support N apps. By the time you get to 3, you understand the problem domain very well and have a lot of confidence in your interfaces.