Chapter 2: KICFJS (Keep it Complex For Job Security)

Note from author: Yes, this is a new blog, these posts are from a 'paper' I wrote along with a friend on Cynical development. It was a tongue in cheek attempt at explaining what we see in the real world in our various development experiences. These posts might seem rambling, but basically that's because I cut and past them from a different format.

Having reviewed dozens of code bases for dozens of applications it's amazing how some things can only ever be understood by the original author. This can only be explained by the simple (and easy to pronounce) acronym KICFJS. Put in another way, if your code base is simple enough that anyone can come in, and within a few hours understand the most basic architectural decisions and component interactions, then you could be out of a job in an afternoon. The only way to truly protect yourself is to make decisions that address symptoms. If you're asked to add a field to a form for an entity, then by all means, make it a completely new entity, name it something convoluted, and persist it in a completely different mechanism than the original entity, perhaps relating it through a shared child object or parent. After all, if someone can figure that out in an afternoon, then they deserve your job. Furthermore, you can justify your code by spouting out tremendous technological jargon such as "decorator pattern" and "persistence unit"

Spaghetti code might be a good start but can be accomplished through mere incompetence. To really obfuscate your meaning and thereby achieve immortality (or at least your paycheck) takes more malice and creativity.

First, name your variables things that are actually counter productive, not merely non-descriptive, but actively dissembling.

Second, abuse data types. Need an Integer? Make it a string and cast when necessary. Need a String? Make it a char[]. Need an internationalizable string? Make it a short[]! Virtually everything can be stored in more complex data types.

Maybe you're writing a financial application and it's database. Varchars can hold virtually everything, and random sizes are key! varchar(57) should appear at least once, as a warning, to other Cynical Developers. This will tell them "Don't mess with your code, lest you be doomed to insanity"

If you DO eventually give in, for your own sanity, and use numeric datatypes, under NO circumstances should you use decimal places. That'll just make everyone's lives easier, and we certainly wouldn't want that.