paulchinonline.com

Going to the Dark Side: The Dangers of Renegade Development

By Paul Chin

Originally published in Intranet Journal (16-May-2005)

back back to portfolio


This summer millions of people will flock to theaters to watch the once innocent Anakin Skywalker turn his back on the powerful and spiritual leaders of the Jedi Order to high-five and drink cheap beer with the dark side of The Force. In this final installment of the Star Wars series we will find the answer to the question that's been on everyone's mind: Why did Anakin make that transformation from Jedi—heralded as the "chosen one" by his mentor Obi-Wan Kenobi—to the walking tin can we all fear as Darth Vader?

In April, I wrote a piece about the side effects that unofficial sites and applications can have not only on an intranet but an organization's entire IT infrastructure. I discussed the problems associated with renegade development—non-sanctioned development done outside official IT channels—and why it's dangerous to allow it to go unchecked. Shortly after that piece ran, I received a number of e-mail messages from self-confessed renegade developers who were more than happy to share their own personal war stories and why they took matters into their own hands. Some did it out of developmental curiosity, some did it because they tried to go the official route and were not able to accomplish anything, and some did it because they simply had no other choice.

What can intranet owners do to prevent skilled non-IT developers from answering the siren song of the dark side and becoming full-fledged renegade developers?


When Good Developers Go Bad

Long ago, in a galaxy far, far away, information systems were created by a small number of highly skilled programmers. They wrote applications in archaic languages that sat on huge mainframe computers—but not anymore. Today, as average computer users become more technically inclined and development tools become easier to acquire and use, non-IT developers have entered the arena of program development. The nature of this fast-paced, technical culture calls for applications to be put into place as quickly as possible—and by any means. Applications can result from:

Gone are the days when applications only came from a closely knit group of knowledgeable Jedi knights. Now, new applications can be brought to life by anyone able to wield a light saber. But with this power comes danger. Without proper guidance, these non-IT developers can fall prey to the influences of the dark side: Renegade development.

Renegade development can be defined as the implementation of any substantial application built by non-IT affiliated developers outside of official IT standards and infrastructure. It takes place when there's an application requirement within the renegade developer's department or workgroup and is fulfilled internally with little-to-no knowledge, influence, or involvement from IT.

The good news is that renegade developers are not as sinister as those dreaded fiends from the dark side. They can't crush your larynx with a wave of the hand or make you bark like a dog just by looking at you. In my experience, renegade developers don't intentionally go looking to break official IT development standards. They don't necessarily go looking for trouble; unfortunately for all involved, that's where it often leads.

But it's a little unfair to lump all non-IT developers into a single group. There are really two distinct types: First, there are those who knowingly and blatantly disregard IT and its established development standards. Second, there are those forced into renegade development because they have no other choice.

The first type is the toughest to convince that working with, rather than against, IT is in everyone's best interest. They're the ones with the hacker mentality and view IT as an unnecessary barrier to their goals, exhibiting an "I can do this without them" attitude. These developers don't work within IT's development environment and view the organization's established standards as a restriction. Rather than working with IT to build a solution, they skirt the issue and go underground, placing their need for developmental autonomy over the long-term welfare of the application and the users it's meant to support.

The second type, however, became renegade developers not by choice but because they were driven to it by past bad experiences with IT, long delays and turnaround time for system delivery, or IT teams who were unreceptive to their ideas. The irony with these types of developers is that IT—the harshest critics of non-sanctioned development—itself is the root cause of the problem. How can IT expect non-IT developers to wait idly by for much needed applications within their department and not take matters into their own hands when they have been stymied so many times in the past by going through proper channels? IT needs to look closely at themselves to see if they're contributing to the problem they're trying so hard to eliminate.


Why Renegade Development is Dangerous

The modus operandi of the renegade developer is to find the solution to a problem within their department or group as quickly as possible with whatever tools they're familiar with and are at their disposal. This not only breaks an organization's established standards but also undermines the entire development and system infrastructure set up by IT.

The problem with many renegade developers is that they operate with blinders on, seeing only to the needs of their users in the here and now. While their intentions are good and their on-the-fly solution may meet users' immediate requirements, they're actually risking the longevity of their application and putting users on very shaky ground by not involving IT in the development process.

It's very risky for users of renegade applications to put all of their faith on a system maintained by a small group—in some cases a single person—within their department rather than a larger governing body such as IT. Aside from all of the technical issues, system ownership will play a big part in defining the long-term life of any application developed without any IT involvement.

All it takes is for the application author to leave the department or company and users, as well as IT, will be left to deal with an orphaned application that no one wants to take ownership of. The users, many of whom may not be as technically inclined as the application's author, will not have the know-how to take over the responsibility. And IT will not want to deal with it if it's in contravention with the established infrastructure (see "Guilt by Association: Effects of Unofficial Sites and Applications" for more on the implications of orphaned applications).

