We don’t just work here, we *live* here.

We’re about three weeks into the shelter-in-place, one week into the governor mandated shelter-in-place order, and about 8 projects down.

Ok, maybe that’s an exaggeration; one sec.

5 projects in.

Five projects of tidying up, moving things around, and ensuring that 6 people can all survive in a 1800 sq ft house.

They were small projects; and each on their own not at all important — mere nuisances we would encounter. Like the Hall Tree we purchased in October of last year for our new entry way (warning: clicking on that link will take you to a twitter thread that spans 11 months with lots of photos detailing the progress), that we didn’t put together until now.

Or reconfiguring the office so that my wife and I could share it (that bookcase behind me in this video doubles as her desk).

Anyway, not to lose myself here, but let’s just say we’ve had a lot of projects. Projects that weren’t really essential. We didn’t have to do them.

Except we did.

None of those projects would increase our bottom line (if such a thing actually exists in a family), but they would make it much easier for us to live together under one roof for 24 hours a day.

Your codebase is just like that.

It’s a place where your entire team lives together, works together, and tries to make it work. And unlike our halltree project; it really does add to your bottom line when you keep it tidy, or take on those small projects.

Your product owner doesn’t live in your codebase, and neither do your stakeholders. They don’t realize that that developers live here. They don’t realize that just like that annoying box that was sitting in the corner for six months (our hall-tree), any annoyance in your codebase will fester into slowing down your team’s productivity given enough time and pressure.

For instance: If you use Entity Framework, those abstractions you put into place before you realized DbContext was already a unit-of-work abstraction will hurt you at some point. If you put that off, yea, you could work around it, but you’re dealing with an annoyance that will affect every member of your team at some point, for an indefinite amount of time (until it’s fixed).

This doesn’t mean you should fix all the annoyances; but if you treat your team’s codebase a lot like you’d treat your house; you’ll start to change how you view it. It’s not a set of functions and components that generate money: It’s more than that, it’s a place where you live, and decisions you visit upon your codebase will affect your entire team.

I don’t know about you, but if I’m going to be living somewhere for six months or longer, I’m going to be sure that it’s not going to cause me six months of pain. I’m going to make sure it’s as easy to make changes and improvements as possible. I’m going to structure my project in such a way that getting into that codebase day after day is a joy, not a pain. I’m going to use TDD.

Dealing With Elephants

How do you eat an elephant?

One bite at a time.

It’s funny, of course, but it’s true.

What are our elephants?

Rewriting a system, sure.

What about a new UI?

What about refactoring a large component of the system?

All of these are elephants, but there’s an easier way to determine the elephant in your system:

It’s the part no one wants to talk about, or tackle. It’s the part that keeps getting bumped down in priority on the backlog. It’s the part that only one or two of your teammates can look at, since they either wrote it or were trained on it by the people who understood it.

That’s your elephant.

Elephants may not be expensive, but they’re unwieldy. They’re parts of the system you can’t change easily. They are parts of the system — to extend the metaphor — that do whatever they wantwhenever they want. They’re the parts of your system that have twitter quotes written about them.

The second-best way to get rid of the elephants in your system is to take them one very expensive bite at a time.

Another way is to develop systems that, by the nature of their construction, lack elephants (or at least adult elephants).

This is what Test Driven Development can offer. It trades elephants for systematized construction. If your project doesn’t need maintenance, or your team doesn’t need an O&M contract, it may not appeal to you, but for the rest of us that have to maintain these IT systems long after they’ve been written, a system without elephants sounds almost… joyful.

Can Software Development be a repeatable process?

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.

The Importance of Team Alignment

In my last blog post, the last sentence said:

[The length of time needed to complete an ADR] will vary on the team and the change needed, but is one way to align the team to move nimbly, not just quickly.

Why did I separate out moving quickly from moving nimbly?

What the heck’s the difference, and why does it matter?

When you picture someone moving quickly, you may associate that with rushing. I know I do. I picture trying to get all the kids out the door to the car to get them to school on time, or attempting to ensure three kids get to soccer and ballet on time.

When you picture someone moving nimbly, they are generally quick of pace, but even if they aren’t, they glide with a sort of confidence that isn’t found otherwise. They may hop from rock to rock, crossing a creek, but they’re sure of their footing and sure of the next rock.

That’s moving nimbly.

Put another way, a buffalo stampede moves quickly. You don’t always want that. What you do want is to be sure of your footing, and to take the right step at the right time. That’s how you move nimbly.

That’s where alignment comes in, and why an Architectural Decision Record is so important to gain alignment (and to move nimbly).

Alignment: a position of agreement or alliance

You may not always agree; and in fact if you’re using an ADR right, you’ll have periods where people disagree before they realize that they’re just seeing the same set of events in a different way. But the part of alignment I want to focus on is alliance.

Everyone may not agree with the best course of action, but everyone agrees on the goal, and aligns themselves with that goal and the chosen course of action, even if they don’t agree with it.

This is where the ADR comes in.

An ADR allows you to put the zeitgeist to paper. This is important because not everyone sees the same events the same way. If you put the business and architectural and team considerations into an ADR, you’ll uncover how other people think when they give you feedback, and you’ll learn what is important to others.

Those ‘others’?

They’re the ones you’re trying to get alignment with. That’s how software is made. With other people. Without everyone being aligned, you won’t get much done.

You want to produce better software, faster. You want to move nimbly. You want to gain alignment, as it allows you to move nimbly. Gaining alignment allows you to produce better software, faster.