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.

Fixation errors

Back in the 1990’s, it wasn’t uncommon for people to check code into the repository that didn’t work. Sometimes it wouldn’t even compile.

Learning to say no

A team I was coaching was coming up on an important deadline. Specific functionality had been promised for a certain date that was now eight weeks away, and they wanted to know if they were going to make it.

All we are is change

We often hear that people are “resistant to change”, and yet as a friend of mine is fond of saying “all we are is change”.

Ability to deliver quickly

I was talking to a team that maintained a year-end batch process. Their code only ran once a year, on the first day of the new fiscal year.