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.
Top comments (6)
Well i like the satirical tone of the article. I am sure everyone have had written a God object sometime in their career. But like you said once you realize it can always be broken down and improvised. Thanks for sharing the book names will read when i can.
sometimes, those kind of projects spawn by themselves and they are indeed defined to be of such insane complexity right from the first spec. I am nearly 12 years into my professional career and 1.5 years ago I was given the task to create a
thing(which is multiple things, micro services) that consumes data from (no exaggeration) 15 different systems, find a way to combine the data (when possible) and createAreport system. It follows every good practise that there is out there and its not hard to understand from a code perspective (you need to be familiar with several code patterns).I work in telco. Its insane how many names exist for the same concept between different systems... figuring out things usually involves reading huge manuals and talking to many teams. So this project now has such a huge documentation that no new developer wants or has time to go through it.
I don't hate the system, but the thing I hate is that, I am afraid, when the time comes to move on... handing it over would be nearly impossible.
New developers say that the code needs to be self explanatory instead of having links to big pieces of documentation. I totally agree with them but unfortunately no system consumed was designed to be compatible with each other, so some complex mappings are unfortunate but necessary.
I'm feeling the pain of a god object I wrote about 2 years ago right now. It's a shame it's a learning curve we all have to pass through at some point.
The article made me chuckle, great writing as always Matt :)
OMG! I know places where this article would pass as a "best practice" - if you would just delete the disclaimer, and the last notes....
It amazes me that there are many organizations out there that actually promote this kind of behavior!
Reminds me of the classic satire piece: How To Write Unmaintainable Code (PDF) by Roedy Green.
Funny that I stumbled on this as I am currently slaying a Codethulhu. At first it looked like it might of been the work of a genius, a single class that fully and absolutely handled all of the processing of files.
One section, 200 lines of code, all for checking if a value in a db field is some form of blank, then making sure that it was the correct value of blank for the given field type, for no other reason than making sure it was the correct type of blank coming out of the db, took me a day to divine that... Delete it... Test that yep it essentially did nothing for the processing of files.
Starting to think this kind of genius was actually an idiot.