In December's Stride Tech Talk, Debbie Madden, CEO of Stride, sits down with Rex Madden, CTO of Stride to discuss TDD best practice for Lean Startups.
Debbie: You’ve been an Agile advocate since literally day one in 2001. Are Agile engineering practices like TDD and refactoring ALWAYS best practice?
Rex: TDD and Refactoring are almost always best practices. But not 100% of the time. I’ll paraphrase Kent Beck from a recent Startup Success podcast “something that might be good engineering practice when taken in isolation might not be good startup practice.” This is important because in startups, you’re going out there with the mindset of looking to reject ideas (we did that with our Topic Editor screen in Ballpark. We quickly decided to redo the entire thing once we got feedback from initial users - I'm glad we didn’t spend too long TDD’ing and refactoring that original screen! Spending time on sustainability practices is effectively slowing down your Learn-Measure-Build cycle.
Debbie: You said Learn-Measure-Build. Isn’t it the reverse: Build-Measure-Learn?
Rex: Usually. But, if you aren’t sure that you have a product/market fit, your main goal is to learn, learn, learn. In these cases, when you’re launching an MVP, starting a new business, the cycle should be reversed: Learn-Measure-Build. This is another thought process I share with Kent Beck, who actually borrowed this idea from Eric Reis. Figure out what you want to learn first. Then figure out a measurable experiment where you can do to learn from. Then finally you build the smallest/cheapest thing you can to run that experiment. Prioritize activities that enhance learning. Deprioritize activities that slow down learning.
Back to our Ballpark screen, the first go-around we were more concerned about the Simulation engine and whether people got the concept at all. We weren't as worried about the Editor screen. So we threw something together with some basic CRUD pages, just enough so a user can edit things, albeit painfully. The feedback on the simulation concept was good. And not surprisingly, there were complaints about how hard the data-entry was, which is why we started over on that.
Debbie: So, how does an Agilist decide when to invest in TDD when the goal is rapid learning?
Rex: As a rule of thumb, if TDD helps you learn faster, than do it. For example, a calculation engine I built last week for an MVP has a fair amount of tests around it, because trying to build that without tests would actually be slower the first time around. Therefore, testing actually helped me get through the Learn-Measure-Build cycle faster.
Debbie: Ok, I’m convinced. But, how does one decide when they’ve learned enough that it’s time to move to more disciplined Agile engineering practices like TDD and refactoring for their MVP code?
Rex: You make a judgement based on your situation. For TDD and Agile Engineering, there comes a point where you decide that it’s worth building in more sustainability. Effectively, you’re saying “this is going to live for a while so I’d better shore it up. Otherwise, it’s going to slow me down."