All of this content used to be spread over three different blogs at three different domains and it's now been merged into one. Why was it ever three? Because at the time it seemed reasonable that each of them was for a different audiences, and yet over time I've found that the lines between topic areas got blurrier and tended to overlap. So now they're all together in one place.

If you encounter things that seem broken, please let me know and I'll get them fixed.

Browse by topic area:

There's a lot here and if you're not sure where to start, here are some popular starting points. From these, you'll find crosslinks to even more topics. Enjoy!

YAGNI (You Aren’t Going to Need It)

YAGNI (You Aren’t Going to Need It) is a principle that keeps us from over-engineering the system. Build today only those things that you need today. Things that we need tomorrow, we can build tomorrow.

Hot-fixes

It used to be common that we would have two different ways to deploy something to a production environment.

Perceptual positions & Halloween

I had a client once that went all out for Halloween. Just about everyone showed up in costumes and there were prizes for individual or team costumes. At the time I was there, it was commonplace for work to be outsourced to India so my group decided to do a team costume of “IT outsourced to Mars”.

Hybrid teams

For decades before covid, were were already using a hybrid model. We’d outsource part of our development teams to other countries, like India. We’d then have part of our teams collocated in our offices and some people calling in from that other country.

Mocking frameworks

I’ve recently noticed a number of posts criticizing mocking frameworks, where half the responses are defending the idea of mocking rather than talking about the frameworks that had been called out1. Let’s be clear that those are two completely different things.

  1. This is an example of a psychological phenonomenon called Attribute Substitution where we are faced with a computationally difficult decision, we will often substitute a more easily calculated decision in it’s place and answer that instead, without even realizing that we did this. ↩

Audit

We commonly hear things along the lines of “that’s required for audit purposes” and it’s therefore not to be questioned. If it really is needed for audit then we should certainly do it. Yet, every time I’ve had the opportunity to talk to an auditor, I discover that they don’t want most of the things that we give them.

Fractional people

I worked with two teams that shared a database specialist, for a fairly proprietary system. Because she was on two teams, they had her attend all meetings for both teams. Two standups, two planning meetings, two retrospectives. She ended up doing crazy amounts of overtime because she couldn’t get her regular work done during the day. Her days were filled with meetings, and it was only after everyone else left that she got anything done.

Optimizing for time overlap

If we want people to actively collaborate then they have to be working at the same time. It’s irrelevant whether they’re in the same physical room if they don’t work the same hours. If one person comes in early and another comes in late then there is no benefit in forcing them into the same place.

“Everything that’s old is new again”

When we look at the agile technical practices, there’s a tendency to believe that these things are new and unproven and nothing could be further from the truth.

Should remote workers have cameras on?

For remote workers, the issue of cameras on or off keeps coming up. There’s no question that having cameras on allows for much richer interactions. We can start to interpret body language and can pick up on so many subtle hints that just aren’t possible when the cameras are off.