Protected page

Workaround-oriented programming

From Uncyclopedia, the content-free encyclopedia
(Redirected from Ariane 5)
Jump to navigation Jump to search
Reusing old code – a common practice among workaround-oriented programmers – is known for a few detrimental side-effects, such as having caused this rocket to explode.

Workaround-oriented programming (WOP) is a programming paradigm that uses "workarounds" – quick, inelegant fixes for every little problem – as its defining feature. Unlike most programming paradigms, instead of its style and methodology centring around the utilisation of particular structures within a given category of languages, WOP is much more flexible; the sole defining feature is the fact that the workaround-oriented programmer usually does not in fact know what any of the structures within the given language are. Thus, instead of following the usual abstractions or following established patterns, the programmer will make up and search out new and exciting workarounds for everything, effectively 'reinventing the wheel' at every step, usually using Google or by asking more technically-savvy acquaintances how to implement seemingly random pieces of code that seemed like they might help solve whatever problem was a pressing concern at the time.

As a result, workaround-oriented solutions will typically comprise of a plethora of smaller workarounds all working together to comprise a larger workaround that, while slow, excessively large and/or needlessly complicated for the intended function, works perfectly. Except when it doesn't. Eventually, however, even the most elaborate solutions will fail as whatever the programming was intended to control will finally exceed the capacity of one of the smaller workarounds, at which point examination reveals nothing more than an incoherent jumble of punctuation. Fortunately, there are workarounds for this as well.

Overview

Many people learn to program in a workaround-oriented environment; in the modern world of busy lifestyles and rampant commerce, quick fixes are often what comes most naturally. Leaving learning the patterns and basics of computer science in general to the academics and the nuances of particular languages as relics of another age, it is often much faster and easier to simply look up what each piece does as one comes to it. Need to print something? Search for an example and copy what seem to be the relevant bits. Perform a calculation? Look up an algorithm. Meanwhile the application becomes more and more elaborate, yet the workaround-oriented programmer gleans almost no overall comprehension of what he is actually doing; none is required for any of it.

This tree is analogous to what can happen if a workaround-oriented solution is allowed to fester for too long; the system grows around it and becomes impossible to remove.

But it doesn't matter. To the workaround-oriented programmer, elegance, readability, or future usefulness are not an issue, so long as the software serves its purpose now. Thus the employer sees what was commissioned now, the employee gets paid now, and the problem is solved for now, and the company can then move onto the next project; efficiency is maximised.

This is not unlike the notion of a car with a poorly-secured engine block with a penchant for falling out at all the wrong moments. A workaround-oriented solution, instead of taking the vehicle into shop to get the block professionally secured, would simply involve duct tape, twine, several bottles of superglue, and perhaps some of the sticky stuff the kids left on the floor of the van. Much faster, much cheaper, and the engine stays put for only a fraction of the effort. The superglue may eventually cake after repeated implementations, but it does stick to itself remarkably well.

Likewise, WOP will be faster, cheaper and function well for the time being, and even when it invariably breaks down, further workarounds will resolve this simply enough. These subsequent workarounds will also make the system nigh impossible to approach through more standard means due to to all the needless smaller workarounds rendering the system much more secure from malicious and friendly queries alike. This added security is fortunate, as WOP does not govern so mundane of objects as the engine block of a car; it governs the creation, implementation and maintenance of the software that can control anything from online banking to rockets to Wikia's security system.

Design patterns

Like this cat, workaround-oriented programmers would much rather sleep than code – which explains not only the origin of most problems inherent in WOP but the origin of the thing itself.

Unlike most programming methodologies, WOP has existed from even before the dawn of modern computers. Dependent only upon the workarounds themselves, workaround-oriented solutions were common not only in day-to-day practice, but also in the realms of mathematics and physics. Though most scientists would prefer not to admit it, theirs is a field with a rich history of workarounds. Can't explain something? Make something up. Some overly complex explanation to fit the theory, or perhaps some whimsical story to explain it all away. When that fails, however, an even more common workaround was often to simply get drunk. Likewise, modern WOP solutions will also regularly involve getting drunk, which has the unusual effect in programmers of increasing the effectiveness, though not the comprehensibility, of their code.

As programming is little more than the application of algorithms, which in turn are nothing more than specified processes by which to do things, it was not a far leap to apply even the crazier workarounds to the concrete structures of computers and thus to programming. Thus, unlike the computers themselves, WOP has managed to undergo almost no major evolution over recent years. It has proven consistently applicable in any language, regardless of complexity or intent, for the workarounds themselves are as varied as the problems that arise. Twine and superglue and bits of gum may hold an engine together, just as Google searches and forum posts may serve for more typical problems, but just as often the workaround-oriented programmer will have to get much more creative, creating complex applications with only the most minimal of understanding of just what it is he is doing, or perhaps more often, pretending to create complex applications that seem to fulfil the intended purpose, while in fact they are more often effectively empty containers with some pretty interface. Such containers need only fool others and can easily serve to buy the programmer some time so he can fudge the entire thing later, though they often also serve as a distraction so that he gets paid and can then make a hasty exit.

WOP may quite possibly be the most commonly implemented form of programming, and with increased availability of distractions as well as quick fixes, it becomes more commonplace with each generation. As it is inspecific to any particular languages or purposes, it can in fact be applied to pretty much anything, and there is no way to say for certain just what would be the extent of its prevalence.

As it stands, some scientists theorise that there are only ten or so actual programmers creating new, non-workaround-oriented code in the entire world at any given time. The rest are all reusing each other's code and forming it into new and creative wonders, the complexity of which would boggle the mind, if only anyone would willingly go near them.

Potatohead aqua.png
Featured version: 28 February 2011
This article has been featured on the front page. You can vote for or nominate your favourite articles at Uncyclopedia:VFH.Template:FA/28 February 2011Template:FA/2011Template:FQ/28 February 2011Template:FQ/2011