“A very common strategy I’ve seen in the programming world is thinking of certain desired high-level features, then directly codifying each one as a separate codepath. I call this strategy ‘top-down’ because it begins enforcing constraints on code by starting with high-level requirements. Such an approach would mean that, in the case of user interface rendering, each of the features I’ve mentioned—text, rectangles, rounded rectangles, rectangle borders, rounded rectangular borders, drop shadows, and icons—would all be implemented as distinct codepaths. Each feature is seen as a separate ‘case’ to handle, and the programmer in charge naïvely translates that into distinct cases in the code. “This has a number of possible drawbacks. The first is simply that you may write (and thus maintain) more code to implement each feature, when compared to an alternative world where you got all of the features you wanted out of a smaller number of codepaths. That might not sound too bad for a small number of features, but it is worse than you might first assume. Each ‘case’ is heterogeneous, and so there is a degree of variability that propagates elsewhere, and forces itself not only into the implementation of each case, but also other code that must interact with each case. Any codepath that wants to programmatically parameterize this rendering codepath now must scale itself with the number of cases. For these reasons, I consider each addition of a ‘case’ as a multiplication of code, rather than an addition of code.”