Oh Hail the Mighty Customer… or is it Oh Hell!?
As I started down this train of thought…
Visions of the future crowded in…
Then a ditty popped into my head and it’s ok now. I mean, what do you do with a drunken sailor? Especially early (err..lie) in the morning.
This is about Customers and their ways of expressing what they want in contrast to how a lot of technical experts (Consultants, programmers, architects…you name it) interpret those requirements. I mean, it’s all covered with SDLC or Agile right? Personally, Agile seems to me a better approach. As long as the project remains a manageable size. What do I mean by this?
The Grand Example
Perhaps it’s the Grand Illusion? Yes? No, STYX!… To keep this short, I’ll use a very basic example where a customer provided me with an input form and a report/input form. Not really grand…but it will work…
To break it down:
The system definition: Provide a means by which exceptions generated by customers could be recorded and reported on. The reported information needs to be generally available to specific groups and easily maintained. There are two processes by which this information is obtained. A daily review and an on demand special review. Kind of looks like:
The normal path on the left, occurs daily. Exceptions are reviewed, reported and resolved. The “Special Case” on the right only happens on demand and all records reviewed are accounted for. Those with exceptions follow the same basic path as the daily review of exceptions.
The first pass of the forms received looked something like…
An Input Form;
and the combo form:
The Input Form was pretty easy to start with to begin the database modeling portion. It had some selection entries, basic business processes etc. So here’s how that part went down…
You’re right but I’m right… conveying why the physical model is different
The customer in this case was pretty user savvy with databases. Running queries were second nature. ‘splaining how the tables were derived was initially a challenge. Now, the easy approach would be to take the basic assumptions from the initial design discussion, run back to the lab and crank out a prototype. Then negotiate change requests… I didn’t want to do that this time and it was important that the customer fully understood the data design for future support issues.
When is a Model a Model and how do you get there?
One of the bigger challenges I run into is turning the concept from idea to model. The customer always has a vision. The vision is always the right one. It’s just up to you to build it, right? You get there but it’s after cost overruns, delays, and other unsightly events.
Or worse yet, the customer has a vision but so does the architect. Then the customer’s vision is taken as just so much advice and adhered to where convenient. Under that scenario, nobody is happy with the outcome. The customer isn’t happy because the final product is not what they requested and the architect is unhappy because everybody thinks the baby is ugly. Back to cost overruns and hurt feelings.
So, back to the scenario at hand. So far, all that exists are some drawings of a potential system and it’s time for a little show and tell. Now, taking time out to go and create a database ruins the moment and delays the process so here’ s where a prototyping tool like Microsoft Access comes in real handy. Even better if the the customer has a smattering of experience and you can drive them to drink …no… create the structure.
Creating the Model as a basis of discussion
Let’s face it, the best system is define/designed when all parties have a clear understanding of what the point is. Too often have I seen a construction project go awry because the end goal was not understood. Going back to the original request. Had I just ran off with the drawing and a base understanding, the end product would have been something other than requested. Never happens right? Always a clear understanding, yes?
This is where build and discuss is such a great thing and really stresses RAD (rapid application development). I’ve worked with some interesting tools for model driven architecture and they all have their strong and weak parts. Bottom line, use the tool that you are comfortable with and can show results quickly. I like Access 2010 because you have all the parts there and upsizing to SQL is a snap.
Back to the process and the application under discussion. What appeared to me as a report, actually turned out to be a hybrid between data gleaned from the system plus some additional manually input data stored as it’s own unique set. Not only that but a whole other set of requirements came out of the modeling process. It took quite some time but even at it’s rough stage, the final product is already shaping up into something the customer is happy with and can see additional offshoots for future enhancements. This is a much better approach than building some ornately complex system that only you can support. Scary thing is that some folks do this unintentionally.
Structure out of chaos
Software development requires a structure mind, a structured process and a structured result. That works very well when you are creating a finite system of inputs and outputs. For example, a real estate listing system is concerned about the content which is composed of properties. There’s a pretty finite definition of a property and it’s uses.
Where chaos comes in to play has to do with systems that track or deal with variable content. While there is only one way to accurately describe a house in a listing, there are a lot of ways to creatively change or embellish the basic data such that the house stands out or appeals to a specific group. Which is why there list such things as Equal Housing Laws. Some Real Estate professionals were a bit more creative than others…
So how does this come around to Modeling?
When you build the app with the customer in small bits with lots of discussion, the application starts to take shape from some basic building blocks. Asking key questions about values and if those values should be limited to a specific set, yield sub tables with relationships where initially there were none. When you start out, you basically are working from the logical model of the data structure. As the discussion progresses, you can start to build out the physical model for the application. With a tool like Access, you can quickly throw up some basic forms and ask questions like: is this how you envisioned it? What happens when “this” event occurs? How do you see the data changing over time? Experience helps tune your crystal ball for those futuristic type questions but you get the gist.