Since the Starting again blog post from January 2019, I’ve gone through several activities and phases:
1. Unsettling Ennui (I’d say depression, but this is public, and I’m not sure we’re ready for that conversation).
2. Hearing Colin Powell’s quote in my ears at least once per day: “never let your ego get so close to your position that when your position fails, your ego goes with it.
3. Meeting with the local SCORE mentor and developing a business plan
4. Some freelancing in .NET and .NET Core.
5. Refining that business plan and trying to figure out how to niche down, who to serve, and how to serve them.
6. Discovering The Business of Authority podcast (and subsequently Ditching Hourly), and binging those.
7. Talking with potential customers and and refining who I’m serving, why I’m serving them, and how I’m serving them.
8. Figuring out that “Solutions Consultant” is an utterly bland term that isn’t useful on its own.
9. Making a map of what I’m good at, what I like to do, and what there is an existing market for, and what the gaps are in that market.
10. Reaching out to friends and people I know to ask their thoughts and to re-establish those connections.
11. Had a coaching call with Jonathan Stark; where we honed in on what I could offer: helping software teams double their productivity, and was just left with a ‘how’ (inside baseball: I initially decided to focus on process improvements as a way to help teams go faster, but abandoned it because I don’t <3 JIRA *that* much).
I’m probably forgetting something; but it’s been a year.
Around January of 2020 (A full year later!) I finally finished the exercise of what I’m good at, what I like doing, and what there’s a market for, that matches what I want to do: Help software teams build better software, faster.
The decision came from a conversation I had with Brent Ozar a year ago(!). If you don’t know Brent, he specializes in making SQL Server faster and more reliable, and he has been doing this sort of work for at least 10 years now (longer, but I think he’s been in business for himself for the past ten years). He and I were on a call and he was giving me some advice when I expressed that I didn’t really know what to offer. He said (paraphrased), “Whatever it is. Make sure you like it. A lot. Because you’ll be teaching/talking/reading about it, every day, forever.”
So when I ran down the list of things that help software teams build better software, faster, I thought about processes (requirements analysis, branching/merging, team practices, architectural practices, TDD), tools (git, JIRA, testing frameworks), and development methodologies (agile practices such as XP, Scrum, developer methodologies like TDD), and I realized that I have extensive experience in failing and succeeding with TDD, that there’s a gap in how it’s taught and how it’s presented, that it really is a huge enabler of team productivity, and that learning TDD doesn’t require a change in a team’s process culture to implement.
In other words, it’s one of the practices that a team can implement on its own, without trying to drive the larger organizational cultural change that scrum and XP require.
I’ve practiced TDD across teams and organizations, have seen where it fails and where it succeeds, and I believe it’s a good way for software teams to level-up how they build software. I believe TDD helps organizations build software sustainably, without death-marches brought on by feature explosion, and allow teams to make changes to software more quickly with confidence.
These are not new benefits of TDD. What is ‘new’ (though even this is 8 years old) is how teams should learn TDD. One of my chief complaints with how TDD is taught is that it falls apart on any application larger than a todo-list. If you practice ‘outside-in’ TDD, mocking and stubbing make your “units” brittle, causing lots of pain and changes whenever a caller changes how it arrives at a particular result. If you practice inside-out TDD, it’s far too easy to create units that have a “can’t see the forest for the trees” problem, and they run into issues as soon as you hit the boundaries of any application – the UI, Network IO, Disk IO, or the framework you’re using.
Up until this point, teams have widely either shunned TDD, or adopted TDD in small places, or tried to adopt TDD Across the application but through a patchwork of integrated tests and TDD’d code, are exhausted by the whole process. Simply put, it’s easier not to adopt TDD.
There is a solution for all this, and while I heard about it in 2012, I needed to experience it and use it for myself, and so I did. It wasn’t until last year that I realized, if we’re going to get teams and businesses to adopt TDD, we need to teach it in a way that makes it sustainable. We need to teach this approach, and more importantly, show how it works (as it is a rather large departure from how we develop software now).
And so starting in earnest this last January, I started focusing my efforts on this problem: Finding ways to help teams adopt TDD practices that will help them deliver better software, faster. The ‘faster’ part sounds.. trite, I know. That’s where the different stakeholders in a software project have different priorities. The delivery manager wants features yesterday. The development team doesn’t want a deathmarch. Neither wants 11th hour bugs and a stressful launch. And yet, that happens all too often.
I believe that adopting TDD (particularly the FauxO variety described in the above link) will help software teams and businesses that rely on project-based work to create a better experience for themselves and their customers. And since the majority of my experience is doing so in a .NET centered world, that’s who I’m serving: .NET project teams (think internal IT teams, and software development consultancies), and I’m serving them through on-site .NET TDD immersion training and remote TDD mentoring and coaching.
As an end note if this interests you, you can subscribe to my daily emails (in that nice input box below), you’ll also receive emails related to the intersection of productivity, .NET software teams, and TDD.