In my time as an engineer I’ve had lots of conversations about software
dependencies. I’ve been meaning to put my thoughts in writing for a while
now—specifically about how I feel most teams, and in fact the industry at
large, don’t put enough thought into how they manage dependencies—but it’s
such a big topic that I’ve never found the energy to sit down and capture all
of my opinions in writing, as doing so would likely take up an entire book.
With that in mind, I gave myself 60 minutes to just write down everything
I could, and I used that as a first draft1. I’ve since made some
revisions, but what follows is still a bit rough. It’s best to think of it as
more a stream of consciousness than a buttoned-up treatise.
The biggest problem
Probably the biggest oversight that I see being made time and time again is
that developers don’t appreciate the huge role that trust plays in their
dependency strategy. We assume that the ecosystems we depend on are full of
good, competent actors who...
When we use the word “software” we’re really talking about two things. First
there’s the code, which is essentially a set of instructions, or routines.
But just as an instruction manual doesn’t magically accomplish a task, code by
itself doesn’t do anything. It needs to run in an environment: all of the
requisite pieces, both hardware (e.g. a PC or server) and software (e.g. an
operating system), that the code needs to work.
A deployment is when you take software that’s running in a particular
environment and you update its code.
One type of deployment is called a rolling deployment, where you update
slices of the environment (for example, groups of servers) in sequence, so that
until the deployment is over you have both old and new code running at the same
Rolling deployments tend to be good for reliability. They require no downtime,
since some of the environment is...
Suppose I said to you, “Go read War and Peace and write me a 10-page book
report on it.” What would you say? Probably something like Why? or Who do
you think you are? or maybe just No. That’s a homework assignment, and
there’s no reason I should be entitled to just give you a homework
Why isn’t it reasonable for me to give you a homework assignment? Because I’m
not your boss1. And in civilized society, we don’t abide
individuals just assigning arbitrarily large tasks to one another. It isn’t
Notice I said “arbitrarily large tasks”; we actually are okay with assigning
small tasks to each other. For example, almost no one thinks it would be
audacious of me to say, “Hey, could you hand me that stapler?” Even if I were
to blurt, “Give me that stapler!”—a significantly ruder way to say it—my
suspicion is that most people would still give me the stapler, albeit with a
bit of annoyance.
The team met up on Monday morning, as they always did to discuss the items in
“Let’s talk about Alice’s ticket,” said Bob, the product owner. “Alice, the
summary here says Configure auto-scaling. That sounds like a technical
solution. Remind me, what’s the actual business goal there?”
Alice fidgeted in her seat, as all engineers do under the light of a business
person’s attention. “Well, I guess it’s to make sure the system stays healthy
under production load,” she managed to say. “If we don’t have enough workers to
keep up with the queues, message processing could be delayed and eventually our
servers might run out of memory and crash.”
Bob thought for a moment. “All right, so it sounds like if we don’t set up
auto-scaling, we might not be able to handle peak traffic; is that right?”
Alice nodded. “Then let’s update the summary on this ticket to Prepare the
servers for peak traffic. I think that better captures the outcome we actually
care about without being too prescriptive...
I still remember the last time I got hopelessly inebriated. It wasn’t as long
ago as I’d like to admit. But it was a turning point for me, a wake-up call to
a grown man who shouldn’t be letting that happen. The details of the story
aren’t really important, except for one: it started with the all-too-familiar
mistake of drinking without having eaten dinner.
Anyone who’s made this mistake understands the ramifications. When your stomach
is empty, a little bit of alcohol has much more of an impact than after you’ve
had a full meal1. As a result it’s very easy to get drunk without
meaning to when you haven’t eaten recently.
The relationship between food and alcohol in the context I’m describing is one
of proportionality. Ideally a small amount of alcohol is preceded by a
much larger amount of food. The alcohol provides a pleasant buzz, while the
food acts as a buffer, protecting against some of the negative effects of the
I have noticed that a similar relationship exists between...
There’s an analogy I’ve used many times to describe Bitbucket, both to my team
as well as to outsiders. It works for Bitbucket but I think it works for plenty
of other software projects I’ve worked on, and even for everyday life. Anyway,
the analogy is this: Bitbucket is like a house with many rooms and only a small
staff to maintain it. Some of the rooms are neat and tidy; but given the
limited size of the staff, many of the rooms are a total mess.
When you first join the staff that maintains this house, you don’t have much
context. You may have seen the house before. Maybe you’ve even been inside it
for a social event, in which case you’ve probably seen the dining room, the
living room, perhaps a bar area or a study. But you haven’t seen the attic, the
cellar, many of the storage closets, etc.
So in your first few weeks, you find yourself discovering some of these rooms
you’ve never seen before, and they’re messy and in poor condition...
I realized something recently: I share my ideas with people every day in 1-1
conversations; but the rate at which I share my thoughts in written form is
much slower. Probably 100x slower. That’s not an exaggeration: in the past few
years my rate of publishing posts on this blog is less than 2 per year.
Meanwhile I have multiple conversations, both at work and outside of work, every
You’ve probably heard the expression “The perfect is the enemy of the good.” A
big part of the reason for the discrepancy between the value I provide in 1-1
interactions1 vs. written communication is the amount of
scrutiny I apply to the things I write versus the things I say. Meanwhile, the
value of the information I share in written form is nowhere near 100x as
I suspect the phenomenon of diminishing returns kicks in very quickly for me
with written communication. Most of the value is captured in the first 50% of
time invested; the remaining 50% of time invested only improves the final result...
One of my friends from Philadelphia1 once told me about a time
he went on a trip—I think it was a bachelor party or something—with
mostly guys he didn’t know. Most members of the group were from the midwest or
maybe the south2. At first everything was fine, but as the
trip went on, he started to feel uneasy. Eventually he realized that it was
making him uncomfortable how nice everyone was being to each other.
For my friend and his regular social group, normal behavior was just constantly
tearing each other to pieces. They would make fun of each other, mocking just
about everything anyone said or did that was remotely genuine, at every
opportunity. I’m sure this sounds unpleasant to most people, but for my friend
and his group it’s what put everybody at ease. No one was exempt, which meant
that no one was singled out.
This is why my friend wasn’t comfortable in this new group of polite
strangers. He was suspicious of their kindness and kept bracing for the
sarcasm. He had trouble letting...
There is a lesson I learned in Sunday school that has stuck with me to this day. I recently became aware of the fact that I idly, almost subconsciously think about this lesson on a regular basis; and I’ve even started referencing it in conversations with colleagues. The basic idea is very simple, but it provides a useful metaphor that can help frame conversations around project management and prioritization.
My teacher brought a big canister into the classroom along with two boxes of rocks. One of the boxes was full of large rocks, about the size of a fist. The other was filled with small pebbles.
“I want to fit all of these rocks into the jar,” he said. “Let’s see what happens if I put the small rocks in first.” The teacher poured the pebbles into the canister, filling it about halfway. He then started placing the larger rocks into the canister, but only a few of them fit before there was no more room.
“Hmm, that didn’t work,” he observed. “Maybe if we put the big rocks in first...
I’m writing this for a couple of reasons. For starters, I don’t think I talk about this often enough with my own team. We are typically so focused on our day-to-day work that it can be all too easy to lose sight of just what a special opportunity we all have.
More generally: maybe it’s just me, but it seems there’s a lot of negativity in the software world. For some reason many in our profession actually seem to hate what they do, which is hard for me to relate to. I’d like to see more articles by people who love their jobs, especially those of us lucky enough to work at great companies, on terrific products, with incredible teams.
So basically this is me making a conscious effort to put some positivity out there, in a space where I feel a lot more positivity is warranted.
A brief history
Working at ThoughtWorks as a consultant, I was privileged with a relentless string of learning opportunities from working at different clients, following different processes, and playing with different...