The Software Muscle

If you apply small, but relatively frequent stress to a muscle, then over time it will adapt and grow stronger. We don’t frequently talk about it in the context of software development, but I believe it holds here too. By frequently applying small amounts of stress to our software and processes, we can greatly improve them over time.

If you look at the practices that exist today, you’ll find plenty that follow this principle. When doing continuous deployment, we deploy automatically on a frequent basis, often even on every commit to master. Each deployment applies a little bit of stress. And sometimes… things will break! But that danger is what helps us make our process more resilient. Would you rather deploy a huge change once a year, with the risk of a massive downtime that's hard to recover from? Or, do you deploy small changes, many times per day, with each potential issue helping you learn more about your deployment process? I know which one I prefer.

Of course, at first, switching to this flow can be pretty scary, and probably for a good reason. There are many things that can go wrong if you aren’t used to deploying that frequently. If you only workout once a year, you may get hurt if you’re careless. However, once you commit to moving towards more frequent deploys, you’ll learn to tackle these issues one by one. Note that you don’t have to deploy on every commit from day one, you could just deploy once per workday or per week initially. And, of course, depending on your context, there might be constraints which prevent you from reaching the “deploy-every-commit” state, but the principle still holds and it’s still valuable to deploy as frequently as you can afford.

I see another application of the principle of “software as a muscle” in services that automatically update your dependencies, like Dependabot or Depfu. These services watch your dependencies for new releases and then automatically make a pull request with an attached changelog. As a result, we end up with frequent and smaller dependency updates, instead of the semi-regular “Let’s update all the libraries and see what breaks”. Again, there are more frequent smaller stresses, and something may break occasionally, but this helps us improve over time. Our software stays up-to-date and will be more enjoyable to work with, given the more up-to-date dependencies.

Similarly, I see the idea at play in the Chaos Monkey tool built by Netflix. Quoting their README file:

Chaos Monkey randomly terminates virtual machine instances and containers that run inside of your production environment. Exposing engineers to failures more frequently incentivizes them to build resilient services.

Finally, I believe it’s also one of the principles that makes Test-Driven Development valuable. By adding tests to our code, we apply a bit of stress to it, which verifies that the code behaves as we expect it to. When we apply changes to the code in the future, those tests again will verify whether we are not breaking anything.

If you see any other places in software were this applies, please let me know! I’d love to hear from you.

Why aren't you doing one-on-ones?

It's hard for me to express how much I value one-on-ones, but I'll give it a go. It would be the last meeting I scratched if I were asked to remove all but one. I've even left a company once with the lack of one-on-ones, and their reluctance to implement them, being the primary reason. In my opinion, it was leading to numerous recurring, yet preventable, problems. A process-oriented meeting like the one-on-one would have been perfect for solving that.

So if they are truly so valuable, then why don’t more companies or managers do them? The excuse usually goes something like this: "One-on-ones take a lot of time, so we don't do them on a regular basis, but my door is always open."

"One-on-ones take a lot of time"

They do take up quite a bit of time, but it’s well-invested time that provides a long-lasting return on investment. Knowledge work is about both efficiency and effectiveness. A one-on-one of just 60 minutes can improve both that efficiency and effectiveness of a team member for the coming weeks. From that perspective, it's one of the most high-output meetings you can have.

One goal of the meeting is to address any existing or potential problems, which I’ll discuss a bit more below. Another is that to provide an opportunity for coaching. During the meeting, direct reports can get feedback on their performance, which will help them grow and reach their potential. Likewise, the manager can collect feedback on the processes, new ideas, their own performance, etc.

"My door is always open"

One-on-ones are intended to lower the barrier to discussing problems. You want issues to reach you early, so they can be addressed at a low-value stage and don't get a chance to grow into big monster catastrophes.

By saying "my door is always open," you are attaining the exact opposite goal. Now, people will have to convince themselves that the problem is big enough to be discussed first. Usually, this will prevent them from talking to their manager, even though their feedback was probably valuable. On top of that, whenever they do see someone talking to a manager one-on-one, they'll think that something is wrong. They'll also assume that their colleagues will find it suspicious if they are talking one-on-one with their manager and now have yet another reason to not talk. Compare that with, for example, a bi-weekly one-on-one. Now, there's a regular process for discussing any potential problems and there's no suspicion from others.

If done well, the one-on-one creates a safe environment where problems get tackled quickly. In good companies and teams, problems surface quickly so they can also be solved faster.

Short iterations

Sometimes it’s easy to forgot the value behind short iterations, so let’s discuss why they’re important.

While it’s sometimes true that splitting a big change into smaller pieces can be hard, it’s still worth it. Whenever you’re going through a long iteration, you aren’t getting feedback. You’re working in a bubble, and you might be running headfirst into a wall.

Short iterations are important because the iteration is your feedback loop. Once you finish an iteration you can get feedback on it. Getting it quickly is important, because it allows you to adjust at a lower value stage. Changing direction early is always easier than later.

The feedback comes from multiple sources by the way. You can get feedback from your colleagues, from tests, from seeing an idea work in production, from users or many other ways. Some issues and improvements are hard to predict, and feedback helps surface those quicker. That’s why short iterations are important. Feedback and adjusting based on that feedback is the goal.

This post was originally published on Medium on Nov 26, 2015.

Crucial Conversations

A couple of months ago I read the book Crucial Conversations and started applying its concepts. The premise of the book is that we are bad at conversations where opinions vary, emotions run strong and the stakes are high.

We’re bad as these kind of conversations because our brains have evolved a fight-or-flight response. This means we usually move to silence or violence when we feel unsafe. Which means dialogue stops. Which means our shared pool of meaning stays small. Which means we get suboptimal results. Individually smart people can do collectively stupid things when they communicate badly.

Crucial Conversations teaches you how to notice when you or others are gravitating towards silence or violence, and how to step out of the conversation to make it safe again. How to state controversial opinions in a way that gets heard, and how to explore the opinions and ideas of others, so everyone gets heard. And finally, how to turn those crucial conversations into action and results.

For me one of the most useful lesson was learning to bring up controversial or difficult issues faster, while encouraging others do to the same. Thus also finding solutions faster.

The other is the contrasting technique which helps you clarify what you mean by first saying what you don’t want. This one’s especially important in today’s world of online communication and remote work, where misunderstandings happen frequently.

This post was originally published on Medium on Oct 23, 2015.