Thoughts on Infrastructructure, Technical Debt, and Automated Test Framework

1. for the automation. But automation is a project. You should have a vision and release criteria. You should adapt to change in that project, just like any other project.
2. As you work on a story, whomever you are , you help out wherever you are. If you are, by nature, a code developer, you start with the code. Here’s a story to illustrate what I mean:

You happen to be Platform Paul and you do some development, some refactoring, maybe some rearchitecture, some unit test development, whatever it takes to make your code work and checked in. Fine, you are done.

You check with Tina the tester. She is having trouble with the system tests. You do not abandon her, saying, “My part is done.” Oh, no no no no you don’t.

You say, “Hey, Tina, what’s going on? What can I do?” She tells you. The two of you work on her automated test framework, refactoring it until it works for the new code you checked in and her tests. Once it works, and her tests work, now the two of you walk over to Willie Writer.

Willie glares at both of you and says, “I keep writing the online help, but you two kept refactoring all afternoon. I keep chasing you two and those guys!” as he pointed to the other two developers. The three of you laugh and then all three of you complete the online help in the next hour.

Willie and Tina and you do a little exploratory testing under Tina’s guidance, because what do you know about exploratory testing? She calls it “session-based testing.”

Now, the three of you check with the other two developers who have finished the GUI and the middleware, and only now do you move the story to done. Because the feature required a little platform work, more middleware, and a little GUI to be complete.

Product owners, if you don’t want to fund technical debt, you will create more of it. You will slow down the rate of creating features. I have example graphs of this in Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects .

You don’t have to have the perfect automated test framework, not at the beginning of a project. You don’t know what it is at the beginning of a project. You only know you need one. But you can write a little and refactor it. I wrote a column about that.

And, when it comes to creating technical debt, the one thing you must do is, stop. No matter what, you must not create more. And, if you wander into some code or tests that have technical debt, I do not see how you can be a professional and leave it there. At the very least, you can create a defect report that says, “We have technical debt here.” You know it’s going to bite you on the tush at the most inopportune time.

I am not a fan of “go rewrite the system to avoid technical debt.” But you and I both know that technical debt slows down system development and often slows down system performance. I want to avoid rewrites. I want to clean up as I go. If you clean up every single one or two-day feature, you don’t have to pay a huge price, ever.