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.

Published by


Originally, this was a pretty darn boring post. Kinda like... Well I won't go there. Perhaps its still on the robotic side but... I could say I like music. Safe, generic and non-comittal. Or, I could say that I've been having a blast tuning up my old guitars, getting blisters on my fingers and turning the amp up past 2. Amazaing what a little overdrive and a half pressed wahwah pedal can do for a sound. Get that cool "Money for Nothin" vibe happening. I get a real kick out of reading old Sci Fi. Reading Asimov's vision about the future is really entertaining now. When he wrote much of the material, the items that were futuristic were day to day tools I used in the early part of my career. Microfiche and the like. I also remember that upstart Microsoft and MS DOS...and can you say Lotus 123? So maybe this is a little better than "I like to read and play music". My career is focused on Team Leadership and Technology. Both share the attributes of continual growth and education. Currently, I manage a team of 4 programmers as direct reports. I've been in this role since 08/2007. Prior to that, I was the team lead (on site) for integration with the customer. Customers ranged from local government to manufacturing and medical. Teams ranged in size from one to six additional team members. On the other side is technology. I've been keeping current with .net technologies focusing on C# and Sharepoint (2007/2010). Specialties Team Building and Management Technical Staff Recruiting Microsoft Visual Studio 7 through 2010 (VB.NET and C#.NET) Microsoft SQL Server 6.5-2008R2 (DTS, TSQL, SSIS, SSAS, and SSRS ) SharePoint 2010 (Office Integration, InfoPath, Site Management and planning) Windows Server 2008 R2 AD DS PowerShell Techology analysis Puchasng and working with vendors Microsoft licensing management and compliance Business Systems Analysis Traning plans Mentoring Training coordination.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s