Definitions of Ready and Done

I keep seeing heated discussions about Definition of Ready (DoR) and Definition of Done (DoD) in a Scrum team. People argue whether they’re part of Scrum and whether they’re necessary.

Code comprehension: Chunks and Beacons

We talk about making source code readable and it turns out that this isn’t just stylistic interpretation; there is actual research into this topic. As we read through the code, what we’re scanning for are chunks and beacons. Chunks and beacons are similar in that they’re both code fragments, yet they’re used differently.

Reinventing the wheel

I often find places where people have decided to re-implement some functionality that they could have just called from a library. Sometimes this is done because they honestly didn’t know the library call existed, and other times it’s because their pride insists that they could do it better.

Monkey Grassing

A common anti-pattern that I’ve seen is managers taking a highly effective team and scattering them across a larger number of teams in the hopes that they’ll take everything they know and make those new teams great. Then instead of having one great team, they’ll have many great teams.

Workplace stress and anxiety

A few days ago, I was sitting on my back deck working on the laptop. Out of the corner of my eye I saw some movement in front of me and I glanced up, expecting to see one of the many birds that are normally here. Instead I found myself staring at a young black bear that was walking across my lawn towards me.

The ugliest, nastiest, code

When teaching developers, I’ll often refer to “the ugliest, nastiest, part of your codebase that you’re all afraid to touch in case it breaks”. When I say that, everyone usually nods their heads. They know exactly what code I’m talking about because any long lived codebase has one. In fact they often even know who wrote that particular code, and its very common for that person to no longer be at the company.

Tracking metrics

Most companies I work with have a desire to track metrics for their development teams, and I support this. It’s hard to improve something we can’t see so metrics are a good first step as we seek to improve.

Why technical practices?

Most of the conversation about the agile technical practices tends to stay in the weeds. We talk about whether we should test before or after, whether we should be writing unit or acceptance tests, whether we should be mocking or not, whether PR’s are helpful or harmful. We have discussions back and forth about all of these topics and while they are good details, they sometimes obscure what’s really important.