I’m always amused at the reaction to my response when people ask,

“You’ve been programming for a really long time, you must be really good in math.”

My answer is usually something like, “No, I’m TERRIBLE at math, that’s why I started programming. I am much better at English.”

They’re like… wha? Huh?

A Kid And A Mainframe

I first started programming (in the late 1970s on a DEC PDP/11 in DiBOL. A long story how a little kid was able to get such unprecedented access to technology so early… but I soon realized the importance of the gap between what people wanted to accomplish with a particular computer program, and the art of creating the magical code that instructed the computer itself to do it.

A “good program” achieved an approximate result for a particular person (end user) based on their vision of how the system could actually help them in their daily endeavors… automate a task, store information, create reports, etc…

Fast forward to the early 1980′s, I was around 14 years old when I started writing business code to help accomplish some task or another in the context of a business process.

I’d never been schooled in the fine arts of “business analysis”, or the hybrid role of an individual who can understand a functional business process; and then translate that into a plan for the technical efforts necessary to produce the end results.

I was still a kid in middle school and high school. And I lived waaaay out in the boonies, so public school had no idea what to do with a kid like me.

The Analyst Emerges

In this era, the entire competency of the “business analyst” was just emerging as a distinct IT role. Back then, everything was called “data processing”, and it was assumed that if you were in the field, you had general knowledge across all facets of computing.

Concepts like a “use case” or great tools like UML (unified modeling language) didn’t exist.

A programmer took a list of the various elements of information a user needed and arbitrarily created a “screen” to either:

  1. input data in some fashion; or,
  2. look up data and present it in a readable format.

There was almost always a disconnect between what the programmer created, and what the end user ultimately wanted or needed.

The programmers really didn’t understand business process itself, which ends up being the real-world context within which an end user actually uses the data as part of their day-to-day tasks in a respective role or function.

Not knowing any better, I would try to understand the purpose of an individual program or a system of programs better by actually applying something from my own, youthful, limited worldview.

Junior High English Class

I was in the 8th grade… waaaay out in the boondocks at Dixon-Israel Middle School near Eaton, Ohio – literally on the Ohio-Indiana border in the middle of nowhere.

And of all places to find such a cat, my English teacher was a British guy named Andy Williams (thank you wherever you are BTW).

What a better teacher for English than a British guy, huh?

Being the quirky chap that he was, reeking of cigarette smoke and those pop bottle, prism lens glasses that made his eyes look freakishly tiny, Mr. Williams had no idea all those efforts to drill sentence diagramming into our adolescent brains would become the foundation for my eventual success in the information systems world.

Sadly, diagramming sentences has become somewhat of an anachronism in present day education. I am not really sure why, because it was one of the most useful things I retained from my 12 years of public education.

I’m not certain who is ultimately responsible for pulling it out of the average public education curriculum, but I am inclined to believe it’s not really a good thing to abandon.

Pulling It All Together

After English class, I’d wander down the hall to Mr. Vaughn’s 8th grade math class, and start writing fun stuff on those gigantoid TRS-80 boat anchors.

I never realized the implications this would have on my future interest and understanding of things like database design, cognitive linguistics and ultimately — information architecture.

One of the first areas of programming I explored was that of text-based adventure games. Most coders from my era remember Zork… you’ve been eaten by a grue!

The language commands of where you could navigate and actions you could take were parsed and stored in an array – which was ultimately used to traverse the game world and perform the actions necessary to advance towards the goal.

Turning It Into A Career

So a few years later I figured out I could make money writing computer applications (yes, still as a teen in the 1980’s). I would sit down with someone who wanted me to write a program to do something useful, and simply have them narrate to me in their own words what they wanted the program to actually do.

This could be some business process, or just some random, fun program that I would write for people to do various silly things. I would get them to make it as detailed as possible, asking about fields, behaviors, etc…

Once I had their written narrative, I would literally diagram each sentence in good ol’ Andy Williams English class style!

The nouns in the sentences became the individual data objects that would require various strings, classes, database tables and columns.

The verbs became the actual routines or actions that I would have the computer “do” with the nouns. Various other elements became things like conditional logic… adjectives became the basis for inheritance of attributes about the data within a context, etc…

It wasn’t perfect, and it certainly has it’s flaws. But it helped guide me down the path towards creating a program that got pretty close to what the person wanted on the first shot.

Isn’t information architecture really just a parallel to language itself?

Taxonomies, ontologies, metadata, etc…

It’s all the same stuff… how humans abstract concepts at a cognitive level… assign labels to objects within a context.

Sit on the chair
I sit on a chair
Michael is sitting on his brown leather chair in his office at home
… and so on…

Language Is The Construct

Language is the enabler of communicating abstracted ideas and concepts from one to another. Information architecture isn’t just the design of how information is presented on a screen in some software application or web browser.

Information architecture is the basis of how we organize ideas and concepts within our brains!

It starts with applying concrete definitions to abstract concepts, then categorizing those terms in a vocabulary. That vocabulary is used to exchange ideas and information with others within a specific context. Information architecture is also how enterprises attempt to manage the massive volumes of data needed and resulting from operations.

Information architecture is language is information architecture.


Michael Hiles

GenX writer, speaker, mentor, C-level digital, & tech business guy. Sold my first website project in 1994. The rest is history. Serial entrepreneur. I work with lots of startups as managing director of Founder Institute Cincinnati. Bourbon, coffee, Legos, things that explode. Husband & daddy.

View all posts