Today we have a guest editorial from Kendra Little as Steve is traveling.

As Redgate’s Database Development Disaster Story Contest continues, we’ve got another story of database design gone wrong from Kendra Little. Tell us your own story here before March 20, 2019.

The V1 Team’s Doomed Redesign

Once upon a time, I worked for a startup that purchased another startup. For the first year, the acquired company's applications operated independently, as they were originally designed. After that point, developers from both organizations began merging together, and a team was created and assigned the task of redesigning the applications of the purchased company to be more scalable. Let's call this the "V1 Team."

The existing production legacy applications involved complex data processing. The idea was that the V1 Team would reproduce almost all functionality of the legacy applications in the initial release of the redone application.

The V1 Team went off and began work. As they worked through their long development cycle, features continued to be added to the production application. These were added to the workload of the V1 Team, continuously increasing the scope of their project and delaying their initial release date.

There were a lot of quite smart developers on the V1 Team, people I enjoyed working with, but I found myself stopping by their area less frequently over time - frankly, it was a depressing place to visit. The team was overworked and frustrated. They were never releasing any code to production, and there were no design meetings with anyone.

Finally, we heard that the redesigned applications were going to be ready to launch soon! This was good news, as the legacy applications were not easy to support.

The first thing I remember about the database deployments for the V1 Team's new application is that... well, they didn't actually deploy. The V1 Team had been stuck in a prototype environment for so long that quite a bit of work was needed to bring the codebase into a deployable state for pre-production and production domains.

The second thing I remember is looking at one example table in one of the V1 Team's new databases, and finding that the clustered primary key was defined as being the combination of four uniqueidentifier columns (GUIDs).

I'm not the kind of DBA who sees a uniqueidentifier column as being universally bad or a sign of doom. However, keeping clustering keys relatively narrow is generally a good practice for scalability in SQL Server-- and a 64 byte surrogate key is a particularly bad sign. But it was too late to make any changes: the poor V1 Team was desperate to get anything in front of a customer at this point.

It was a tricky and painful struggle for both the V1 Team and the Operations teams to get that code into production and to begin supporting it. Performance wasn't great, and customer response was lukewarm at best-- after all, they'd been told the whole project was about scalability.

Nobody declared victory, least of all the customers.

Scoping and architecture discussions, I learned, are critical for any project.

Tell us your story

The contest closes March 20, and you are welcome to enter more than once.