Technical debt (TD) – the compromises we make to get stuff out the door – is more often acknowledged and occasionally quantified. We categorize the inefficiency and difficulty working with it—the “interest” on the debt—as an unfortunate cost. Fixing technical debt (paying down the “principle”) competes for resources with new development and tangible defects

The common TD horror story is changing the behaviour of badly-coded modules¹. For example, spending hours adding a simple variation to an existing implementation, which has never worked consistently (and never been fully tested – let alone built for extension or reuse), is dangerous as well as frustrating. Without tests or clear documentation, we are never sure what good behaviour is, so extending that behaviour is often an exercise in faith²

In analyzing technical debt, we tend to mythologize it:

• Technical debt is something...

Decorators are a bit of meta-programming that allows one to add behaviour to functions and classes. The original function or class is wrapped in another function or class, and its name is pointed to that wrapper. Any use of that name will refer to the wrapper, not the original. This happens at “compile” time, not at runtime

The mechanics treat any function or class name prefixed by an “@”[^1] as a decorator and apply it to the following function, class, or method definition. The compiler takes the completed definition and passes it as an argument to the decorator, and the decorator returns a function or class, which the original token (name) points to

@a_decorator
class Foo(object):    "Foo" = a_decorator(class formerly-known-as Foo)
    ...

@a_decorator          "Bar" = a_decorator(function fka Bar)
def Bar:
    ...

rab = Bar()           rab is pointing to the result of

While optimization is often premature and, therefore, the root of all evil[^1], using an efficient design for data access is choosing a good path rather than paving a bad one. A common task for APIs is to retrieve a “page” of master rows and their detail rows (e.g. Invoice and Items), as well as a total count of the master rows that match the given criteria. Here are three ways to get the data from a standard SQL database:

Option 1: for each row of the master table query result, execute a query per detail table to get the detail rows for that master row (also known, derisively, as N+1)

Pro

• initiative design
• allows easy pagination of master rows

Con

• slow
• lots of little queries burden SQL server and network
• data might change during the process if the option does not include a potentially huge transaction (because the last query returns long after the first one)
  

Option 2: join

“… a landmark UCLA study showed that gestures count for a whopping 55% of the impact you have on an audience, while your tone of voice makes up 38%. Your words? A measly 7%” –Forbes

Words, then, are the minority player in presentations. Indeed, to help detect falsehood, one should ask for a written summary to remove the 93% of the demagoguery and hand-waving. Seven percent is not zero, however, and some audiences do pay attention to some of the words: the words that annoy them. If the words are also on visuals (like slides¹), they count for more than seven percent

The word impact as a verb (e.g. “This will impact sales”) makes me twitch. I prefer the verb affect, and I accept that this is a lonely preference. Likewise, performant, value proposition, upskilling, etc., will break my undivided attention

Important, perhaps, to an engineering or scientific audience: theory vs. hypothesi...