Change is inevitable. It is a simple fact of life which permeates into just about everything. Software development is no exception. Many software development life cycles have evolved and others have come into existence in an effort to help us deal with change. Programming languages, tools and techniques are also continuously evolving as well. Yet with all these improvements many project teams continue to struggle with change.

What can we do about change? The truth is change doesn’t have to be hard. There are many things we can do such as plan for change, design for change, and code for change. Read the rest of this entry »

Okay, I admit it. Sometimes I write unit tests second instead of first. I also bite my nails and rest my elbows on the dinner table. But when I’ve got a bug to fix, and I’ve already found the offending line, I can hardly resist the urge to just… just… change it. I’ll follow up with unit tests afterwards, promise.

I admit this to you because admitting my wrongs is a step towards rehabilitation. I admit this to save you pain. Learn from my example. Test-second is so much less efficient than test-first. Consider the following workflow:

1. Reproduce, identify, debug the issue.
2. Fix the code.
3. Compile and try it out.
4. Write a test that proves I fixed it.
5. Compile and run the test.
6. Change the code back to make sure my test really proves what it is trying to prove.
7. Compile and see the test fail.
8. Re-fix the code.
9. Compile and see the test pass.

I humble myself before you. How much time am I wasting there? It’s embarrassing. Read the rest of this entry »