If you follow my writing, you know I typically write a lot on software quality best practices.

In retrospect, this approach was biased towards those who want to improve software quality. I accidentally neglected those who wanted to inject more bugs into a system.

And so, those of you who love defects, let me share with you my number one tip to systematically create a breeding ground for bugs: The God Object.

Warning: This article may be satirical in nature. Please code responsibly.

Find a Sufficiently Complicated Problem

Great! You’ve chosen to infect your codebase with a parasitic growth of complexity that will generate countless hours of important work only you can do (this is pronounced “job security”).

God objects are a great way of generating sufficient complexity that only a developers deeply familiar with them can touch them without daring to invoke the wrath of quality assurance.

The kind of objects I’m talking about become known by names such as Codethulhu, Tormentor of Junior Developers and Quality Assurance Analysts.

But first, they need to solve a problem. I know, we’re in the business of adding complexity and security, not solving business problems. Hear me out, though.

If your code doesn’t solve a unique and critical problem, there’s a risk some future developer may work around it and completely throw it away.

And so, you need to find a type of problem that:

• Demands a high degree of skill and critical thinking to solve
• Cannot be easily understood without investing time to think it through
• Interacts with enough other complex systems and processes to take on some of their complexity
• Has enough potential to grow and expand in complexity as new features are required
• Does not have an easy off the shelf alternative available

If nothing is popping to mind, you could either wait for a new and complex feature to arrive, or you could take a large file from an existing layer of your codebase and expand it. Some types of objects to consider:

• Communications / Web Service Layers
• Custom User Interface Controls
• The Data Access Layer
• Object Serialization / Deserialization Logic
• Common Service (Business Logic) Layers

None of these is as unique as a business problem, however, but all of these work in a pinch if your organization seems to be hesitant to give you a feature large enough for you to expand to Codethulhu scale for whatever reason.

Birthing Codethulhu

Once you identify your opportunity, you are getting to one of the hardest parts of this process. You may need to brace yourself before reading further.

In order for your object to survive and enter the codebase, it has to work. That means, you need to solve or mostly solve whatever problem the business gave you (or you identified) in the first place.

This means you have to buckle in and work. Actually, you likely need to work pretty hard, since large features are harder, and you’re going to be implementing yours by intentionally making a large class that manages the complexity in a single file.

Expanding the Infection

Colossal God Objects don’t just sprout up overnight, however. The kind of terror that we’re talking about takes time and dedication to grow. You don’t have to be intentional about growing them, but it does help.

Remember: as much logic as possible goes into the same class.

If a problem applies to your object, solve it in the object. I’m talking about things like:

• Serialization
• Deserialization
• Data Access
• Validation
• Parsing
• Formatting
• Logging
• Thread Management
• State Management
• Caching
• Web Service Calls

All of these things can be handled in your god object.

Remember this mantra:

Your problem is special and different than other code because the problem it solves is complex. If other code worked on your object, it wouldn’t be as special, so your code needs special customized logic inside of it.

While you’re developing, I recommend only putting a minimal amount of comments in your code. After all, code should be self-documenting, right?

Be sure to take advantage of external libraries and every new language feature available to you – particularly if your coworkers aren’t familiar with or using those features yet.

Nested ternary expressions and regular expressions are surefire ways of ensuring that only exceptional developers can touch a line of code.

Remember: You have only a limited period of time to grow your nascent God Object before other people notice it and begin to ask questions, so use this time well to achieve a critical degree of size and complexity.

Defending Codethulhu in its Infancy

When challenged on creating a large and complex class, claim that it follows the single responsibility principle (SRP) by solving the business problem in a single file. If other people tell you this isn’t what SRP says, claim to be late for a meeting and run off suddenly.

If people continue to challenge you, it’s time to crank up the attitude.

Act insulted and offended, then demand that they explain the full complexity of the problem you’re solving on the spot. If they fail to describe the problem or its solution adequately, point that out and terminate the conversation. If they actually do get it right, look for technicalities and things they didn’t mention. Things like validation, persistence, threading, obscure edge cases, etc.

On the topic of threading, you can get away with a lot if you claim your complexity is structured in a way that improves performance (bonus points if this is actually true).

