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.

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

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 out¹. Let’s be clear that those are two completely different things.

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.

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.

One of the first times I’d seriously paired with a tester on code, we were working on some date/time logic.

For many people, the notion of Zero Bugs seems like an unsustainable dream and yet the teams that do it are tremendously successful.

In the early days of Java, I recall reading a book talking about performance characteristics of various things in Java. One of the tidbits that I latched onto was the suggestion that the default size of a Hashtable object was inefficient if it had to grow in size beyond the default.

Almost every automated test framework has the ability to run the tests in random order and some even do it that way by default. If you aren’t already running your tests in random order then start now. You’ll be amazed at what problems this will uncover.

A common push-back to pairing or ensemble/mobbing work is that not everyone can contribute and therefore it would be a waste to have them there. “We’re building an iPhone app and our backend people can’t help”.