Problem Summary:
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 development 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 ammunition 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 can't 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 the two books 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 view, 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.
Best Answer
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.