Normally, I hate meetings. Meetings are poison, for the most part. They kill productivity. Over the course of my career, I have been in very few meetings that couldn’t have been accomplished via a phone call or a 5 minute discussion in someone’s office.
Today I spent two and a half hours in a meeting with the client.
Why do I mention it? Because this was the kind of meeting that matters. This was a design meeting.
In my current role I am the database developer. I am responsible for designing every aspect of the database that was not in place before I showed up two weeks ago.
Today’s meeting was spent reviewing the changes I made last week, settling on some naming conventions, and going over security. There were times when I was scribbling on my notepad as quickly as I could. There were other times when I was asking questions and getting clarification.
The important thing to take away from all of this is ask questions.
This is why design meetings are important. A design meeting is often the best place to ask about an entire system. When meeting with an entire project team, the collective knowledge of the entire application is in one room and it’s possible to unearth nearly ever facet of how a system should operate a behave given nearly any set of conditions. But, the only way it’s possible to learn and understand how an entire system operates from end-to-end is to ask questions. Ask questions until you’re blue in the face. Ask questions until the other person is sick of hearing your voice. But make sure to ask intelligent questions (this pretty much guarantees that people won’t be sick of hearing your voice, by the way).
The most important question to ask is “Why?” Don’t ask it as if you meant to say “Dear lord, why would you do something so blatantly stupid?!?” The right why to ask is the why brings about a deep understanding of the situation at hand: “Why did you design XYZ to operate this way?” or “What was the rationale for including a flanging skrill in class ABC?”
Understanding why something should work a certain way is better than understanding how something works. With a thorough understanding of the why it’s possible to create a better how.
Back to today’s meeting. A great deal of time was spent discussing security. (By security, I don’t just mean user name and password validation, I include permission checking too.) I’m sure a lot of time in the next few days will still be spent discussing security. Security is complicated. Security is always different. In this case, all of the security will exist in the database — stored procedures will do all the heavy lifting and the application will call the stored procedures.
By taking the time to sit down today and understand the way that security should work, from the initial log in all the way down to individual page level permissions, I was able to get a solid understand of how it should act and why it should work that way.
Now that I understand the why of the security layer, I understand where I made incorrect assumptions in the work that I did last week, I know why I made those assumptions, and, most important of all, I understand what it is going to take to correct those assumptions and build a better, more robust, security layer.
