| Review Early and Often Several years ago, I was brought in on a project to review a database design. I was provided a time for a meeting. No written requirements were available, but I generally knew what the system was supposed to do. No before/after schema images showed what was being changed were available. Still, I was assured that everything would be revealed at the meeting. Yes, my Data Architect/Spidey Sense was buzzing quite loudly. If I had been a contractor deciding whether to take this assignment, I would have likely just politely stood up and walked backward out of the door. It didn't take Svengali to predict the forthcoming train wreck. I put on my confident, civil face and joined the meeting. As I listened to the developers explain their design, I had concerns. It wasn't the worst design ever, but it missed some fundamental database design issues, and some of the logic didn't make much sense to me. I was personally interested not just as a person with the title "Data Architect," but also because I would be involved in architecting the data warehouse components once these changes were implemented. The few changes I could convince them of were places where there was no way that the software would meet the stated requirements, not even with carefully crafted queries they planned to manage the processes. As I asked questions about the design, the developer who did the design defended their database, sometimes with "we already did it this way, can't change," "that is out of scope," and my favorite: "good idea, but we don't have time to make big changes, maybe in the next version." In my 25+ years in IT, I've learned that the only way the next version or any software internals will be different from the current one is if the requirements change. During the meeting, my questions are clearly very annoying to them. Why am I questioning their work? They have already created tables, written much of the interface code, and are close to starting user testing. I don't blame them for reacting to my list of concerns. If you start poking holes in a database (or UI, for that matter) that I have worked hard on and believe I am nearly finished with⦠I am going to be a bit defensive, too (well, I think the term my boss at the time would have said was "whiny") because I genuinely believe that the work I have done is "awesome." I mean, it has passed all of my tests, right? Who am I? The problem is pretty standard. I think I am an engineer in this process, but all that was expected of me was to be the building inspector. People want to hear: "Yes" or "People are going to die if you do it this way." The Building inspector is there to make sure that what has been built meets wiring standards, plumbing standards, etc. There is no longer time to say: "Wow, this building is less than awesome," "This building won't meet the needs of the tenants," or "...the needs of the tenants in two weeks/years". Just will this kill anyone in the future based on the current standards. In the case of a database design, is there a way this database will work well enough? The building inspector has a checklist that has to be met. Exposed wires? Fail. Wrong size pipes? Fail. Is the room too small for the triplets that will be sleeping in the second bedroom? Nothing in the code about the size of that room handling 3 6'5" basketball players. We are all good. And databases have a lot more "it depends" type rules than they di fixed rules. Even the long-standing normalization rules are more suggestions than rules. (Really, really GOOD suggestions, but still only suggestions. The point When you are building something as foundational as a database design. Get eyes on it. If you have someone around knowledgeable about database design, that is ideal. Even novices that weren't involved in the design may notice difficulties. I have learned a lot from beginners through the years because they don't get fixated on things like poor naming, weird datatypes (why varchar(254) for a name? or numeric(38,2) for a monetary amount? Stuff like that draws my eyes right to it. I may miss more subtle issues!) So please do what you can to have your first reviews with people when the possible answers can be enacted, no matter what. My rule of thumb is that when you are reviewing a design, there should be three base answers to every question about your design: - Great idea. Let me do what I can to meet the requirements better using your suggestion.
- That idea is okay, but it does not meet the customer's requirements.
- That is not a valid way to solve that problem.
A bit more tact is clearly required for that last one, but you get the idea. If you are showing anyone else your work for the first time and can't give these answers, it is too late to be of any value. And then no one will be happy⦠certainly not your users when they get stuck with your design that will be corrected....next time.  Louis Davidson (@drsql) Join the debate, and respond to the editorial on the forums |
