Rys Sommefeldt

Surface area

A recurring theme in life for me, especially where it concerns computing and computer systems, is that of surface area, and more often than not the reduction of it.

Present any interface in a computer system to the outside world and you have a defined surface area for external entities to communicate with. That surface area could be the public API in some library code, the ports you listen on in a network, the authentication methods in your security system; you get the idea.

In programming, it also applies to the amount of code itself, with that being the program’s surface area exposed to you.

In almost all cases, you want to work to minimise that area as much as possible at all reasonable costs, without introducing extra surface area in the form of complexity. For example: if a testable function can be 10 lines of code instead of 20 while still passing the tests, and you don’t make it harder to understand, you should do so.

If one of the functions in your public API never gets called, remove it. In any language with the concept of passing by reference or passing by value, passing by value should almost always be preferred since it reduces the surface area of impurity.

Where it concerns data, you should always only provide the minimum required for the receiving system to function properly. In the social network case, minimising the surface area of data you give to it helps protect your privacy and reduces your ability to be advertised to.

It’s often common sense, but in computer systems it’s all too easy to design in or allow accidental complexity and increase the system’s surface area. Automatic addition of accessors and mutators to an object increase the surface area of the object’s interface to calling code unnecessarily. Access to data should be governed, not accidental.

Convenient functionality for programmers should be welcomed, but you should also clean up after using it too. If your framework generates boilerplate, remove the bits of boilerplate you don’t eventually make use of.

Deprecate old APIs quickly and ruthlessly. Don’t allow legacy interfaces to hang around “just in case”. Your job as a programmer is to reduce the amount of code required for a system to function correctly, not increase it.

When designing security systems, reduction in surface area is key to reducing the chances of compromise. For example, if you’re using SSL and you completely control the clients, turn off or compile out unnecessary protocols and ciphers.

In short, always be mindful of the surface area of any system you’re responsible for and always research and understand how you can minimise it.