Skip to main content
October 17, 2013

Totally Unmanageable Code In 8 Easy Steps

Application development is really important, but rarely funny. This developer’s list of simple steps to make your application code totally unmanageable is the exception.


Application programming is really important, but it’s rarely very funny. Software developers are the freemasons of the digital age. And that makes application development … well … masonry. And that’s not typically the stuff of the late night talk shows.

But every once and a while, someone who’s both smart and funny and in the know nails it. The latest is Greg Jorgensen, a freelance software developer who writes the blog “Typical Programmer.” Jorgensen describes his work as taking on “technical debt…I specialize in debugging, fixing, maintaining, and extending legacy software systems.”

greg-jorgensonGreg’s typical gig is pretty familiar to anyone who has worked as a developer or QA professional in the technology field at any time in the last three decades.

“My typical client has a web site or internal application that works, more or less, but the original developer isn’t available. Business requirements have changed and the software hasn’t kept up.” Or, “my client has something that is ‘almost finished’ but they parted ways with the developer after using up their budget and schedule. Usually there’s a list of missing features and bugs.”

Rather than rail on about the poor state of application development, Jorgensen puts a happy spin on it: all that crappy code translates into job security for him and others like him. To make it all easy, Glen put together a list of simple steps that any organization can follow to code themselves into a corner and end up calling someone like Greg in to clean up the mess.

At the top of the list: version control. Ditch it, Jorgensen urges. That way “the next programmer to come along has to figure out which files are part of the current system and which are obsolete or backups,” without the benefit of “commit messages or change logs to get the code’s history from.” Add a couple zeros to the work estimate just for that one.

And developers should make sure to “throw in as much third-party code as you can.” “I’ve seen code depend on large external libraries just to get access to one function,” he writes. For an extra bonus: developers should modify those shared components so that they can’t easily be updated when newer versions become available. Then neglect to document all the dependencies so that the inevitable update just breaks the app, and nobody knows why. Reckless use- and modification of shared libraries will have the consultants charged with cleaning up your mess seeing dollar signs.

That isn’t to say that “rolling your own” isn’t just as good a way to make sure Greg’s kids get their teeth straightened. “Don’t bother with a well-understood framework like Django, Rails, or CakePHP,” Jorgensen urges. “You can write a better templating engine, ORM, sort or hashing algorithm.”

The truth is that developers who think they’re ‘too cool for school’ and insist reinventing the wheel, or moshing together components written in a Babel of “cool” programming languages are great for business.

“Half-baked caching, aborted Rails and Node.js projects, and especially NoSQL solutions (“It’s more scaleable!”) are my bread and butter,” he says.

I’ll let you to read the full list on Greg’s blog – it’s worth it. Also worth reading are the comments that accompany the article on Greg’s blog and developer watering hole sites like Slashdot.

The picture that emerges from these is that application development is an amazingly complex and very human activity. Creating an application these days is more akin to writing a novel by committee than, say, assembling a desk from Ikea. And that means the list of possible faults or problems is as unbounded as the personalities of the individuals working on the project.

Still, some common themes emerge about best practices from Jorgensen’s tongue in cheek post and from others like it.

  • Document everything – even the stuff you think should be obvious.
  • KISS (Keep It Simple Stupid). Where solid and proven third party frameworks or shared components exist, use them. Or, if you’re going to roll your own, have a darned good reason for doing so.
  • Don’t assume anything about who will be maintaining your code two, five or 10 years hence. Don’t assume that you know what their development environment will look like, or the level of expertise they will have. If you can get that person to understand how to get your code to work, how it works, how best to modify it and what dependencies exist, you’ve gone some distance towards putting guys like Greg out of business.

Related Content

Paul Roberts is an experienced technology writer and editor that has spent the last decade covering hacking, cyber threats, and information technology security, including senior positions as a writer, editor and industry analyst. His work has appeared on NPR’s Marketplace Tech Report, The Boston Globe,, Fortune Small Business, as well as ZDNet, Computerworld, InfoWorld, eWeek, CIO , CSO and He was, yes, a guest on The Oprah Show — but that’s a long story. You can follow Paul on Twitter here or visit his website The Security Ledger.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.