I’ve already written about the importance of getting to the red bar and the value of a failing test but once we get the red bar we want to move on and get to the green bar as soon as possible. In fact, turning the red bar green, which is really what TDD is all about, is a mad dash for me. Just like getting to third base with the ball in the outfield, I want to get to the red bar and move on as quickly as possible for the home run.
Getting to the green bar indulges me in one of my few guilty pleasures. Those of you who know me know that I am big on code quality and it is the foundation of almost everything I teach in my classes.
I believe that almost every problem has an elegant solution lurking within and all we have to do is find it. But to turn this lead into gold we must be very careful not to cloud the problem with poor code quality and notice when we get off track by cleaning code smells as we go.
So it may come as a shock to some of you who know me well when I say all that gets thrown out the window when I am turning the red bar green; code qualities, principles, practices, conventional wisdom, etc. are abandoned in my race to the bar green. Why? Because while I love to get to the red bar I hate staying there; it depresses me.
Really, my focus at this point is to get something working and the part of my brain that creates a proof of concept is different than the part of my brain that creates maintainable code.
Turing the red bar green is all about figuring out the right implementation. This is the most creative phase of software development to me and like a mad scientist who throw around elements and formulas until he gets what he want, I experiment but I also make a mess. Once my code behaves the way I want it to I step back and distill out the key parts but I’m grasping at straws until I’ve figured out first how it should behave.