The Pomodoro Technique

There is a special, lonely dread that accompanies a big, complex task. Am I up to it? Is it harder than I think? Am I missing something fundamental? I wonder what's going on on Twitter. Hey, I got retweeted...

A Scrum Reading List

On a recent project I played a pretty active, if informal, role as an agile coach, in addition to my development duties. Which meant I did a lot of reading on plane flights, watched a lot of Jeff Sutherland videos, and got to the point where I could quote the Scrum Guide in chapter and verse. I'm not a certified anything (well at least as far as Agile is concerned), but the material started to make sense to me in a fairly coherent way, so I thought it might be useful to assemble a list of resources that influenced my thinking, and what I learned from them.

In the Agile Trenches (Part 1)

I've been interested in test driven development for a number of years, and recently it has become central to how I do software development.

Rocking the SRP with ReSharper

The Single Responsibility Principle is a pain in the ass. You're trying to get something done, and don't have a lot of time, and you'd like to keep all the moving parts in front of you. So put it all in one class, or better, yet, one method.

A Day in the TDD Zone

What makes a great day of test driven development?

1. A good plan.  This is going in my business layer, that is going in my data layer, and I'm not going to think about it just yet.  Let's wrap it in an interface and set it aside for a bit.
2. Good tools.  NUnit of course, and a good mock suite.  Moq was rocking for me--built around lambda expressions, it makes dynamically created objects obey intellisense.  Pretty nifty.  And ReSharper is wonderful, letting you define methods and classes in your tests, and then Alt-Enter them into existence.  Control-U+Control-U to rerun your last test, and a nice 100% code coverage report for the class under test when your done.

Agile Estimation and Planning

I just finished Mike Cohn's Agile Estimating and Planning, a thorough and very readable treatment of how Agile works as a project planning methodology. Here are my takeaways:

Extreme Programming Dangers

While doing some online research on development methodologies, I came across a useful analysis of how Extreme Programming (XP) can break down in real life, because each component methodology (lack of fixed design, pair programming, constant refactoring) is too dependent on the others for success. An example:

Constant refactoring (i.e. constant tweaking and improving of your code) creates an unnecessary overhead. Outside the XP world, occasional refactoring is welcome, as it is useful to check and improve ('de-fluff') your design; but constant refactoring makes no sense. In fact it only makes sense in the XP world, where the design is made up as you go along.