I've been thinking about how applications evolve, and what we might do if we're unhappy with the results. Three apparently unrelated ideas have been percolating in my head. In this newsletter I'll introduce each one and connect them together, in hopes that understanding these connections will help us understand our apps.
I've been thinking about why we argue about code, and how we might transform vehement differences of opinion into active forces for good.
My thoughts spring from a very specific context. Ten or twelve times a year I go to an arbitrary business and spend three or more days teaching a course in object-oriented design. I'm an outsider, but for a few days these business let me in on their secrets.
Here's what I've noticed. In some places, folks are generally happy. Programmers get along. They feel as if they are all "in this together." At businesses like this I spend most of my time actually teaching object-oriented design.
Other places, folks are surprisingly miserable. ...
I've been thinking about the half-life of code.
In his Software that Fits in Your Head talk, Dan North defines the half-life of software as (I'm paraphrasing) "the amount of time required for half of an application's code to change so much that it becomes unrecognizable."
In that talk he tells the story of working on a high quality, non-trivial application whose code's half-life was six weeks.
Yup. Six. Weeks.