OK, let's get one thing straight! Lazy coding (LC) is good for America, and it's good for India too! You don't need to be a rocket scientist to know this. In fact, it's better if you aren't, because the lazy coding paradigm is not just a "style" of coding but an actual programming model with a sociological impact on the lives of millions. What do I mean? Let's start at the beginning.

What Is LC?

Lazy coding—or LC—rivals extreme programming (XP) as the most popular coding model in use today. In the XP model, two or three programmers sit before a single computer screen working away on a unique project, critiquing each other's work. In the LC model, a lone programmer hunches at his terminal late at night nurturing his contempt for the potential users of his code.

It used to be that software was written for the benefit of users, but no more. LC programmers have wised up to the fact that corporations have little or no respect for their skills and less for the productivity of the people who use their software. How efficiently a particular task might be completed is very low on management's priority list, so—according to LC—it's also less important to the users of the software. Therefore, by extension, the unspoken purpose of creating software has been transformed from enabling productivity to "exercising the hardware"—hardware that has become so cheap that legions of servers line the walls of IT departments.

Why Should Code Be Efficient?

LC answers the epistemological question "Why should code be efficient?" With so much mechanical horsepower at hand, the need for efficiency in coding has become superfluous. Moreover, since corporate IT can no longer afford to hire staff, those who are lucky enough to be employed must now write code to use every available resource, casually and in an unstructured and highly inefficient manner, to justify the existence of the hardware and ensure that they have their own job in the days to follow.

Guidelines for Writing in LC

Considering that the purpose of LC programming is to enable inefficiencies, it's easy to understand why until recently there have been no formal guidelines to working in the LC model. After all, documentation—or more specifically, the lack of documentation—is one of the key factors that activates the core elements of the LC model.

Yet, over the years, I've been able to identify three general traits or rules that seem to uniquely identify the LC model. In test after test, programmers who have followed these rules have succeeded in creating applications that undeniably qualify as LC, so I offer these guidelines for those who are interested in learning the techniques of LC for their own job security.

Rule 1: Squander Everything

Use every programming resource at your disposal as completely, as inefficiently, and as haphazardly as possible. Don't be worried if what you are doing in your code is inappropriate. After all, how many times does your supervisor really peek into your work? Not too often, right? So use your application code as you would use the area beneath your bed at home: a place to hide the things that you really don't want to think about. Waste as much space and resources as possible! Be creative!

For example, if a programming language has the ability to activate 99 indicators, as in the old RPG language model, turn them all on or off, randomly, with no particular purpose in mind. See if you can get the CD player on the user's desktop to suddenly spin! Use every code function you can possibly conceive of to perform the simplest of tasks. Test the limits of your mathematical knowledge whenever possible. Improvise without shame. Who knows? You may get lucky and discover the mysteries of the universe within the confines of your code. But if you do, you don't have to let anyone know. Besides, no one will really care! That's the beauty of the LC model!

Rule 2: Obfuscate Everything

Do not hesitate to create complexity. Structure is the hobgoblin of little minds, so avoid comprehensible structures or universal standards whenever possible. Complexity breeds bugs, and software bugs are good for the software economy.

For instance, documentation within code is an excellent means of leading others astray from the real purpose of the software. Use this conceit whenever possible. Don't hesitate to lie about which functions actually work and which ones will randomly fail. Let the poor dupe who follows you be forced to his own conclusions. And seed the code with completely meaningless comments whenever possible.

The best LC documentation I have ever read was really a programmer's blog about his ex-wife's spending habits at Christmas: 200 lines documenting and complaining about her credit card bills. Of course, this blog had little to do with the actual application code (except perhaps to psychologically explain why the programmer's application was randomly failing to process certain financial transactions), yet it was a perfect LC technique. When this code was transferred to an outsourcing service in India, the Indian programming team spent months trying to decode the meaning of the blog, believing it was some internal corporate compliance document. Remember, great obfuscation leads to great LC documentation!

Rule 3: Alienate Everyone

Never forget that the users of your software are in your complete control. So abuse them whenever possible. Make them sweat by periodically displaying error messages designed to intimidate and worry them.

For instance, if you choose to use error numbers in your error escape routines, make certain that the most critical errors have no documentation at all. Or if documentation is "required" for error codes by your management, make certain that the messages are as obtuse as possible. Such error messages might read "9999,99—Warning! Program failed to do something important! Contact your system administrator immediately."

Another great LC technique is to provide a comprehensive table of contents for all the documentation, but no actual help text within the documentation itself. So, for instance, a user looking up the word "Failures" might find 150 listings for potential failures, each pointing to the same page that says "This page intentionally left blank."

Another useful technique, especially for commercially available software, is to list a URL and/or telephone number for help desk questions. If you list a URL, make certain that it is the homepage of your corporation so that users will be forced to search through the company's entire site for support.

If your company uses FAQs as a support mechanism, reduce the available FAQs to the smallest possible number and then once again hyperlink the answer to the corporate home page.

Finally, if you are required by your management to provide a support telephone number, make certain that the number is one that will overload the corporation's switch board or be queued into a voicemail box that fills to capacity quickly.

The Humanitarian Impact of LC

No doubt you're scratching your head and wondering "Why is this called lazy coding? It sounds like more work than what I'm doing right now!" And, indeed, setting up the functionality of LC does require a bit more work. However, it's definitely worth the effort, and here is the reason.

Corporations have ceased caring about the efficiency of their software application base because modern software has caused a kind of financial amnesia about the true cost of human productivity.

For instance, what used to take 20 people in five departments to accomplish can now be accomplished by a single individual with a PC. In fact, most corporations would prefer a person outsourced in some distant developing country, connected by a telephone line that uses the company's VOIP technology. This modular approach to human productivity has offloaded IT resources so completely that IT can no longer even afford to provide its own personnel for basic help desk functions. These too are commonly outsourced to developing countries.

So the purpose of LC is threefold:

First, it keeps all equipment operating at peak capacity (and inefficiency), enabling IT to maintain its budgetary prerequisites.

Second, it guarantees that the programming jobs within the corporation are protected through lack of documentation, arcane language use, and obfuscated functionality. After all, it's less expensive to keep the existing LC personnel in-house than to hire hundreds of consultants—even consultants in third-world countries—to figure out what the code is doing.

Third, and most importantly, LC feeds the developing world by providing support desk jobs in developing countries where labor is cheap and individuals are grateful for meaningless jobs. Corporations can then easily pin down the impact of supporting LC applications, while providing high-profile service at minimal cost.

All told, LC—as a programming model—is proving to be a viable means of software development. No wonder IBM, Symantec, and a host of other software providers are leaping aboard this new model.

Isn't it about time that your team gave up too?

Thomas M. Stockwell is Editor in Chief of MC Press Online, LP.

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.

 

 

Also Read

IBM i Shops Pivot to Battle COVID-19

Energy, Vibe, and Atmosphere

Murphy’s Security Law