I have been part of the organization I work in for the past year and a half or so. The company basically writes Perl code and they have large amounts of legacy code which originally prevented the company from moving forward with any code changes. My first observation with the existing code was non existence of Modularity.Over the time I worked here I, with the help of a few (who left the company), did a lot of hardwork Modularizing all the core sections of the application. I believe that we now have about 70% of the core systems modularized, coherent and layered. At this point in time I am accused of complicating the system design and everything I try to do is sort of looked at with suspicion. To design these systems I applied all the best design approaches(patterns) and methodologies(SOLID) available or known to me. When I wrote it, it was all appreciated but now the developers want to revert back to what they believe as simpler methodologies(which basically involves having large single classes, doing 100's of things). I still do not believe that those approaches are actually going to lead to simpler design but no one is actually ready to listen.To give an example, our code basically loads a bunch of files during its lifetime. Traditionally the class handled a lot of things like loading the file, repeatedly checking if the file has changed, is the right version of the file loaded etc. We also load a different set of files for test cases to ensure that it is working fine. All this was done very un organized fashion earlier. Every one created their own version of the file. There were lots of versions of these files and they were un manageable. I introduced a subsystem that will load you the right file(do the version verifications) given a name and a configuration that will tell all the versions of the file available. It eventually ensured that only two to three versions of the files are used across all the test cases. It basically follows a facade and factory pattern where the loader will create the right file object, which will have interface to load, save and should_reload. It was eventually even used to load contents from CouchDB as they only represent a document. This is now too complicated for the developers and no one really reads the code or the documentation I wrote. I do agree that going back to our old system will remove one sub system but will bring back the problem of un manageable number of files.At this juncture I find myself quite unsure of all the things I have learnt. I find myself not really interested in suggesting any improvements as my solution will only be accused of being too complicated.What do you think I can do at this point in time?
Modularity vs Single class simplicity
object oriented design
One thing that comes to mind is something I just read in Robert Martin's book: You learned design patterns and you learned solid principles. But all these things should not be applied blindly to any and all code just because you know them. Instead, they should be applied when the alternative would be more complicated than not applying them.It's a pretty good book and he walks you through a bunch of examples of iterative, test drive development. Throughout the book there's a unifying message that says, keep the code simple, don't introduce extra abstraction layers and patterns. Instead, incrementally add features and converge towards known patterns when that proves to be the simplest solution.Based on your post, it may have sounded like some of your software could have been considered as over-designed. At the same time I do not know what the skill level for the rest of your team is.  And unfortunately, I can easily imagine other people getting confused when they see 2 classes and an interface even if you were absolutely correct in suggesting them.In my experience, there are definitely some programmers who do still believe that the goal of our job is to stitch together API calls using any number of control statements needed. And when you need to extend the code, you simply need more control statements. And what makes a good programmer is one that can navigate 600-line method and be able to make it 700 lines while introducing only 2 bugs. And if this is what they believe, you will have a very hard time convincing them otherwise, God knows I've tried.I don't have a good answer for this type of situation.  My only advice would be to gain support of the project technical lead, or another senior developer that others look up to. Have some discussions and reflections on past code and see if you can identify what was done in the past that worked and that didn't. Once you have them on board with you, gain support of management so that the right people would have the capability of ensuring some level of design makes it into the product.If you don't have that support, I guess you could either a) look for a different job/team or b) create a bubble of good code around you and try to work in isolation :)Just remember that we apply patterns and SOLID not because we read about it, but because it IS THE SIMPLEST code we can possibly write. So if you practice this stuff, you should be able to code faster and produce higher quality code than your team mates.  Eventually others, including your management, will notice that.  If you find yourself producing proper designs but your tasks continuously take you twice as long as they would have otherwise, then you may be missing something (good design might take more time upfront, but you should expect to see a payback in very short future).