We all have no problem listing the theoretical reasons why an application should be retired:

• It no longer meets the users’ needs
• It becomes too costly to maintain
• Better technology is readily available
• Integration with other, newer applications is getting more difficult

Yet we all have applications that no longer meet user needs, are too costly too maintain, could be replaced with better technology, and barely integrate with our other systems. Why is it so hard to kill off old applications?

One word: metrics. Very few CIOs develop, collect, manage, and analyze the metrics to prove that an application is past its prime.  Without hard data to document usability issues, cost concerns, or replacement expense, retiring an application shifts from being a matter of fact to a matter of opinion.  When opinions start driving the discussion, it becomes almost impossible to kill off anything in IT.

While some things can be difficult to fully measure (what is “better technology?”) other things can be easily tracked to drive retirement decisions.  In particular, usability metrics can give great insight into how users use a system, which features matter, and which features can be abandoned.

The right time to think about retiring an application is the day you begin to develop or acquire it. If you engineer usability metrics into a system, that data will be invaluable in five years when you may need to pull the plug.

Imagine a system with a few thousand reports. Imagine being tasked with eliminating the unnecessary reports. Imagine doing that with no empirical data. Imagine having to instead rely on user conjecture and anecdotal data on which reports are the “important ones.”  Users are notoriously inaccurate in deciding these things; perception and reality are very different animals.

I once had to retire an old mainframe system which several users insisted they used on a regular basis.  We saw no evidence of this, but they were adamant. Finally, we simply locked their userids to see what would happen.

The result? No complaints. It turns out they were using a completely different system that they thought was the mainframe. When we pointed this out, they happily allowed us to proceed with the retirement.

A bit of usage history would have been quite helpful. But no one ever instrumented the system to track such things, so we were left with drastic measures to move forward.

The next time you build a system, instrument the code to record who does what when.  Disk is cheap; collect the data and see what users are actually doing in your applications.  During the life of the application, such data will help tune the app and allow you to focus on what users really need.  As the app approaches its “golden years,” you’ll know when usage drops to the point that you can safely pull the plug.  As always, a little planning now saves a lot of pain and heartache later.

I appreciate your time and would offer two alternatives:

• In lieu of blogging, I’ve shifted to a different kind of conversation on Twitter, tweeting more and engaging in dialog more often.  While I’ve been on Twitter for almost two years, I’m experimenting with how it might be used to reach people in smaller snippets. I’m also tinkering with ways to manage Twitter more effectively, which still seems to elude me (and lots of other people).
• Much of the content on this site is not time-sensitive.  In fact, one of the reasons I paused was that I was starting to write the same things over and over.  I’ve been heartened to see that traffic to the blog has continued at a sustained level as people discover older but still-relevant posts through Google and many cross-links.  In just the past week or so, these topics are still attracting readers:
  • The Original Social Media Guru – Dale Carnegie figured out how to reach people, way before Facebook
  • Measuring Metrics -The value (or lack thereof) in measuring things
  • Three Envelopes -Timeless advice on avoiding disaster
  • The Happy Path – Are you testing what you need to be testing?
  • Arbitrary Boundaries – the danger of pigeonholing people

  and a perennial favorite

  • “…I’ll never go hungry again” – Scarlett O’Hara as an indicator of generational disconnect

Until I resume writing, I hope you’ll join me on Twitter and take time to explore the archives on this blog. I trust you’ll find value here, engage in some of the conversations, and stick with me until I pick things back up.  Until then, look me up on Twitter!

I started this blog more than two years ago as a way to understand the technology. After intermittent posts for eight months or so I began writing in earnest, posting articles every Monday, Wednesday, and Friday for more than a year.  245 articles and 125,000 words later, it was time to take a breather.

When I started writing, I had many things I wanted to talk about.  Typically, I had articles written two weeks in advance.  Over time, that lead time began to shrink, so that most recently I was writing the night before my self-imposed deadlines.  That resulted in rushed, poor-quality posts, which I won’t have and you don’t deserve.

I also realized that many of my topics are timeless.  On more than one occasion, I would write a post only to discover that I had written essentially the same article a year ago.  Rehashing the same topic serves no one.

Finally, I began to consider topics that really need more than 500 words, the typical length of an entry on this blog.  I prefer “short and sweet” articles; I know that I get turned off by enormous blog postings.  Nonetheless, certain topics deserve more scrutiny, and my current format does not serve these topics well.

On February 1, I just stopped posting.  I had meant to write this explanatory post soon thereafter, but became intrigued by the traffic behavior on my blog.  Instead, I stayed quiet to see what happens when a blog goes silent.  I was surprised to see that traffic takes a long time to dwindle. I don’t completely understand why, but it has caused me to rethink the impact of posting frequency and readership patterns.

