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.

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.

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.

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.

Branching is a great workaround for problems elsewhere in the system that we are unable or unwilling to fix.

One of the key things we’re trying to get with Agile is faster and more effective feedback so that we can make better decisions. This extends into to the technical practices just as much as it does in our meetings and processes.

My comments yesterday on social media about encouraging the hiring of juniors seemed to resonate. So let me tell you about two of the very best teams I’ve worked with. Two teams of juniors, that were freshly hired, many straight out of school and none of them having worked professionally for long.

I found myself quoting Deming in a question about Pull Requests (PR’s) today.

We often hear things like “we’ve set up CI”, which makes no actual sense when you consider what CI is. It’s not a server or a tool, Continuous Integration (CI) is an ongoing practice whereby we keep the code continuously integrated. That sounds simple but has more subtlety than you might expect. Many places today that think they’re doing CI, actually aren’t, and as a result aren’t getting the benefit they could.

Most companies have too many active branches in their code repositories. “Active” meaning we’re doing actual development on them.