Development standards are established for a reason. Whether to ease application maintenance or reduce total cost of ownership, standards are required to keep development and the resulting applications from turning an organization's IT infrastructure into smörgasbord of unrelated and unstructured systems.

Renegade applications raise many concerns for IT teams responsible for maintaining overall IT integrity because they:


Preventing Renegade Development Requires a Change in Attitude

My goal here isn't to imply that all development must be done by IT developers. The number of business requirements and application requests will almost always outnumber IT developers and resources. If IT has the luxury of working with knowledgeable and skilled non-IT affiliated developers it should take advantage of this opportunity. Otherwise, if ignored, these non-IT developers—many of whom have valid application requirements—will go rogue and become renegades operating under cover of darkness.

Many of the e-mails I received cited lack of IT response as the biggest contributing factor in their transformation from promising non-IT developers working in cooperation with IT to covert renegade developers. They tried going through the proper development channels only to hit a wall when confronted by overly territorial IT teams unwilling to listen to their suggestions. This type of attitude toward an organization's non-IT developers only goes to fuel the caricature of the high-and-mighty IT department that thinks it always knows what's best for everyone. Not only is this counterproductive, but it will drive non-IT developers right into the welcoming arms of the dark side. And once they make that jump and adopt a "no IT, no headaches" mentality it will be near impossible to bring them back.

In order to eliminate, or at least minimize the impact of, renegade development a fundamental change in attitude and approach must take place on both sides:

A Message for Non-IT Developers

For your part, you must understand that IT is responsible for the entire organization, and that it's unrealistic to expect instant gratification when your requests are made. IT probably has a very long to-do list and only a limited staff. Proposals for new features or applications are usually placed into a prioritized queue—if they can be done at all—so a reasonable amount of patience should be afforded to them whenever possible.

However, a far greater concern will be when official IT development teams won't even hear out your proposals, choosing instead to take a "stay off our turf" approach. To combat this, you should never make your proposals to them by yourself. More often than not, IT will look upon these types of requests as non-IT developers with itchy trigger fingers trying to make busy work for themselves. IT is usually much more receptive to suggestions that come directly from a group of users rather than a single would-be developer.

Your best chance of getting IT to accept your proposal is by presenting it to key members within your own department first (or whoever your users will be) such as group leaders and managers—the higher up the ladder, the better—and having them initiate the development process with you. This will hold much more weight than trying to go it alone since it's coming straight from users' mouths. If your proposal is accepted, your involvement in the actual development may vary from acting as a key point of contact between your users and IT to being a full developer "subcontracted" to work under the auspices of IT.


A Message for Official IT Developers

As mentioned earlier, you need to take a good look at yourselves to determine whether you're giving non-IT developers a reason to go renegade. Non-IT developers are not deliberately trying to usurp IT; they're merely trying to get applications out to their users. In some cases they're under extreme pressure from management to get it done any way possible. And if you don't provide them with the support they need, they will eventually be forced to take matters into their own hands—and then you'll only have yourselves to blame.

This isn't about territory. You need to have the foresight to see that working with non-IT developers will reduce the many headaches associated with the adoption of orphaned applications built completely outside of IT—big or small. In cases where you're unable to do they actual development yourselves, don't abandon them with an insincere "we'll look into it later" knowing full well that "later" means "never." If non-IT developers have the knowledge and ability to take on the development themselves, help them define the proper development parameters so that when it's done, their application can be easily integrated into the existing infrastructure.

The choice is yours: Help non-IT developers build an application within the confines of your established development infrastructure or ignore them and risk them going renegade.


Closing Thoughts

Renegade development is one of those strange problems that feeds itself: IT guards its territory fiercely so non-sanctioned applications won't threaten the organization's infrastructure, but in doing so they end up driving non-IT developers into seeking alternative solutions. Non-IT developers do this because they just don't want to have to deal with a troublesome IT department that won't take them seriously. And after having been turned around so many times in the past by unreceptive IT teams, they will eventually look to eliminate the middleman.

Maintaining corporate development standards doesn't mean restricting all development to official IT developers—this is not always possible. The true key to maintaining corporate development standards is for IT to provide support and guidance for non-IT developers when there's no other choice but to allow them to take the reins of development. If they are to follow development standards, it's IT's responsibility to help them do so.

The other option for IT is to ignore them, but that's a very dangerous attitude. Yes, they will go away—but only for a while. Then one day, out of the darkness will emerge a shadowy figure cloaked in black and accompanied by two menacing things: the mechanized sound of heavy breathing, and an application no one has ever seen before.


Copyright © 2005 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.