Although outwardly calm, internally you break into a cold sweat, thinking of all the changes they’ve just dropped into your lap. Your gut clenches, thinking about the explosion of possible side effects those changes will have. Since this is a non-TDD environment, regressions can only be detected manually, adding days to the QA testing schedule. As a slight silver lining, you do have some tests, but they’re a combination of low-value unit tests and slow-running integration tests, so they will be generally unhelpful in this endeavor.
The more pressing issue, however, is that the existing codebase was written sloppily. The team ended up leveraging many shortcuts like tightly-coupled classes and lack of dependency injection. Because of this coupling, removing the feature will have far-ranging effects on the codebase, putting the release at risk.
Your mind flashes to the meeting last year when the team considered TDD practices. You recall the team’s skepticism and outright resistance: “It’s extra work!”… “It will slow my development cycle down!”… “My code is always perfect, so tests are insulting!”… In the end, the majority consensus came down against TDD and it was not mentioned again; The only remaining automated tests are the halfhearted ones written during the ‘tryout’ period for TDD.
This flashback triggers memories of other meetings… The one where the team decided not to use source control because it was too restrictive… Another where coding standards were deemed unnecessary because they restrict developer’s creativity… Yet another where 3-month sprints were deemed acceptable…
The Bad News:
Suddenly you realize that your hand has migrated upwards to the universal “I have a migraine” position. Letting out a sigh and lowering your hand, you say “There’s just too much partially implemented stuff to remove, and it’s basically like a delicate surgery. There’s also going to be a few extra days on the QA side because they’re going to have to do a full regression pass. I’m going to have to call it 2-3 weeks, and even that’s pushing it – if anything at all goes wrong, we’re looking at a month or so.”
Dave’s expression gradually shifts to crestfallen as he digests the bad news. “That’s really the best you can do? You couldn’t pull it in to a guaranteed 2 weeks? We might be able to sell that to management, but more than that is out of the question.” “Dave,” you say, “The only way we’re going to bring it in at two weeks is with an all-hands death march effort combined with a ton of luck and cutting even more corners than we already do. If that’s what you need us to do, I guess we don’t have a choice, but there is a high probability of failure.” “Ok, I’ll take that to management then, we can commit to a 2-week timeframe.” as he hastily exits the room with Patti in tow.
Over the next two weeks, your fears play out just as you expected. Reverting the changes manually introduced dozens of breaking changes, all of which leaked to QA. Due to the tight coupling, some of the breaking changes were in virtually unrelated areas, causing a steady stream of bugs during the certification process. At the end of the second week, the product is somehow even less ready to ship than it was two weeks ago, and the deadline is missed. Just before the end of the day, you’re called into the boss’ office and given your walking papers.
A few weeks later, you see the silver lining as you get hired onto an experienced, actively-practicing TDD team. Over the next couple of years you hone your skills, learning new tools and techniques to ensure code coverage, testability, and overall codebase robustness. You’ve recently been promoted to team lead, and one afternoon deja vu strikes as Michelle, the BA and Phillip the PM step into your office to tell you about a schedule change from management…