Part 2 of this series covers uncovering what the terrible codebase now in your care is actually supposed to do. Part 1 covered determining whether or not the codebase in question is indeed a tire fire that can only be extinguished by a rewrite.
Tests, documentation, and accurate requirements were almost surely afterthoughts that never happened for your tire fire. Unsurprisingly, the codebase that emerged from this process behaves in erratic ways that make it impossible to pin down what it should be doing. Not infrequently, the software matches the client’s needs about as well as a down parka in Death Valley. This means you’re going to have to go back to the beginning and confirm the what, why, and who.
Requirements gathering isn’t easy under ideal circumstances. The circumstances that lead up to a tire fire make the requirements phase harder. The project has likely lost direction and clarity. Be prepared for distrustful, frustrated, and resistant stakeholders.
If you’re lucky, the tire fire’s creator abandoned project early on or the stakeholders in charge realized it was going sideways before the codebase reached production. Not only will you encounter less resistance and distrust, but not having users, production data, or a need to keep the tire fire running to meet day-to-day business needs simplifies things. Handling this case isn’t much different than a new project. Enjoy your greenfield.
If you’re not lucky, the tire fire did reach production. In this case, the biggest danger to the requirements process is getting sucked into the dysfunction swirling around the tire fire. Easier said than done, since it will have developed its own gravitational pull by this point.
Minimize the attention paid to the tire fire. Doing so will reduce the amount of negative emotions flying around. Keep stakeholders’ attention directed toward what they need to do, why they need to do it, and who will be doing it. This will prevent them from becoming distracted by how questions or providing information that would make the unsuitable experience they have now marginally better but doesn’t get at the meat of what their needs are.
Keeping track of whether you’re still facing up is important in a normal project. With a tire fire you’re going to need to check direction a lot more often. During the requirements phase, who, what, and why are up. The specifications you develop during the requirements phase will serve as up for the work that follows.
In part 3, we’ll go over developing a plan of attack to move the project closer to meeting the requirements.
Leave a Reply