Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

In Defense of Rigor (Part 2 of 3)

June 6th, 2007 · No Comments

DJ1.0, Contributing EditorDJ1.0 is a contributing editor of We don’t know much about DJ1.0, since he participates in the dark side anonymously. We suspect DJ1.0 is a “he” since he refers to a wife in an early post, but then again, maybe they’re from Massachusetts… Either way, you can reach DJ1.0 at

In my last post, I made some assertions regarding the benefits of rigor. Now let me define what that means and how to apply it to IT.

What rigor does not mean is the normal IT approach of obstacle based development. Rigor is not about a series of flaming stage gates, approvals, and forms. Rigor is not constraining what people do and when they do it. Rigor is about empirical evidence and making decisions based on what is commonly referred to as data and sometimes even facts.

Here are two important examples.

1) Do not state the obvious. Only interesting conclusions are interesting.

As I prepared my thesis proposal, I was constantly reminded that research should contribute to the body of knowledge. More importantly, it should expand the body of knowledge. This is why you don’t see a lot of studies about if a Porsche Boxster can outrun a stock Dodge Neon (it can) or if tabouli tastes good (it doesn’t) Masters of the obvious have trouble surviving in academia. Thank goodness.

Yet how many times have you seen IT presentations or IT vision docs that say obvious stuff like “We need to reduce expenses.” “We need to build reusable components.” “We need to enable the business.” This just in – plants need water – film at eleven. IT would be better off if everyone worked to expand the body of knowledge not parrot it.

2) Define what you mean.

This is an idea so engrained in research that it is almost second nature. In IT, it is almost unnatural to do it at all. What does “reusable” mean? What does “user” mean? What does “response time” mean? Most IT definitions are like the Supreme Court definition of obscenity – “I know it when I see it.” Unfortunately, this approach can lead to poor decisions.

The fact is that terms are not obvious. Even something as simple as “user” is ambiguous. Is a user anyone that uses your system? So a person who uses your system everyday to run their business is the same as a temp who logs in once to print-out something? Is anyone who has ever used your system a user? Someone who used it three years ago is still considered a user? What about one year ago? What about “power user”? Is this idea based on time or fluency? The fact is, how you conceptualize “user” effects how you create and maintain a system for them.

There was an old trick I used when I taught classes. I would ask the class, “What is the fastest car?” Invariably, males in the class would shout out small, fast sports cars. I would then ask, “What about for moving 8 people?” With this new context, the sports car no longer applies. This lesson was normally about requirements. (An upcoming post entitled “No one buys a drill” addresses this further) But it is also about definition. No one ever bothered to simply ask, “What do you mean by ‘fast’?”

Terms aren’t obvious in language and when you try to measure them – a process called operationalization – it gets even worse. Rigor dictates that you try to boil down your terms into something you can measure objectively. Something not only you know when you see it – but others do also.

This is normally where the “CS is an art” crowd starts to get riled up. Software architects – of which I am one – often consider what they do an art, not a science. After decades of experience, we know a reusable component when we see it. Our judgment in these matters is very good and we trust our gut. To try and operationalize that into some rigorous formula undercuts what we (as architects) do.

That premise has the distinct disadvantage of being wrong. I think the thousands of art professors, instructors of music theory, and English Lit teachers would agree with me. Art not only can be taught, in most cases, it must be taught. Mozart – despite revisionist movie history, worked extremely hard, practiced and reworked draft after draft. Bobby Fischer studied tirelessly.

Experience allows you to internalize operations you have used over and over again. Judgments made from experience are still data-based. You don’t just randomly say, “Yeah this code looks secure.” Behind the scenes, you are using objective measures and patterns. Because you are experienced, you happen to know about them. But because you are experienced, you also happen to have forgotten what they are – like a locker combination that your fingers remember but your mind doesn’t.

The important difference is that research requires you to be explicit, IT doesn’t. IT makes so many bad decisions in the name of an idea like: agility, reuse, standards. Academics may ask pie-in-the-sky questions, but they do not let ambiguous undefined terms run amok and guide decisions.

In my next post in this series, I will cover two more really important ideas that IT could use to better itself.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: DJ1.0

0 responses so far ↓

  • There are no comments yet...Kick things off by filling out the form below.

Leave a Comment