Many years ago, I came in one morning to a client, to discover the website down and the email server completely unresponsive. Naturally, we assumed that we we’d been hacked. What else could take down two unrelated systems at the same time?
This week I heard “A developers job is to write great software” and I disagree. A developers job is to solve problems for their clients. We have a tendency to get so focused on specific skillsets like “I write code” that we miss the entire point of why we’re doing it.
I was recently talking to someone who had an old codebase that they just couldn’t work with anymore. So they rewrote it from scratch and within six months, the new code was just as bad as the old. They were no further ahead, despite having invested a significant amount of time and money. This is a common story and it doesn’t have to be this way.
Spikes were an interesting idea that have become massively abused and it’s time that we just stop using them.
I was recently talking to a developer who had just been promoted to tech lead. They were asking what they should be doing differently now. I suggested the first things I’d focus on are that their job is now…
I was first introduced to the idea of splitting technical debt into two distinct parts during a conference talk given by Rebecca Wirfs-Brock. She talked about there being a real difference between simple cleanup such as renaming or adding clarity and architectural restructuring.
Ensemble programming (aka “Mob Programming” or “Software Teaming”) is a technique where the entire team works together on a single story at the same time, on the same computer. It takes pair programming to the next level by including everyone.
Surprisingly, there isn’t much agreement on what a defect is or how they should be addressed. This page explains our position on defects and how we feel they should be dealt with.
Most teams are a bunch of individual silos that have become good at passing work between each other. This exercise is designed to show how real collaboration is different from the way we normally work.
Demonstrates the problems that occur when we don’t integrate frequently enough.