End-users are super important in Database Design
In Web Developer's Life By Gustavo Gómez Macías (Goz) on 22 Feb 2019
Photo by rawpixel
I'm going back teaching Database Design and something I always tell my students is that we must involve the right end-user, that is very very important to achieve a good database design. It's almost like becoming the good cop from a movie trying to get the confession from the criminal, in our case to get the real problem to solve. This will make that the end-user participates actively in the system's development and in the end this will be his system too.
This type of topics are those that in most of the time one does not find in books. The purity of the normalizations, associations, diagrams and many other topics usually set aside the important human issue. So let me share two experiences where end-users were really important.
The good one
A few years ago I was asked to develop a system, the end-user would be the assistant of one of the bosses. The type of system or client does not matter, the point is that I introduced myself to the assistant and told her that I would develop the system she would use and that I would like to know his opinion about what the ideal system would be like in his mind so that she could do his work easier.
She looked confused and between answers she said: This is very strange because anyone had never asked me anything about what I needed in systems. Every time a new system arrives to the company, she just got it installed and received a manual, the promess was always the same: this will make your job easier. Obviously these systems never helped her and over time they became obsolete.
When I showed up that day she showed me all the records of the place perfectly arranged in different handwritten notebooks (a database). We worked together for a few weeks and in the end we developed a system that is still in production.
The last time I saw the assistant, she told me that she is still using our system but that nobody asks her anything again to develop new systems.
The bad one
A few years ago my wife and I were asked to develop a system for a big client, there would be three end-users: boss1, boss2 and the accountant. In the first meeting just boss1 and boss2 were present, they told us that they needed some kind of system to know exactly where their money is spent in every moment (millions of mexican pesos distributed in different projects) and how much do they have. They told us that the accountant do all the work from his notebook, not computer, just by hand. I could not stop saying "What an important notebook", they nodded. Our next comment was that we have to talk with the accountant, we would have to work weeks with him. The bosses just told us: yes of course but we have to told you that he is kind a difficult.
Difficult they said, well that was a polite form to describe the accountant. Over five long loooonggg meetings (and two months) me and my wife were able to unvail all the "secrets from the notebook" and translate that to a functional database model. There were meetings that I just wanted to be the bad cop and slap my client, he obviously didn't want to reveal his information, that was "his precious" power. Many people were dependant from this guy's information and we were taking away so he really was unpleasent with us.
The bosses were really happy but at the end we could never check if we got a correct database design, Why? well the bosses never payed, so the system never got to production (insert violin sounds).
