At the Coalface

Hacker News had a great post recently about whether startups have enough time for TDD/BDD. More here.

Caveat emptor: I haven’t worked in a startup, but have spent most of my career incubating nascent ideas in a startup fashion within a small growth company. My observations:

• Any emerging solution that’s finding product/market fit within an established company goes through a cycle of preparation, learning, and optimization
• In the preparation phase, you have a general idea of what you want to do, but no actual users, and you are possibly tempted to worry about standard metrics such as code coverage. This is a sign of a team experienced in maintaining and releasing code, but one not familiar with facing a market Within a company, you have the buffer of longer product cycles, competition for budget, establishing viability.
• As the team gets closer to having something to market, the techniques that pay off greatly in a stable operation fall by the wayside as factors related to responsiveness and true agility come to the forefront. No one looks at code coverage reports any longer; they’re focused on the client/user/customer needs (as they should be). This is a good thing. They are at the coal face of maximizing learning and establishing product/market fit.
• At the product reaches a certain level of maturity, the benefits of TDD and BDD start to become apparent again; we’ve now reached a steady-state and the pace of change (and the rate of learning) has decreased. The traditional values around code maintenance are now prized, and we’ve presumably established viability and a sense of what parts of the code we’ll be living with for some time.

Therefore I believe that in the context of a true startup, or for a project that’s acting as a startup within the context of a larger, more stable company, that the value of TDD/BDD is inversely correlated with the rate of learning about the market’s needs; and in a startup, most of the time spent away from the coalface of learning the market’s needs is a net negative.

That said, even in this startup mode, there are certain fundamental pieces of infrastructure which you know will be preserved regardless of market feedback. These are worthy of TDD attention. The trick is to know what is core, fundamental keeper code, and what is going to be tossed out many times over. In my experience, data models, data access and core services last forever; business logic, workflow and especially UI/UX tend to change dramatically as learning grows. Apply your TDD wisely.