Monday, September 1, 2008

How to create unmaintainable systems

Several years ago, an article appeared entitled "How to write unmaintainable code." It is a very funny look at ourselves, because we have all used some of the techniques outlined in the piece. My personal favorite is:

"Exceptions are a pain in the behind. Properly-written code never fails, so exceptions are actually unnecessary. Don't waste time on them. Subclassing exceptions is for incompetents who know their code will fail. You can greatly simplify your program by having only a single try/catch in the entire application (in main) that calls System.exit(). Just stick a perfectly standard set of throws on every method header whether they could throw any exceptions or not."

I'm not going to revisit unmaintainable code, but I'd like to discuss building systems in an enterprise, and how "programmers in a box" struggle with the transition to corporate development. So here are my top picks for how to create systems that are unsupportable and unmaintainable in an enterprise. Of course, if you start with unmaintainable code, then delivering an unmaintainable system should be child's play.

Use whatever programming language you want:
Is Java the corporate standard for distributed development? Sure, but some .Net programming will pad your personal resume. What the heck, might as well write a .Net application using both VB.Net and C#, then you can throw your code into Visual SourceSafe even though there is no corporate support, no way to get your code to production (legitimately) and of course, SourceSafe doesn't always lose your code. Then for burps and giggles you can test your application using the embedded Microsoft test suite, even though the corporation has paid (significantly) for an enterprise testing solution, built a centralized testing Center of Excellence, and established a professional testing governance program - but what the hey, you're personal reputation is more important than all that.

Join the Scripting Language of the Month Club:
Scripting languages are notoriously easy use; and equally difficult to debug or maintain. Each contains some nuance or speciality that makes them ideally suited for a specific task, but generally not good for anything. They tend to have no formal structure, use cryptic syntax, and sprout up as frequently as spam. So, first of all use a scripting language, even when a more structured language is available. Secondly, take the time (at work) to become a certified script kiddie in JavaScript, ECMAScript, Groovy, Python, Jython, JRuby, ANT, Perl, PHP, Rexx, Kixtart, DOS Batch, UNIX Script, TCL, Pike, and VBScript so that no one can ever predict what language you'll use next, what VM needs to be installed on the servers, what version of the VM, or who you are (because you'll never include an Author tag in the source file). Lastly, make sure to call scripts in one language by scripts written others. Oh, and lest we forget, breed lots of confusion and dissent by blithering on about how your new script du jour is better than yesterday's legacy hack and how out of touch the company is, and there's never any training, and what a bunch of morons you work for.

Assume you'll be the only person who will ever look at the code:
Hey, at the moment you wrote the code (or downloaded it) you kind of, more or less, understood it - so there no need to insert any commentary about what is does or why. Besides, the code is self documenting to any quasi literate programmer with half of your underpaid, overworked skill. Afterall, its not like you hack code like the last dufus whose program you had to maintain. If only that guy had taken the time to insert a few meaningful comments. No, your code is different, it is simple, except where it isn't. It is bullet proof and will never need to be modified. Ever. By anyone. Even you. Ever.

Assume you're the first programmer that ever existed:
Every time you're handed an assignment, whether it's related to the human interface, the database, security, or business logic, assume that no one has ever been given this or any similar assignment and start coding from scratch. Furthermore, assume your code will be the end of this requirement for all time. No one will ever think to reuse it, so there's no need to document it, or to , gasp, make it abstract! No, make sure that the inner workings of the code have no interfaces, everything is 'final' and for heaven's sake do not package it up for export. Don't even think about a web service.

This cannot be the end-all on this topic, so I'd like to hear your thoughts on developing unmaintainable systems in a corporate enterprise.

No comments:

Post a Comment

Follow by Email