Words matter

Maybe it's the English major in me -- yes, I came into software development through the "back door" of web publishing back in the 90's as a writer, not an ordained computer science or IT major -- but I am often struck by how much words matter when you're developing software.  I'm also often surprised how often we coders can remain oblivious to it.

It isn't enough to just skim over the processes of our user community, the parts of their daily lives we are attempting to absorb into the ever-hungry maw of software automation.  Although we may fool ourselves as we walk away from the project launch meeting with visions of classes, interfaces, and object graphs dancing in our heads, we simply can't get away with having only a superficial understanding of what our users need to do.

The required understanding can only be achieved if we internalize and regularly use the vocabulary of our users.  We have to stop saying "insert the Person record" and start saying "receive the initial incident report."  This is because Cheryl in records is right this very minute having an incident report placed in her hands and that is not likely to change between now and when we complete our project.  And the further away from that reality we allow our vision to drift, the further away from success we will end up.

Robert Heinlen, in his wonderful sci-fi novel, Stranger in a Strange Land, coined a wonderful word that perfectly captures what we must do:  We must grok our users' process and their language.  To grok is to delve so deeply into a particular knowledge that we come to intuitively understand it.  It becomes part of who we are and we are able to actually predict behaviors and outcomes based on that intuition.

Some developers and project managers work under the impression that it is possible to "parachute" into an organization, document their processes, and code a working system from specifications written by a third party.  While this may often be required by a misguided client, I have yet to see it end well.  I've seen millions of dollars and multiple years spent on systems that became only marginally appropriate within a few months of completion.  And they never became what the users deserved.

Deserved?  Yes, deserved.  Your users are working hard doing their jobs and you have waltzed into their organization with promises of efficiency and easier access to information.  Every day, they are telling you what they need, what they deserve, but not in the way you would expect.  They aren't speaking directly to you.  They are speaking through the vocabulary they use in their daily activities, among themselves and the people with whom they interact.  They speak through the things they do to get the job done.  Only if you listen to this unspoken dialogue can you truly grok your user community's needs.  And the only way to do that is to walk among them as much as you can.

Domain Driven Design has an explicit acceptance of this kind of understanding.  Used as intended, DDD actually makes your software project into a repository of knowledge about your users' activities.  The "Ubiquitous Language" referred to in DDD, in which you document the words used around your project, is the perfect example.  The "domain" in Domain Driven Design is not an Internet domain, and certainly is not your domain.  It's the domain of your users.  Their world, their rules, their words.

Are you listening?  Can you hear your users and the words that get them through their day?  If not, get out there among them and listen hard.  You'll be amazed at what you discover and how the course of your development efforts can be guided to success.  There's no better way to be an Above Average Programmer than by becoming a better listener, because Words Matter.