Discovering what brings value
There are only 2 kinds of code: the one that brings value to the customer, and the one that doesn’t. I’ll call the former domain code and the latter plumbing code. But what does this mean?
Domain code
In simple terms if it’s not in the business jargon, it’s not domain code. That is, all of the business concepts and the rules that dictate how they relate to each other, the services provided by the business to its clients, the actions taken on specific situations (procedures) are all part of the business domain and automating these (completely or partial) are the things that help the business to increment revenue, diminish costs, accelerate the procedures execution and take better decisions. Otherwise it doesn’t add value to the business.
Plumbing code
This is the kind of code that doesn’t directly add value to the business. Is mostly comprised of technical aspects such as the database, software architecture, reporting technology, technology stack, frameworks and so on. It is necessary for an information system to run, but it is not the reason why the system was created in the first place.
The “egg or chicken first” paradox
Common sense dictates that the things that are most important to the business are to be put first. That is that a development team should make sure that the business policies, rules and logic are correctly implemented in the code before anything else. The common practice however, is a different story. That is because the developer usually needs a minimum amount of plumbing code to test if a business rule is working as expected. Consider the case when a developer has to test a simple rule: you can’t get more money from a back account than available. To test this the developer may start creating a BankAccount table, then writing the code for the rule, then creating a test program to exercise that code. And then he would have to add code for transient fault handling in case the database connection fails. So writing the code that adds value (domain code) it’s just a tiny fraction from the whole operation. Most of the actions are about setting up the infrastructure. Even more, a lot of developers take this all the way up to creating an API or UI. This just makes harder to test the code related to the rule, since now there are several points where something may go wrong. So now in order to know if the rule is correctly implemented, the developer has to put an end to end application that may have to be modified in the event that the domain code needs to be rewritten. So which is first: domain or plumbing code?
Defining what’s to be done
TDD change the focus from the plumbing code back to the domain code. It makes this by forcing the developer to create functional specifications in the form of tests and then create code to fulfill the specification’s expectations.
On a typical development project, a lot of the initial analysis goes into the plumbing code: database, frameworks, operative systems, hardware and so on. On the other hand, the business idea of what the system is supposed to do is subject to evolve as the developers and the business discover the requirements and needs. Unfortunately, a lot of time the developers don’t dig into it until later on, when all the technology stack has been decided. This creates a situation where the domain code is now restricted by the technology stack limitations.
TDD reverses this situation. By having the developers to create the specifications first, they find themselves in the need to understand better what’s the expected outcome for a piece of software. Taking back our previous example, what’s supposed to happen when the bank account has not enough money to fulfill a withdraw operation? An exception? Returns a message? Should that be a string or a structure of sorts? Or a function (closure)? Should these be logged? Should the account owner be instructed to go through some sort of procedure (like a loan)? To answer these questions, the developer has to understand what does the business expect to happen. This will lead him to go back to the business and make questions until he understands enough to continue. This process usually happens on any development project, especially if they’re following an agile methodology, but the use of TDD greatly accelerates it. It allows the development team not only to write the software in the right way, but to help the business to decide if it’s the right thing.
So are you ready to jump in?