Originally published in Intranet Journal (04-Oct-2004)
In July, I wrote a feature discussing how developers and content owners can increase their chances of selling an intranet to "old-school" users—those who, regardless of age and experience, are afraid of change and least comfortable with the adoption of new technologies. While the majority of the feedback I received on that piece was very positive, there was a small handful of readers who seemed to have missed the point entirely and saw it as an argument for the blind acceptance of all new technology—but this isn't the case.
That article was meant to warn against the inability, or outright refusal, to adapt to new corporate technology standards to the point where some employees end up with outdated skill-sets, making it increasingly difficult to do their jobs. But the solution to this type of technological immobility doesn't automatically translate to a blind faith acceptance of the "bleeding edge"—technology that's so new and untested that developers risk system integrity by using it.
You want to make sure that your systems have a certain amount of longevity—prolonging system lifecycle, avoiding the risk of obsolescence, and maximizing your return on investment—by making use of current technologies while not hastily chasing bleeding-edge promises of some sort of high-tech eden.
Users should stop seeing technology at both ends of the extreme; it's a granular, not an all or nothing, approach. And when it comes to technology, non-action is just as dangerous as blind action. It's our job, as IT professionals, to understand our users' needs and then determine what technology to implement, how much of it, and when it's appropriate to do so. After all, technology—for all it's done to improve our business processes—still requires a good amount of old-fashion human judgment and common sense.
In this article, a follow-up to the July feature, I'll flip the coin and focus on the dangers of following bleeding-edge technology and allowing your intranet to fall prey to a bloated featureset.
Technology has been integrated into our normal everyday business lives so much that some of us have unknowingly blurred the line separating it from the process. But these processes existed long before the introduction of the thousands of new software tools on the market today. What a lot of people seem to forget is that technology is merely a facilitator, a tool we use to make our processes more efficient. It should never be mistaken with the process itself.
Take this as an example: The technological invention of the airplane has made the process of getting from New York City to Los Angeles much quicker. Of course, the need to travel between the two existed long before the airplane—perhaps travellers sat for days inside a stuffy steam train. But no one in their right mind would ever confuse the journey with the airplane. The airplane is a tool, a means by which to get from Point A to Point B. You wouldn't sit in an airplane simply for the sake of sitting in an airplane, would you?
Similarly, you should never implement new technology simply for the sake of technology—it needs to serve a purpose and shouldn't be allowed to dictate your business (unless, of course, your business is technology). Technology and process are interdependent components of a single solution. And like all things, there needs to be a balance. The key is to find a technology that suits your business processes, not to bend those processes or add unnecessary features in order to experiment with new technology.
Unfortunately, many people I speak and work with view technology as both the cancer and the cure. While it's true that technology has made old processes much more efficient and given us the ability to do things we never thought possible, untested, bloated, and overly complicated technology has left a sour taste in users' mouths. They wow at technology's advances just as much as they lament, "Why can't I just get it to do what it's supposed to?"
Those not used to the speed of technology seem to feel as though they're at the mercy of some silicon god, constantly inundated with advertisements, articles, and books describing the newest trends. It's easy to see how they can become overwhelmed by this information.
But this struggle to reconcile the true purpose of technology hasn't really been helped by overly eager developers who haphazardly implement untested, bleeding-edge technology because some IT analyst said that it will be the next big thing. This type of experiment-driven "progress" is usually at the expense of the user community.
There's always going to be something newer, something faster, something bigger; it's a never ending chase—but only if you allow it to be. IT developers needs to know when to stop chasing or nothing will ever get done.
It takes a great deal of discipline to consciously distinguish between what's required and what's desired. Users need to be able to search their primary intranet database of client information and have the results sortable by name, location, and project association; it would be nice if these results could be exported into a MS-Access database so that the data can be used to produce cosmetically friendly reports.
It's the same principle behind never going grocery shopping when you have a case of the munchies—because if you do, you'll most likely end up with a cart full of beer and Ho-Hos. But this is really a matter of interpretation: one person's necessity is another's extravagance.
This distinction between need and want—sometimes a matter of controversy depending on who you ask—must be made during the requirements gathering stage of an intranet project, and agreed upon by the developers and content owners. Failure to do so will put your intranet at risk of being overtaken by runaway technology and a bloated featureset.
Here are some tips to help prevent your intranet from being a victim of its own technology:
It's a phenomenon known by many names—creeping featuritis, requirements creep, feature creep, creeping elegance—and occurs when a system's featureset grows beyond what was originally planned. It can be caused by users' growing wish lists or overzealous developers' attempts to "improve" upon a system when they learn of newer technologies and techniques. It's a movie we have all seen at one point or another; the characters and setting may be different, but the plot is always the same. For me, the story plays out as "The Attack of the Killer WIBNI."
WIBNI (Wouldn't It Be Nice If), a term coined at Bell Labs to represent features (some would say superficial and unnecessary features) that are constantly dreamed up and added to a original system specs. Wouldn't it be nice if we could put dynamic Flash-driven menus instead of static ones; wouldn't it be nice if the search results were automatically formatted for printable reports; wouldn't it be nice if the system was able to spit out an espresso while I surf. The list of system WIBNIs can be as infinite as your imagination.
The only way to tame this WIBNI monster is to follow a formal set of project specs and stick to them regardless of any desire to tack on more flashy gadgets.
System specs provide developers with a concrete framework in which to work with. If WIBNIs are constantly added, your project will never get done. Any time progress is made, the finish line would be moved as well—like a rabbit chasing a carrot dangling in front of it from a fishing rod attached to its back. This will not only wreak havoc on scheduled deliverables and milestones, it also creates an incongruous patchwork of system features.
Post-spec WIBNIs—and feature creep, in general—are notorious for delaying project deliverables. Rather than feeding the beast with endless features, consider them something that can be added in future versions of the system.
But if additional features not originally specified in system specs are truly required (i.e., not trivial WIBNIs), make sure:
With all this discussion of technology, what everyone needs to remember is that at the other end of technology are human beings who must use it. You can pack tons of technological ammunition into a system but if it does nothing to make the lives of your users easier, it's useless.
It's sad to see that the advancement of all things high-tech seem to have dehumanized the workplace when we should, in fact, be placing even more emphasis on the people using the products because of such advancements in technology.
We need to always be aware that we're developing for people, not developing for technology. But it's an unfortunate trend in system development where developers feel the need to pack in as many features into a product as possible just because the technology allows them to do so. This is precisely why the market is swamped with so much bloatware—software that's so feature-laden that it not only taxes hardware requirements, but also makes it overly complicated and almost unusable for regular end-users.
Simplicity and user-friendly software is often the key to productivity. Just because technology allows developers to do more doesn't mean they're obligated to do so. It's unfair to expect users to constantly have to adjust to the frequent changes in technology. Don't, for example, redo or replace a system that was only rolled out onto the production environment several months ago (unless there are serious deficiencies with the original system) because a newer technology arises.
Bottom line: If it doesn't help the users, don't do it.
Bleeding edge technology is a vicious cycle; those trying to gain control of technology are also the ones feeding the problem. In their attempts to keep pace with new technology, developers are sometimes forced to use production systems as a live experiment for lack of a practical alternative.
Perhaps they find it difficult to justify the expense of a dedicated development environment because there's little to show management in terms of immediate returns. But R&D shouldn't be viewed upon as a luxury; it's essential in keeping the bleeding edge from seeping into live, production systems—an environment not suitable to open experimentation.
Development and production must remain two separate entities because new technology requires a period of testing—or as I like to call it "gestation"—in a controlled environment to ensure stability and technological maturity before being released for company-wide usage. Using a production system to facilitate this need places the unwanted burden of being guinea pigs on users who are just trying to do their jobs with the tools provided to them by IT. And you don't want this relationship to turn into one where users harbor resentment toward IT and everything that comes from them.
There are far too many users, both in and out of IT, who feel as though they're slaves to the trends in technology—but they don't have to be. There is such a thing as technological freewill! What we all need to achieve is a balance between keeping pace with technology so that we don't fall behind while maintaining enough caution and good sense not to prematurely adopt bleeding edge technology.
I hope users and developers begin to see technology beyond both ends of the extreme. We have far more options than just standing rigidly still or running full-speed ahead with arms flailing in the air because there's plenty of middle ground for a nice, steady stroll.
Copyright © 2004 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.