When people say that they require doing a full code review on your code, this is a trap. Say that your schedule is too tight to allow for that and that code review is only for bad developers. Your code is good and they should know this because they hired you and you continue to solve critical problems.

If people continue to give you issues about the code, it can be a good tactic to give another developer a chance to work on the class without assistance and fail horribly, only for you to swoop in and save the day.

Finally, if your object still attracts the ire of other developers, you could potentially rename it to something ending in the word Facade, Controller, or Service as people seem to have no issues with classes like this growing larger and larger over time.

Meet Chaos, AKA Job Security

Sooner or later, your God Object will unleash chaos upon quality assurance, your fellow developers, and potentially production.

Don’t worry, this is normal.

Like the jelly of the month club, God Objects are the gift that keeps on giving.

Sure, some of the work coming your way from these objects will be extremely complex and potentially urgent, but the work is coming your way, which is what you wanted.

You’ve established a reputation as the only one capable of handling the complex state management, threading, and order of operations issues present in Codethulhu and so you are tied to its fate.

Hopefully by this point Codethulhu is vital to the business’ continued operation, otherwise you and it may be out on the street by next week.

If Codethulhu has become entrenched, congratulations on your well earned self-made tenure. Sure you won’t be able to be promoted due to the organization’s fear that nobody will be able to maintain the beast aside from you, but that’s a small price to be paid for job security.

Just watch out for any crusading architect or anyone who has read or written anything with the word refactoring in it in the last month.

Beware those Who Can Slay Codethulhu

Every so often, some knight in shining armor will ride along and try to slay your monster. Typically this is fine, as Codethulhu devours the sanity of lesser developers.

However, sometimes the right sort of person comes along with a mix of knowledge of software architecture and patterns, a desire to “improve” the codebase, and the skill and sheer force of will to pull it off.

When this happens, it’s very bad and you should start looking for an escape hatch.

Typically this person will yell and preach to the development organization about refactoring code to common patterns, the Single Responsibility Principle (SRP), extracting helper classes, favoring composition over inheritance, and other such nonsense.

They may have books on their desk or shelves such as:

• Working Effectively with Legacy Code, by Michael Feathers
• Refactoring, by Martin Fowler
• Test Driven Development, by Kent Beck
• Clean Code, by Robert C Martin
• Software Design X-Rays, by Adam Tornhill

Watch for them to successfully modify Codethulhu or worse, put tests around it. If these things happen, it’s probably time to look for another organization in need of a new God object.

This was a Joke

So, as it turns out, this article was satirical.

Nonetheless, some of this hit close to home to some mistakes I made early on in my career.

I was working on a complex and non-standard user interface control for a Windows desktop application. I was 6 months into my professional career, but had already been coding for about 15 years or so at that point.

Over the course of a quarter, I made an incredibly complex user interface control class that managed (among other things):

• Animation
• Selection
• Focus
• Data Virtualization
• UI Virtualization
• Event Propagation
• Keyboard Navigation

With each new release we’d add things it needed to do and so the class grew larger until it hit nearly 4,000 lines of code in a single file.

The features inevitably started colliding with each other and before we knew it, we had a God Object on our hands that owned our codebase and led to chaotic and unpredictable bugs that were hard to replicate and fix.

Slaying Codethulhu

Most people aren’t going to get into a God Object scenario intentionally, but if you do, all is not lost.

Here are a few high level ideas to help you get out:

• The Single Responsibility Principle is your friend. If you keep this in mind when developing a class or a method, you will avoid this anti-pattern by default.
• Extracting logic to helper classes helps simplify code by moving non-core responsibilities off to other objects.
• Put as many pinning tests in place as possible before making any modifications to the class. You want to capture current behavior and explicitly know if it is changing.
• Don’t be afraid to communicate technical debt to management and discuss your concerns over the current codebase. They’ll likely appreciate the honesty and openness and want updates on mitigation of the risky code.

Good luck, and may Codethulhu never haunt your codebase.

Cover Photo by Yosh Ginsu on Unsplash

The post God Objects: How to Summon Codethulhu appeared first on Kill All Defects.