The case for any change of practice is made by identifying the pain points created by the existing design. Specifically, you need to identify what is harder than it should be because of the existing design, what is fragile, what is breaking now, what behaviors can’t be implemented in a simple manner as a direct (or even somewhat indirect) result of the current implementation, or, in some cases, how performance suffers, how much time it takes to bring a new team member up to speed, etc.

Second, working code trumps any arguments about theory or good design. This is true even for bad code, unfortunately. So you’re going to have to provide a better alternative, which means you, as the advocate for better patterns and practices, will need to refactor to tease out a better design. Find a narrow, tracer-bullet style plane through the existing design, and implement a solution that, perhaps, for iteration one, keeps the god object implementation working, but defers actual implementation to the new design. Then write some code that takes advantage of this new design, and show off what you win because of this change, whether it’s performance, maintainability, features, correction of bugs or race conditions, or reduction of cognitive load for the developer.

It’s often a challenge to find a small enough surface area to attack in poorly architected systems, it may take longer than you’d like to deliver some initial value, and the initial payoff may not be that impressive to everybody, but you can also work on finding some advocates of your new approach if you pair on it with team members that are at least slightly sympathetic.

Lamenting the God Object only works when you’re preaching to the choir. It’s a tool for naming a problem, and only works for solving it when you’ve got a receptive audience that’s senior and motivated enough to do something about it. Fixing the God object wins the argument.

Since your immediate concern appears to be executive buy-in, I think you’re best off making a case that replacing this code needs to be a strategic goal and tie those to the business objectives that you’re responsible for. I think you can make a case that you can provide some technical direction by first working on a technical spike on what you think should be done to replace it, preferably involving resources from one or two technical people that have reservations about the current design.

I think you’ve found enough resources to justify your argument; people in such meetings will only pay attention to summary of your research, and they’ll stop listening after you mention two or three corroborating sources. Your focus initially should be in getting buy-off to work the problem you see, not necessarily proving someone else wrong or yourself right. This is a social problem, not a logical one.

In a technology leadership role, you need to tie any of your initiatives to business goals, so the most important thing for making your case to executives is what the work will do for those objectives. Because you’re also considered the “new guy,” you can’t just expect people to throw away their work or expect to rapidly fall in line; you need to build some trust by proving that you can deliver. As a long term concern, in a leadership role, you also need to learn to become focused on results, but not necessarily be attached to the specifics of the outcome. You’re now there to provide strategic direction, remove tactical obstacles from progress by your team, and offer your team mentorship, not win battles of credibility with your own team members.

Making a top-down decision will rarely be credible unless you have some skin in the game; if you are in a similar situation all over again, you should focus more on consensus building within your organization rather than escalating once you feel the situation is out of control.

But considering where you are now, I’d say your best bet is to argue that your approach will bring measurable long-term benefits based on your experience and that it’s in line with the work by well-known practitioners like uncle Bob and co., and that you’d like to spend a few days/weeks leading by example on a narrow refactoring of the highest bang-for-buck aspect, to demonstrate what your view of good design should look like. You’ll need to align whatever your case is to specific business goals beyond your personal preferences, however.

First, you need to present that any measurable organisation need to adopt industry best practices. Saying that “it just works for us!” cannot be measured, neither in time or in resource as it is simply unpredictable. Software engineering is a science as much as any other fields of science, and these concepts have been studied, researched, tested, and documented.

1. the God Object is an anti-pattern which states that

   In software engineering, an anti-pattern (or antipattern) is a pattern
   used in social or business operations or software engineering that may
   be commonly used but is ineffective and/or counterproductive in
   practice.

2. In the Google IO conference of 2009, this subject was partially explained when the MVP pattern was explained. It may not be relevant to the God Object, but may give you some ammo.

3. Also, using this anti-pattern violates the single responsibility principle in object-oriented designs, which states that :

   every class should have a single responsibility, and that
   responsibility should be entirely encapsulated by the class. All its
   services should be narrowly aligned with that responsibility.

4. The Decaying Code blog also talks about this and about it’s solution.

5. We cannot talk about the single responsibility principle without talking about object coupling.

   […] coupling or dependency is the degree to which each program module relies on each one of the other modules.

   Where having a tightly coupled system may cause assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. A higher level of object couping means less cohesion, and vice versa. God objects are a good example of tight coupling as they know more than they should, thus overloads them with responsibility, thus limit greatly code reusability.

6. When designing a complex application, simplicity must come to mind. Big problems must be decomposed into smaller ones, which are easier to manage, test, and document. This is especially true in an object-oriented paradigm.

   With this argument, we do loop back to the anti-pattern argument, but this paradigm is all about patterns, real world object representation and, ultimatly, data encapsulation.

7. You are part right when you say that these “good practices” are more existent in classrooms. However, I do have teaching experiences in college (and some university) and I only saw these principles being taught in universities, especially in engineering faculties. Which is sad. But like any good practice, those who strive to better themselves usually learn some basic design patterns, and eventually understand how to jungle between coupling and cohesion.

   What I usually teach to students is that, it may seem to require more efforts to adopt good programming standards, but it always pay off in the long run. A good example would be someone asking a programmer to write a sorting function. The programmer has two choices; 1) write a quick bubble sort function (less than 5 minutes) that will not be sustainable as the list of elements grow, or 2) write a more complex (aka optimized) sorting algorithm (quick sort, etc.) that will scale better with bigger lists.

