As you may have noticed by now, I’ve decided to rename the site once again. While the New Name (“Worse Than Failure”) seemed like a good fit at the time, and the New, New Name (“The Daily Worse Than Failure”) seemed like an even better fit, it turns out that there was one name that was still better: the New, New, New Name, or “The Daily WTF.”

While I understand that the New, New, New Name may seem completely and entirely identical to the Original Name, there are a few key feature changes here. But instead of detailing those, I think it’s much more valuable to do a quick Site Renaming post-mortem. This will allow us to explore the lessons learned and answer one key question: why did the deployment of the Older Newer Names not work?

 

It Was My Predecessor’s Fault

Yes, I realize that I’ve been the editor here at WTF since day one. However, the Alex of Early 2007 was a completely different person than me (the Alex of Late 2007). Having significantly more experience and a vast breadth of wisdom under my belt, it’s now obvious that Alex of Early 2007 was wrong for the job.

I can assure all of you that appropriate actions have been taken – for starters, Alex of Early 2007 does not work here anymore – and the reins have changed hands. While the damage that was done by Alex of Early 2007 cannot be undone, I, Alex of Late 2007, will lead things in the right direction.

Poor Requirements

As they say, a Site Renaming is only as good as the Requirements, and in this case, the Requirements fell shy. Assumptions were made, liberties were taken, and in the end, the Site Renaming fell short of what was actually needed.

Deficient Tools

One can’t do something right unless he has the right tools, and in this case, we had deficient tools. Without the latest and greatest tools and technologies in Site Renaming, it’s virtually to implement such an undertaking in today’s competitive market.

Not Enough QA/Testing

Don’t get me wrong, both New Name and the New, New Name were extensively tested before going into production. It passed local testing (everyone here seemed to not hate it) and QA testing. Unfortunately, all aspects of the production environment were not taken into consideration.

Lacking Training and Transitioning

While both the New Name and the New, New Name technically worked to spec when going into production, the Name’s users had grown accustomed to the specific features and functionality of the original name. Had an effort been placed in developing a Transitional Name, it’s entirely possible that both the New Name, and the New, New Name would have been received better.

Conclusion: The Real Problem Was A Faulty Process

While it’s easy to point fingers and assign blame to any single person, the real culprit here was The Process. This poorly monitored Site Renaming process allowed issues to fall through the cracks in all areas, from requirements to implementation to testing. The good news is that the process of process improvement has been started, which will allow future Site Renaming to go much smoother.

 

I think we have all learned some valuable lessons from this post-mortem, and I hope that the New, New, New Name (“The Daily WTF”) will meet all necessary requirements. That said, I look forward to future Name enhancements and support.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!