So now what?  I will confess that my initial angst over stopping has been replaced by a sense of relief from not having to post.  I’ve been able to consider some more in-depth ideas (many in the area of cloud technologies and shifts in personal computing) that may result in longer, more detailed posts.  I’ve also been able to rebuild my supply of “short post” ideas, which I can draw on as the need arises.

It has become clear that every blogger needs an exit strategy, and that mine was ill-formed at best.  While I do intend to resume blogging at some point, I need to think about a real long-term strategy that will allow the content to continue to serve as a resource for those who are interested.

The best part of blogging has been the feedback and support from many, many people.  I appreciate your time when you read, and I really appreciate those who comment and extend the conversations I’ve started.  I hope you’ll continue to check back to see what I’m doing, and I hope to continue to provide value to you when my blogging becomes more frequent.  Until then, feel free to search for useful stuff I’ve already written, and don’t hesitate to connect through my Twitter presence. This experiment continues, and there’s still a lot to learn…

We’re sorry for the interruption, but our records show that this is our first outage in your area in more than two months.  Even though we project that the outage will last for at least four hours, that still means that we provided service 99.72% of the time. This easily exceeds our 99.5% target metric for excellent service! We appreciate your business and thank you for your patience as we work to restore your service. Thanks for calling!

Happy now? Of course not. Yet many folks in IT hide behind metrics in a similar fashion.

It is said that anything you measure will improve.  That provides a strong incentive to measure system availability, since we’d all like to hit that elusive goal of 100% uptime.  But there is a difference between using those metrics to improve our performance and using those metrics to improve our public relations.

Uptime tracking coupled with root cause analysis will help you find and fix many tiny problems that may exist in your environment.  Most mature IT shops have long ago figured out how to run their systems without catastrophic failure.  We can all hit availability of about 98 or 99 percent on a regular basis.  Getting much higher than that, however, involves ferreting out deep issues that may only surface under unusual circumstances. It takes discipline and focus to get there, and metrics can really help.

Metrics should never be used as a defense.  When users are affected by an outage, the last thing they want to hear is how well you’ve been doing prior to the problem.  It doesn’t matter, and you’re only annoying people that are already upset.

Similarly, metrics should never be used to tell the world what a great job you are doing.  When things are running fine, announcing that they are fine just makes you look boastful.  Most users just want IT to work, and they don’t want to think about it beyond that.  Building on our cable analogy, how would you like the cable company to call once a month to tell you that the service is running just fine?

From the user’s perspective, availability is measured as a binary value: yes or no.  There is no average, there is no track record, there is no target goal.  You either provide your service or you don’t.  Metrics matter internally so that we can improve our service.  But they have little bearing on user opinion and can actually do more harm than good.  Use them wisely.

Don spoke about his relationship with John Wooden, the legendary UCLA basketball coach. At 99, Wooden still mentors Don on a regular basis.  Don was kind enough to share some advice from Wooden, involving the lesson of five.

Yaeger noted that if you want to know your child’s GPA, don’t call the school or ask your child.  Find the GPA of their five closest friends, and your child will most likely be in the middle of that range. If you want to understand the morals and ethics of someone, understand the morals and ethics of their five closest friends.  If you want to understand the business philosophy of someone, learn about the business practices of their five closest business associates.  You get the idea.

Wooden instructed Yaeger to take a sheet of paper and make three lists.  In the first, list your five closest personal friends.  In the second, list your five closest business associates, and in the third, your five closest partners in service, such as your church or Rotary.

Now examine each list.  Do these people want what you want?  Do you aspire to be like them?  Do they share your dreams and reflect your morals and ethics?  Will they help you get to where you want to be, either personally, or professionally, or in service?  Would those people put you on their list?

If so, strengthen those relationships and make sure you give back to them as much or more than you are getting.  Recognize the value of that group and grow it to your mutual benefit.

If not, why not?  Have you chosen poorly?  Are you maintaining bad relationships?  How long will you maintain connections with people that will hinder your ability to become great?

This is a simple but powerful exercise.  These close relationships define us, and we are often too busy to give them conscious consideration.  Good or bad, we need to create and assess these lists on a regular basis.  We want to surround ourselves with people that will challenge us to be better.  And perhaps more importantly, we should live our lives in a way that others will want to have us on their lists, too.

Have you made your lists?

For each part, the catalog includes part numbers and the appropriate model year, as you might expect.  But it also includes an odd item: a “code word.”  What on earth is a code word, and why would you need one for car parts?

It turns out that back in 1924, people would often send their orders to Ford via telegram, a very early precursor to shopping on the web. Given that you paid by the word to send a telegram and that errors could be costly, you could specify your part using its code word instead of its part number and description.