Oh here I go, necroing another old question but I’m going to guess you didn’t win this argument and here’s why.

It Sounds Like a Culture Problem

You’re their manager but you can’t replace them and you have to go to your managers in order to get them to do what you believe they should be doing which in this case I assume is to at least knock it off with the god objects moving forward. It sounds to me like a classic case of code mirroring the culture it was born in. In other words the god object is how this company works. Want to make any kind of meaningful change? You’re always going to the same place for it ultimately since all decisions apparently have to be cleared at the top.

Having been privy to multiple failed attempts at legacy code cleanups and code policy changes I am now of the opinion that you cannot fight the culture that made the code possible in the first place when that culture is still firmly entrenched or at the very least, fighting culture is a very hard uphill slog that it’s unlikely anyone could ever pay me enough or give me enough power to feel like it was a worthwhile endeavor that was likely to succeed ever again.

Before there can be change, they have to be motivated to change and unfortunately as programmers who give enough of a damn to read Stack occasionally it’s hard for us to understand that not everybody is motivated by the same stuff. I’ve won plenty of the rational arguments in my experiences but at the end of the day the company suffers intellectually lazy devs for a reason.

Maybe the business concerns have been motivated to think only about tomorrow rather than next week or five years out (an especially frustrating scenario when you’re the child of immigrants from a country that built a seed vault in the Arctic in case of apocalypse). Maybe they’re afraid of change. Maybe they value seniority overly much to the point that the chain of command is meaningless even when they have to hire from the outside to bring in a dev team lead or manager because they recognize nobody on their all-lifer team has grown enough in their time there (or because said lifers don’t want the risk associated with responsibility). Or, and I’ve seen this, perhaps it’s the very real and depressing phenomenon of mediocrity championing itself because it knows deep down inside that it can’t compete with quality and when there’s enough tomfoolery to go around it’s impossible to figure out who to blame when everything regularly goes to pieces.

How do you fight issues that are ultimately rooted in fear or broken metrics for success? I’ll tell you this, it takes a lot more than even a committed quality dev team and you had a lot less than that from the sound it at the time this Q was posted.

In the Not Impossible Event That It’s Not an Intractable Culture Problem…

Now assuming people at the top are very receptive to change, and they’re actually willing to trust you to make it, you really only need to punctuate all of your arguments with money and lost opportunity.

Every time it takes longer to train somebody new up on this ridiculous codebase, every time it takes longer to modify or add a new feature to something, every time it becomes prohibitively difficult to expose endpoints to another system from a company you want to partner with, it is costing money. Lots of freaking money. Most importantly it leaves a window open for a smaller more agile competitor to swoop in, put you in a position where all you can do is react to them far too slowly, and ultimately snatch it all away from you.

Just recognize that a particularly stubborn and stupid culture will maintain the status quo at all costs even if the actual physical roof of the company is in fact on fire because of it.

You could cite some of the most basic OOP principals such as loose coupling and high cohesion. A “God object” sounds like it couples unrelated classes and has low cohesion.

You could always ask Uncle Bob himself.

The thing is, it’s so obvious to people with any sense that once it’s spelled out, it doesn’t need to be re-referenced by a multitude of authors. There need only be one source.

Other terms you might want to start with when looking for sources are:

• SOLID
• Law of Demeter
• Big Ball of Mud

All of these express related concepts that might yield viable reference sources, even though they don’t actually name it as such.

Ultimately though, you’re the boss. The reason for doing it is because you say so, and although to be considered a good manager you really should be prepared to justify your decisions; you’ve done that, and if there is still resistance, the correct course of action is for your team to do as they’re told.

You may want to see guru of the week #84. It’s all about god objects (monoliths) and how they are bad.

Extract:

(Major) It isolates potentially independent functionality inside a
class […] (Minor) It can discourage extending the class with new
functionality […]

How do I prove or disprove “god” objects are wrong?

You Cannot.

This kind of conjecture is not amenable to mathematical proof, and mathematical proof is the only kind of proof that is sound.

Even if you try to replace the emotive word “wrong” with quantifiable measures of the effects of using god objects, you will find that:

1. the available measures are crude,
2. there are few credible studies where those measures have been quantified for code produced by professional programmers
3. there are few if any credible studies where language constructs or design (anti-)patterns have been tied to those measures.

And that is ignoring the issue of deciding when a particular object is a “god” object.

At best, these kinds of study could only demonstrate an empirical correlation. Not a genuine proof.

What you are actually doing is debating the pros and cons of “god” objects with the view to changing other peoples’ opinions … and then your organization’s practice.

Don’t use words like “proof” or the people you are debating with are liable to laugh in your face.

I am not shure if your team is really interested in academic proove that “God objects are wrong”.

From a psychologic point of view your refactoring aproach can be misunderstood as attacking the team-s competence a la: “the team has done a bad job” although the programm is working as expected.

What you really want to do is to cope the negative side effects of “spagetti code” and “God objects”: explodig costs to add new features because of increasing bugs caused by sideeffects.

Beeing very specific and asking questions instead of providing answers may be more helpful:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code