blog

image of buttons and workflow

Friday Linked List: July 8, 2016

by

I used to do this more frequently than I have been — here are some posts and articles that have occupied open tabs in my browser for much of this week:

Two Views of Technical Debt

Earlier this week, we had an interesting discussion in one of our internal discussion forums on this Medium piece from 2014 talking about the difference between Technical Debt and just writing bad code:

In software development, the dreadful consequences of sacrificing quality are widely misunderstood by non technical managers. They underestimate how detrimental it is to continued productivity and morale, and ultimately, to the overall strategy of the company.

Given non technical managers have no actual first-hand experience building software, to explain to them these consequences we have to rely only on analogies. And here is where our problems start.

This morning, a paper from Google came through my feeds that touches on an aspect of this that I hadn’t considered before — machine learning techniques are both advancing and being adopted at an astonishing rate, but those advances don’t come without cost:

Machine learning offers a fantastically powerful toolkit for building complex systems quickly. This paper argues that it is dangerous to think of these quick wins as coming for free. Using the framework of technical debt, we note that it is remarkably easy to incur massive ongoing maintenance costs at the system level when applying machine learning. The goal of this paper is highlight several machine learning specific risk factors and design patterns to be avoided or refactored where possible. These include boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, changes in the external world, and a variety of system-level anti-patterns.

Beyond the Twelve-Factor App

The idea of the 12-Factor App first defined by the folks at Heroku has gotten pretty wide traction in the last few years. O’Reilly has just released a free e-book ‘Beyond the Twelve-Factor App’ that outlines an updated and expanded 15-factor version (adding ‘API First’, ‘Telemetry’ and ‘Security’) to help everyone write better cloud-native applications.

In 2012, early cloud pioneer Heroku developed the Twelve-Factor App, a set of rules and guidelines for helping organizations build cloud native applications. It served as an excellent starting point, but as technology inevitably marched forward, some areas needed revisiting. To accommodate current best practices, this practical book expands on the original guidelines to help you build applications that not only function in the cloud but also thrive.

Author Kevin Hoffman takes you through each factor in detail, explaining why these guidelines are important and, in some cases, pointing out how and why today’s new approaches work better. You’ll learn exactly what a 12-factor app is, and discover how to evaluate your existing applications against the guidelines in this book.

Mental Models

Another piece from Medium, this one from Gabriel Weinberg, Founder & CEO of Duck Duck Go, contains an exhaustive list and discussion of mental models that he’s found useful:

A mental model is just a concept you can use to help try to explain things (e.g. Hanlon’s Razor — “never attribute to malice that which is adequately explained by carelessness.”). There are tens of thousands of mental models, and every discipline has their own set that you can learn through coursework, mentorship, or first-hand experience.

There is a much smaller set of concepts, however, that come up repeatedly in day-to-day decision making, problem solving, and truth seeking. As Munger says, “80 or 90 important models will carry about 90% of the freight in making you a worldly‑wise person.”

This post is my attempt to enumerate the mental models that are repeatedly useful to me. This set is clearly biased from my own experience and surely incomplete. I hope to continue to revise it as I remember and learn more.

I have this one saved to Pinboard so I can come back to it later.

+ more

Accurate Timing

Accurate Timing

In many tasks we need to do something at given intervals of time. The most obvious ways may not give you the best results. Time? Meh. The most basic tasks that don't have what you might call CPU-scale time requirements can be handled with the usual language and...

read more