YAGNI (You Aren’t Going to Need It)

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.

Hot-fixes

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

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. 

“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.

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.

Zero Bugs (Defects)

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

Premature optimization

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.

Tip: Run tests in random order

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.

Underutilized skills and talent

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”.