The WWAIT Trap

The dangers of fixing things "While we are in there"

Don’t half ass two things, whole ass one thing. – Ron Swanson

The first project I was on as a junior developer ultimately failed, largely in part to a temptation that I have coined as the “While We Are In There” trap. I like the acronym because it is also the response you should have when you hear the words “while we are in there”, even with the little stutter: w-wait. But lets get back to the story since I think it illustrates it nicely.

I was fresh out of college and joined a company writing pharmacy software. I joined a new team who would be working on rewriting a legacy windows application into a modern web app (modern at the time was Silverlight but we wont go there). We didn’t want to just rewrite the application we wanted to “fix” all of the things that were wrong with the legacy windows desktop application. Because no one was using our new software yet, we could redesign the database and change some of the processes. This made sense because since we were not burdened by customers we could move quickly to fix these issues and design the system from the ground up. These decisions, while correct in that they were good improvements, ultimately killed the project.

Joel Spolsky talks about all of the reasons you should not rewrite software. If you happen to decide that you are of course the exception, which is what we all have done, then you need to be on the lookout for the WWAIT trap. There will be enormous temptation from developers to fix the woes of the past while also delivering product. Every engineer will have a pet peeve that they have been wanting to fix. These changes will add up and become distractions from delivering customer value.

The WWAIT line is common in car repair. If you ever get your timing belt replaced its likely the mechanic is going to say, “We should replace the water pump while we are in there.” If they are going to spend all of the time to take apart your engine, they might as well update the other parts that are likely to be worn out. In this case it makes sense because you are dealing with very well know systems and parameters. Software is more like art than automotive repair.

The logic for software goes that since customers aren’t using the software, it will make it much easier to make changes. No inflight migrations are needed and no one has to worry that a crazy bug will make it into production. So while we have the code all taken apart, we might as well do some things we have always wanted to do. The truth is that customer usage provides just enough friction to keep the good but unneeded changes from happening. Once that friction is removed then a flood of changes, with second and third order consequences, will flood in. Again, these are often good changes, is just that when you do them all together it adds complexity which isnt good for software.

The most dangerous of these changes is changes to the database schema. This is what got us on our project. We made a few critical changes to the database that we felt would dramatically improve the software. But because of these changes each customer had to be migrated from the legacy database to the new one. After working pretty hard to get the process down we figured we could do one every 2 weeks. At that rate it would have taken 2 years to move over every customer and that was an optimistic timeline.

If you are in the middle of planning for a rewrite of one of your services or if you have made the most dangerous of moves to rewrite your core app just listen for the “while we are in there” traps to be set. As a manager you need to navigate this treacherous water vary carefully. I am routing for you, we all in this together.