Thus, if you were in need of a crankcase lower cover (part number 3101) you would send the code word “Closure.”  This ensured that you would not wind up with a complete crankcase (part 3100), whose code word was “Closet.”  That’s a big difference, since a crankcase lower cover would run you $0.35 while the whole crankcase would set you back $11.00.

There were also code words for shipping, so that the terse message “Closure Topersteen” would order one crankcase lower cover and ship it to you via standard freight.  If you want to upgrade to express shipping, you’d use “Closure Toperig” instead.

We live in an age of glorious technology, which leads us to believe that previous eras were backwards and hopeless.  In fact, people have always been clever and creative; they simply had different tools at their disposal.  Using those tools, they crafted the best possible technical world, one that seemed glorious and amazing compared to previous times.  Imagine how they lived in the olden days, when they ordered car parts by mail and had to wait three extra days as a result! Code words and telegrams were an amazing improvement.

As we struggle to build, deploy, and exploit all the new technology that comes our way, both personally and professionally, we would do well to remember that we will be seen as living in a hopelessly backward time.  “Imagine,” they will say, “how people lived with such primitive tools.  They must have been miserable!”

Not at all.  We are always living in the best of all possible worlds, in the best of all possible times.  And with luck, determination, and perseverance, we’ll continue to make it better and better.

Like me, your first reaction is probably one of extraordinary relief, with the burden of missed sarcasm forever removed from your written communication.  How did we ever get along without a sarcmark before?

My second reaction is to presume that the creators of the sarcmark are simply engaging in a little viral marketing.  Although the mainstream media is treating this as a real news story (surprise!), the entire concept is outlandish and impractical.  That said, they are selling software that allows your PC to create and display sarcmarks, so there is a bit of entrepreneurialism in there as well.

It goes without saying that the sarcmark is doomed to fail.  Not because it is a silly idea (it is) but because it is going up against too much legacy technology to ever succeed.  From that perspective, the sarcmark does provide a useful lesson.

Modern punctuation was pretty much settled a few hundred years ago.  There isn’t a lot of space (or demand) for innovation in this arena.  Nonetheless, if we were all still writing everything by hand, you might be able to create a new punctuation mark and get some people to start using it.

Unfortunately, we produce most of our written content by machine.  Those machines use standardized encodings for characters and standardized fonts for presentation.  The idea that you could revise a standard like ASCII or Unicode to include a new symbol, let alone update a substantial portion of the thousands of fonts used worldwide, is ludicrous.  The combined inertia of these systems overwhelms a tiny effort like the sarcmark.

As agents of change, IT leaders must carefully assess and understand the inertia that threatens every initiative we undertake.  Is the inertia overwhelming?  Will it crush our efforts?  Is there enough value to overcome the challenge?  With careful consideration, we can choose our battles wisely.

More importantly, is there a better solution that simply circumvents all that inertia?  The best innovation occurs when a completely new path is developed, one that bypasses all the problems at hand.  People are far more open to solutions that relieve them of the burden of difficult change and allow them to easily adopt new things.

In the realm of symbols, emoticons have succeeded in creating new symbols by easily combining existing glyphs into new patterns.  No one tried to create a new symbol for “smiling;” they created the sequence “:-)” instead.  By stepping around the inertia of character sets and keyboards and fonts, people developed a whole family of new “symbols” that expanded the meaning that could be inserted into a message.

As we tackle problems, we need to find more solutions that build on existing successful tools and avoid those that creation unwarranted, expensive disruption.  At the very least, we stand a better chance of hearing “Nice job!” without needing a sarcmark.

Invariably, many of these discussions reach a point where a proponent of cloud stuff will point out that some very large companies have made big commitments to cloud technology, moving some or all of their infrastructure and systems to the cloud.  The implication, of course, is that if these big companies are comfortable with the cloud, I should be, too.  As my mother would be quick to point out, if these companies were to jump off a bridge, should I jump off too?

There is a comfort in following the paths of others, but there is no guarantee of success.  The only thing that matters in a decision like this is what is important to your company.  Other companies are making decisions based on their own criteria; they may or may not match yours.  Simply assuming that large companies are somehow smarter than you may not be a wise decision.

In the classic Simpson’s episode Krusty Gets Busted, Bart’s idol, Krusty the Clown, is accused of robbing the local Kwik-E-Mart. The entire town of Springfield rises up in opposition to Krusty.  Bart is horrified to find that even his father Homer has turned against Krusty.  Bart complains, “Dad, you’re giving in to mob mentality!”  To which Homer replies, “No I’m not, I’m hopping on the bandwagon!  Now get with the winning team!” In the end, of course, Krusty is exonerated when it is discovered that his evil sidekick, Sideshow Bob, was the real culprit.

So many technology decisions seem to become a choice between mob mentality and joining the bandwagon. In reality, what others do should not factor into the decisions we make for ourselves and our companies.  We need to make a decision based on the unique merits of the case.

