Is software development an art or a science?
Is software development a craft to be mastered?
Is software development a repeatable process?
Depending on who you talk to, the answers are both, yes, and no (respectively).
When we build houses, there are very clear engineering codes that define how the house is to be built. Minimum safety tolerances, and specifications abound (fun fact, a “shed” is referred to as an accessory structure in my local county’s building code).
But, we don’t have that for software. We don’t have a corpus we can turn to that says, If you’re building a web application that handles PDFs, it must have specifications X, Y, and Z, and be for an user-base size of 0-50 be rated for 200 operations per second).
When we’re building houses, there is a logical order to how it’s built. Survey, excavation, foundation pouring, foundation inspection, materials specification, frame built, roof trusses are pre-made and delivered on site; roof trusses installed; exterior sheathing installed framing and roof inspection, and the list goes on.
With software, we can start pretty much anywhere (and do). We can start with the user interface; we can start with the lowest system component; we can start with the database; we can start with the application layer and abstract out the database, anything.
But what if we had a series of steps we used? Repeatable steps?
What advantages would that give us? What disadvantages would we incur?
We already know the status quo; and software teams are much more likely to not create a specification than they are to create it; as a specification takes time, energy, and project-based businesses don’t want to spend the money on non-deliverables.
But what if we could eat our cake and have it too? What if we could provide a measure of stable, repeatable steps to building software, know the constraints and edge cases as we’re building it, and still move nimbly?
Is it possible?
Of course it is. That’s what Test Driven Development provides. But, and this is crucial, it takes a lot more than the three rules of TDD to build software in a repeatable fashion and cadence.
There are architectural patterns to learn, development processes to hone, repeatable checks through Continuous integration, and individual practices down to the method level to learn and master. Outside/In TDD and Inside/Out TDD teach different methods; but those break in various ways at various sizes. I’m partial to the FauxO style of TDD; which is more resilient to larger codebases; and provides value without brittleness.
But the question you have to answer for yourself and your team: Do you want software creation to be a repeatable process with predictable results?
For some teams that answer is yes. These teams are generally project-based teams that have a defined end-date and budget. They have to be repeatable because the team finds itself moving from project to project. For other teams (product-based teams) the answer can be no; the team continually develops the software over the course of years, and TDD can help there too; but the practices are more difficult to retrofit on an existing system not built with tests; and often have a much higher cost (and are harder to get buy-in for).
P.S. If the answer for you and your team is “yes” then you’ll get value from signing up for my forthcoming course on Test Driven Development for .NET Project Teams. By signing up, you’ll receive pre-release material, as well as a special launch-day discount that won’t be available anywhere else.