Josh Kerievsky called me to task for not following up on his third version of his story of providing a quick fix before a test-driven fix. As I said, I don’t want to be critical of Josh. I will, however, cast a critical eye on the code he has shared.
For those just tuning in, the previous installment talked about differences between the culture we espouse and the culture we practice. This installment will return to that.
Read MoreUsed with care, software development estimates can help you manage project risks. They let you peer into the future, though only as well as your current understanding allows. Estimating based on what you know is easy. Estimating based on what you know you don’t know is possible. Allowing for what you don’t know you don’t know is prudent.
Managing risk is a dynamic process. I’ve seen people document a risk in a “Risk Register” document and promptly ignore it. That’s not management. Instead, consider different ways a risk might be reduced in likelihood or consequence. When time or cost is of the essence, think about how you’ll determine what you can afford, and when you need to take a second-choice approach. Read More
A common complaint against Test Driven Development is that writing tests and refactoring take too long. In the long run, I’ve found that TDD has improved my skills such that I can complete work faster by writing tests and refactoring than without. I’ve also found that this information is a weak argument for those who have less confidence in their skills, or feel too pressed for time to learn. But that’s not the only benefit. Read More
Grabbing a handful of wet, saturated sand, I let it dribble through my finger tips. I watch each drop pile on top of the previous, draining away the water and leaving a new building block of solid sand. Too much water and the previous drip will be washed away. Too little and the sand cracks and refuses to hold together. I watch the sand grow, getting into a rhythm that ensures just the right amount of water, without thought.
My thoughts are not on the mechanics of building a drip castle with sand. Instead, I’m thinking of the spire that I’m building. Can I build these two spires toward each other and form an arch? Can I make this slender spire taller?
Frequently I fail and a part of the castle slides down, becoming part of the landscape again. Or becoming a foundation for a new part of the castle. No matter. It’s the building of the castle that brings me joy–not the owning of it. For I will never own it. The sea soon comes and takes it away.
Last weekend, I drove six hours down to Floyd, Virginia for a Code Retreat organized by Gustin Prudner and led by Corey Haines. There, I joined thirty-some people working in pairs and threes on Conway’s Game of Life for forty-five minutes at a time. Then, Corey would call time, and we would wash away all traces of what we’d built.
Does that sound like a waste of time?
Some of you may remember that I started a house construction project. Things are moving very fast, now, and the actual construction may take less time than it took to get all the necessary permits. So far, the project’s about 100% over the time budget. And people say that software development should be more like the construction industry!
But the fact that the construction has run slower than expected is not the reason for this post. Neither is the fact that this project has been consuming a large portion of my attention, and hindering posts on this blog.
This post is about an example of refactoring found in the house construction domain. Read More