That said, critical market mass should be factored into a software or system decision, since it affects long-term maintenance and support pricing.  Nonetheless, simply assuming that something is right because others are doing it is a poor decision process.

CIOs have to pick their way through these minefields everyday.  Where will you find yourself today? As part of the mob, happily on the bandwagon, or following someone off a bridge?  What would Bart (or your Mom) think?

In meetings, I can hardly stand to not draw on the board.  If something is worth talking about, it certainly warrants a diagram or two. I am a big believer in “boxes and lines” diagrams.  If any two entities have a relationship, you can create a boxes-and-lines diagram to help express it better. Charts, trees, lists, timelines, you name it: I’d prefer to draw it out.

I’ve noticed that some people share my compulsion and others seem to have no need to leap up and draw things.  My need is so great that it was a running joke among some co-workers as to how long I could hold out before jumping to the board. How could anyone live without a whiteboard handy?

Obviously, some people are wired for visual communication and others are not.  Some people can read volumes of information and internalize it without the need for pictures.  My brain is not so gifted; I need to explicitly render the relationship to fully understand it.  I also like to color-code elements if possible, to further elaborate on important aspects of the diagram.

This affection is so bad that when I do not have a whiteboard handy, I am almost at a loss for words. Almost.  In a pinch, I’ll sketch on a sheet of paper or a napkin, but it’s not quite the same as a full whiteboard. As much as I love words, they seem incomplete without a diagram.

Don’t get the idea that I’m any sort of artist.  When I say “boxes and lines,” I mean boxes and lines and not much more.  I once even took a course on how to doodle, learning how to create little people and other elements of quick sketches.  It helped a bit, but you won’t find any of my work hanging anywhere anytime soon.

This deep desire leads to one of my fondest dreams: a world where everything is made of whiteboard material.  Imagine being able to draw on the walls and doors and tables!  A quick sketch on the dashboard of your car (while safely parked, of course) would be a wonderful thing.  Jotting a note or two in an elevator or on a credenza might be just the thing to get your idea across in a pinch.

Sadly, as you move up the management ladder, the whiteboards diminish.  Cubicle farms and team meeting rooms seem to be covered with whiteboards; management offices tend to have fewer, smaller whiteboards, often hidden behind a wooden panel or a projection screen.  People at every level need to draw; why can’t we have whiteboards everywhere?

As I listened to this song recently, it occurred to me that a younger audience might be puzzled by these unusual lyrics.  What is an “operator?” Why would they be demanding money?  Forty cents for three minutes? How would you pay them? Technology has marched on, leaving language (and old pop hits) behind.

The operator, of course, was a human who helped complete calls.  Before cell phones, people used pay phones to make calls away from home, ponying up spare change to stay on the line.  While the first three minutes might run you a dime (and later, a quarter), subsequent blocks of three minutes could cost a lot more.  To stay on the line, you fed change into the phone.

To the modern ear, this sounds no different from instructions on how to tan your own leather or fashion a thatch roof.  The concepts are so foreign that the words barely make sense.  Yet this song describes things that were commonplace just thirty years ago!

Much of our language is derived from current technology, forming a common cultural base. As the rate of technological change increases, language cannot keep up, stranding all sorts of shared phrases.  While amusing, I think it also creates an ever-wider disconnect between generations, making communication more difficult.

Even in the past ten years, many ideas have simply disappeared.  Back last century, people needed to rewind things.  Now, no modern device requires rewinding.  We’re at the point where nothing spins to make music; how would a 50s DJ describe his world if unable to “spin stacks of wax?” People will soon wonder why we “dial” phones.  I suspect that the number of US citizens that have actually operated a dial telephone is rapidly declining.

In a similar fashion, acronyms continue to shrink, encoding more information in shorter sounds.  During World War II, acronyms started out as concatenated syllables from related words, pronounced as a single word.  “CINCPAC” is the Commander-In-Chief of the Pacific, “CONUS” is the Continental US, and so forth.

By the 1960s, acronyms became individual letters strung together to make words (NASA, ASCII, etc).  This happy state has existed for a while, and no product or process worth its salt is without a clever acronym that forms a related word.

Now we’ve started pronouncing the acronyms for shorthand abbreviations, creating new words. I’ve actually heard people say “lol” and “brb” in running conversation, without a hint of sarcasm.  This is different from traditional acronyms, which typically represent nouns.  Now we are collapsing and pronouncing verb phrases and even whole short sentences.  This cannot be good for general communication.

What to do? Not much, I’m afraid. In between more-frequent trips to Urban Dictionary, I’ll go back to listening to Dr. Hook. They had another hit song that involved getting their picture on the cover of a magazine.  As I understand it, a “magazine” is like an entire web site, printed and bound as a sequence of “pages.”  The “cover” is the first page, and often had a photo on it.  Imagine!