Long story short, I inherited a code base and a development team I am not allowed to replace and the use of God Objects is a big issue. Going forward, I want to have us re-factor things but I am getting push-back from the teams who want to do everything with God Objects "because its easier" and this means I would not be allowed to re-factor. I pushed back citing my years of dev experience, that I'm the new boss who was hired to know these things, etc, and so did the third party offshore companies account sales rep, and this is now at the executive level and my meeting is tomorrow and I want to go in with a lot of technical ammo to advocate best practices because I feel it will be cheaper in the long run (And I personally feel that is what the third party is worried about) for the company.

My issue is from a technical level, I know its good long term but I'm having trouble with the ultra short term and 6 months term, and while its something I "know" I cant prove it with references and cited resources outside of one person (Robert C. Martin, aka Uncle Bob), as that is what I am being asked to do as I have been told having data from one person and only one person (Robert C Martin) is not good enough of an argument.

Question:

What are some resources I can cite directly (Title, year published, page number, quote) by well known experts in the field that explicitly say this use of "God" Objects/Classes/Systems is bad (or good, since we are looking for the most technically valid solution)?

Research I have already done:

I have a number of books here and I have searched their indexes for the use of the words "god object" and "god class". I found that oddly its almost never used and the copy of the GoF book I have for example, never uses it (At least according to the index in front of me) but I have found it in 2 books per the below, but I want more I can use.

I checked the Wikipedia page for "God Object" and its currently a stub with little reference links so although I personally agree with that it says, it doesn't have much I can use in an environment where personal experience is not considered valid. The book cited is also considered too old to be valid by the people I am debating these technical points with as the argument they are making is that "it was once thought to be bad but nobody could prove it, and now modern software says "god" objects are good to use". I personally believe that this statement is incorrect, but I want to prove the truth, whatever it is.

In Robert C Martin's "Agile Principles, Patterns, and Practices in C#" (ISBN: 0-13-185725-8, hardcover) where on page 266 it states "Everybody knows that god classes are a bad idea. We don't want to concentrate all the intelligence of a system into a single object or a single function. One of the goals of OOD is the partitioning and distribution of behavior into many classes and many function." -- And then goes on to say sometimes its better to use God Classes anyway sometimes (Citing micro-controllers as an example).

In Robert C Martin's "Clean Code: A Handbook of Agile Software Craftsmanship" page 136 (And only this page) talks about the "God class" and calls it out as a prime example of a violation of the "classes should be small" rule he uses to promote the Single Responsibility Principle" starting on on page 138.

The problem I have is all my references and citations come from the same person (Robert C. Martin), and am from the same single person/source. I am being told that because he is just one guy, my desire to not use "God Classes" is invalid and not accepted as a standard best practice in the software industry. Is this true? Am I doing things wrong from a technical perspective by trying to keep to the teaching of Uncle Bob?

God Objects and Object Oriented Programming and Design:

The more I think of this the more I think this is more something you learn when you study OOP and it's never explicitly called out; Its implicit to good design is my thinking (Feel free to correct me, please, as I want to learn), the problem is I "know" this, but but not everybody does, so in this case its not considered a valid argument because I am effectively calling it out as universal truth when in fact most people are statistically ignorant of it since statistically most people are not programmers.

Conclusion:

I am at a loss on what to search for to get the best additional results to cite, since they are making a technical claim and I want to know the truth and be able to prove it with citations like a real engineer/scientist, even if I am biased against god objects due to my personal experience with code that used them. Any assistance or citations would be deeply appreciated.

Please define your understanding of "God Object" and how it relates to your question. You spend 4 paragraphs saying that God Class isn't a standard term in the literature. Then why are you using it? If you use industry standard terms, and can show how those concepts apply to your current project, then you might convince some people of your point. Using made-up words in a business meeting is only going to undermine your argument. Industry standard terms exist - you aren't the first person to ever see an everything-is-global or single-object nightmare, or whatever you are trying to describe.
–
GlenPetersonDec 5 '12 at 2:49

You shouldn't be attacking the god object but the problems it creates. Like: we have very tight coupling between everything and a change in A requires also changes in B,C and D. So, to help against that we're going to extract classes. Or: we want the code to be in a testing framework, and we can't do that, what are we going to do? Also, try avoid using the term "God", people not receptive will think you're using hyperboles.
–
Pieter BDec 5 '12 at 8:14

6 Answers
6

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.

Now that I have more than 5 minutes to write, I'm editing my answer to add:
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, ia 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.

Good point about it being a social problem. Must be why there is so much bad written code and poorly designed applications out there.
–
Yanick RochonDec 5 '12 at 11:57

3

+1 for tying it in with 'business speak' as such; aim to make it as relevant to your audience as you can. If you're talking to executives then do talk about how the standard of code has a direct link with maintenance and performance, and do discuss how this ties in with overall project finances, long-term stability and so on. It sound like you've been hired because of your knowledge; remember this. (Just don't become a jerk-off manager who thinks he always knows best - but in this instance you're 100% correct.)
–
Fergus MorrowDec 6 '12 at 16:55

1

+1 for "working code trumps any arguments about theory or good design." Something we often forget in our quest for perfect code.
–
Bjarke Freund-HansenFeb 10 '13 at 11:18

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.

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.

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.

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.

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.

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.

Object-oriented programming languages often require that if two independent source assemblies are responsible for different aspects of an object's behavior, independent object instances will need to be created to encapsulate those behaviors. Unfortunately, even though in many cases the most logical subdivisions of functionality between code assemblies don't coincide with the most logical subdivision of functionality between object instances, I've not seen much discussion about distinguishing the two kinds of subdivision.
–
supercatJan 21 at 18:05

I believe this is a little off-topic for this question. We're not talking about the God Object anti-pattern, here, but code coupling and cohesion, which is a much broad topic and very subjective.
–
Yanick RochonJan 21 at 18:17

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.

"if there is still resistance, the correct course of action is for your team to do as they're told" Maybe the correct course of action is to quit rather than making your team miserable..?
–
TomDec 2 '12 at 20:11

The manager's decision has been adequately justified, and if the team don't agree, then the problem is with the team. The OP was hired for his expertise and not being allowed to use it to benefit the business because colleagues won't behave reasonably isn't acceptable. Let's turn your assertion on its head - why shouldn't the resistant team members quit if their view of the job is incompatible with that of the business?
–
Tom WDec 2 '12 at 20:21

3

Fair point. It depends how you want to run the team. But in my experience forcing people to do things against their will just leads to misery. I would rather see God Objects throughout the code base than a miserable development team. Maybe the answer is to send them on a training course. Everybody loves a training course. Win-win.
–
TomDec 2 '12 at 20:55

The lead developer/manager/whatever should absolutely take all reasonable measures to ensure that the team retain a good working relationship with one another. If additional training is helpful, then by all means consider it as an option - but this seems to be like a case of wilful ignorance, and telling someone they need to be trained to understand your idea when what they think they've done is disagree, rather than not understand, could backfire. I have a hard time imagining ways of dealing with people who don't want to learn.
–
Tom WDec 4 '12 at 14:17

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.

I left the company shortly after. they tried to hire me full time and make me move to NY from Seattle in order to accept the offer; I basically told them "No way, I'm not going to move to NY when the team I would be managing is in Bellevue, WA" and at that point I basically walked across the street and got a job at MSFT until I found something better.
–
honestduaneJun 5 '14 at 14:50

@honestduane Yeah, that set of expectations alone speaks volumes. Good for you on the GTFO.
–
Erik ReppenJun 10 '14 at 16:10