Software Launch: Adapt and integrate FTW Part 0.5

Last month, I introduced to you our project as well as some of the initial missteps in getting the technology side of things to run smoothly. Since then, I've actually learned--or come to appreciate--a very valuable lesson: TDD has its place. Now, I could have spoken even more broadly about how actions have consequences, but we won't be following that trail down to a very likely destination: a discussion around Abstract Reasoning... instead

let's focus on how TDD can really shine in a particular use case.

For many developers (ahem, "Software Engineers"), writing tests is, at best, an afterthought; and at worst, a tedious chore whose avoidance is somehow exempt from any inevitably bad consequence borne of the hubris of not writing any. So many take a pragmatic approach to this: write the code, then implement the tests. Simple enough--and sometimes quite literally the only option when inheriting a poorly covered codebase--right? Well not quite.

In many ways, employing TDD when working with contractors or any outside talent--or _anyone_, for that matter--that is not familiar with the codebase, is the *only* approach that makes business sense. Consider this scenario: you are responsible for an application and in order to implement some features on the roadmap in a timely fashion, you've decided to hire some contractors. The additional resources may or may not implement tests, but since they are unfamiliar with the code, the path of least resistance will always be to write the tests afterwards. And a path with even lesser resistance is one that doesn't include any tests. If you; however, enforce that tests should be written _before_ any features are implemented, you'll drastically reduce the overall time/effort invested in onboarding resources while suffering minimal regressions. There's also somewhat of an autocatalytic effect here - to write good tests, one must understand the application and its requirements; but in order to understand the application behavior, one will explore by writing tests. All this, of course, is predicated on the quality of said tests... We'll dive into that during a later installment in the Adapt and integrate FTW series.