Four A's and a Zed

A couple of years ago, in an attempt to combat myopia, I tried to collect some thoughts on a software system I had a hand in developing. I came up with a few principles that applied to that code, but there might be something more general in them that’s worth capturing. So with apologies to Hugh Grant, here are Four A’s and a Zed.

Availability is Scalability

An important lesson learned is never try to bolt on fault tolerance or fault resiliency at the end. One has to design it in from the beginning. The twin of this idea is that scalability isn’t accidental either. By scalability, I mean the capability of the architecture to improve some figure of merit (throughput, for example) by throwing more hardware at it.

All right, those points are obvious. But what wasn’t obvious (and what might not even be true generally) is the idea that availability and scalability are the same thing.

Architecture By Contract

ABC is a term I made up to denote an amalgam of Design By Contract (DBC) and Interface Oriented Programming (IOP).

Adaptors for Protocols, Plug-ins for Logic

Our product had to integrate into a number of environments. One mistake we made was to mix business logic into the same code that was handling the communication. A better approach would have been to create adaptors that only handled the protocols, and contained no biz logic. Instead, separate plug-ins would contain customizable logic that could be varied independently.

Asynchronicity Considered Harmful

Event-driven systems can allow design decisions to be deferred. Usually, it's better not to defer such decisions, but make the hard choices up front.

Zero Bugs in Zero Slocs

Code that you don't have to write can't have bugs in it. Our prowess at the keyboard should not be measured by how many lines of code we write, but how few.