There has been a surge in recent years involving Test Driven Development, something that Mike Amundsen and I were discussing last night. It's not a development style that we work with much and that discussion led to this post and a new style of programming we call MDD, матрёшка doll development. матрёшка (Matryoshka) dolls are nesting dolls, looking something like this:
To understand the MDD, let's look at TDD and some of the reasons it seems to have exploded in popularity. One reason that I posited was that TDD is really great for quickly creating demo software. Create the stub of a class, wire it up to a UI and you have a working, though non-functional demo that can become functional as stub methods are replaced with functional code. Stubbing code is a good way to write code, but TDD requires such things, and requires writing the tests before writing functional code. But while this is a benefit to TDD, it turns out there is a very large downside to TDD and that is the tight coupling of code.
TDD is a way to force code to be specific and stateful. The code has to match consistently in all ways in order for it to work properly. And, while you may be saying to yourself that such tight binding is good, I suspect that the scenario can be broken down quickly to show that tight binding is not as beneficial as some folks want you to believe.
For an analogy, let's look at a house, built in TDD mode. It's a simple, shotgun house with a Living Room, Dining Room, Kitchen and Bedroom in that order. All we want to do is to change the dining room table from a small 2 person table to a larger 6 place setting. So we simply rebuild the entire shotgun house with the new dining room and all is fine and dandy.
Except that anyone who wants to enter the house now needs to know it has a dining room table for 6 instead of 2. Doesn't matter if they are doing nothing more than opening the front door to check to see if there's a package waiting to be delivered in the living room and have no knowledge of the Dining Room nor care about the Dining Room, they need to know that the Dining Room now has a bigger table because the dining room is tightly coupled to the living room.
Yes, a whole suite of tests can be run against that shotgun house to make sure nothing broke, but those test are probably going to also know the dining room table expanded, even if they don't go into the living room. Because tightly bound TDD is like the матрёшка dolls in that everything has to fit together exactly so and everything is statefully bound. And that, to me, is a major problem.
There is an answer, but it's not one that most people are going to like, and that's Stateless programming. Instead of tightly binding everything together, make sure every piece of code stands alone and doesn't require knowledge of anything else to get the job done. Let me open the living room door and see if there's a pacakge to deliver without requiring any knowledge of the rest of the house because I don't care about the rest of the house. The state of a package in the dining room doesn't matter to me, I only care about the package when it's in the living room.
When I think of Stateless programming, I think of 3 descriptions that give it an advantage over TDD:
- It's more flexible. I can change up my dining room and it may or may not affect folks using the dining room but I certainly don't need to affect anyone who is using some other functionality.
- That flexibility makes it more Agile. I can implement my changes without it affecting anything else.
- It's more demanding to code statelessly. I'm not gonna lie about this, but the extra demands in writing stateless code provide the flexibility that's missing from TDD. And that's an advantage because it's that minor inconvenience of writing more demanding code that creates the flexibility and agility of stateless code.
I'm sure that there are a lot of programmers and architects who have read that list and are ready to start telling me that I am mis-using the word Agile and that TDD provides very Agile paradigms. But they are using Agile in a specific discipline. And TDD is agile like a Ford Mondeo while stateless programming is agile like a Ferarri 599. To understand the difference, let's take a quick look at the dreaded F word that Microsoft is so fond of, Frameworks.
I think everything coming out of Redmond lately has a three letter acronym (TLA) ending in F. And there are times when a Framework makes a lot of sense, but not all the time. Using a Framework in your application can be very much like installing a full-blown transportation infrastructure, complete with subways and buses when all you want to build is a dirt track for you go-cart. Even if you're plan is to build a stock car track, you're not going to be using subways or buses or ferries. But a lot of projects use Frameworks and I think I know why.
Microsoft likes to say they have taken care of the plumbing that we programmers can focus on more challenging issues. Over the years, however, that plumbing has grown in complexity to the point that using the various Frameworks is less helpful than not; rather, it is more helpful to start but far less helpful as you go along.
Let's say that you're on a team that's starting out a new project. Using the various TLA's Microsoft has provided, you can quickly put together a prototype, kind of like going to a large rental company and asking for transportation and getting a fleet of Ford Mondeos. They are perfectly adequate cars for transportation, easy to get and everyone knows how to use them. But will they actually take your project where it needs to go?
There are companies in Minnesota that retrofit your cars to be more prepared for winter by replacing tires with tracks, something like this:
Retrofitting a vehicle can be far more expensive than designing it the way you need from the beginning. It can also be more time-consuming. And when managers see a demo whipped up in a couple of weeks they wonder why it takes so long to get a real project out the door and finished. This is one consequence of using a framework incorrectly and an expense in both dollars and time that applies to many projects.
How can you tell when are you using a framework incorrectly? When the framework constrains your programming, forcing you to contort your program into the shape of the framework:
A man goes into a tailor shop to buy a new suit. The tailor helps him try one on. It looks good. But then he sees that one leg is too long. The tailor suggests that he hitch it up. Then the arm is too long. He hitches that up, and so on. The man is confused but everyone has told him that this is the best tailor in town so he accepts the adjustments, he admires himself in the glass and purchases the suit. As he hobbles down the street holding his suit carefully in place, two men come along. One exclaims, “Look at that poor man!” The other replies, “Yes, but he's got a mighty fine tailor.”
When you start hobbling your program to fit the constraints of the framework, you're doing it wrong. If your framework makes you build out an entire transportation system to enable you to race cars around a track, you're doing it wrong. And if your framework requires everyone to know the size of the dining room table to check for a package in the living room, you're doing it wrong.
Finally, if your framework has tight binding and requires state knowledge outside of the piece you're working on, you're doing it wrong. All state should be self-contained. If it's not, you're increasing your scalability issues and hobbling your program.
I'll be talking a great deal more about state and non-framework programming over the next several weeks as I finally launch a new series on using Azure for building truly scalable projects.
And I'll be doing my best to avoid матрёшка doll development.
Josef Finsel
Azure-Architect.com