Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
Stick to your guns. Listen to their points of view and if not convinced then be ready to argue your point as to why what you have done will lead to less work and better maintainability in the long run. Lots of head banging and internal swearing will be needed by you. Good luck. –  dreza Mar 8 '12 at 3:15
1  
Methodologies are so hard with no syntax sugar to easen the pain. (sorry for the half-comment, had slipped on the save button) –  ZJR Mar 8 '12 at 3:46
    
Thanks, that was pretty encouraging. :) –  arunmur Mar 8 '12 at 3:46
    
Now, what I really don't understand is why you trowed the CouchDB bomb over to an already pretty alienated crowd. You're kind of losing them. Are you at least officially meant to manage the whole project or you just hijacked the scene? –  ZJR Mar 8 '12 at 4:00
    
@ZJR most of them are not my decisions. Its works more like a group decision. I mostly write them, while I do come up with solutions. –  arunmur Mar 8 '12 at 4:07
show 2 more comments

3 Answers

up vote 5 down vote accepted

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).

share|improve this answer
    
I will again agree with that. I find my designs have considerably reduced the amount of time it would take to integrate and test things over a period of time. For starters it made a huge percentage of the code testable, which they were not earlier. I also believe in evolutionary designs, where you start with something simple and then improve(or redesign) it over a period of time when things dont work. I also consider design and implementation complexities while designing something. Our code base often has 3000-5000 line classes, which annoys me to death. –  arunmur Mar 8 '12 at 4:01
    
I think you are on the right track and yeah nothing good every came from 3k line class. Just remember that it will take time and before you can influence people, sometimes you just need to do your thing and gain their trust and respect first. In the meantime, I would seriously consider focusing trust/respect thing on the current leader of your team. It's much harder to change the way your team works if it's 1 vs. 8 compared to 2 vs. 7. –  DXM Mar 8 '12 at 4:26
    
Thanks. I will try that. I was seriously thinking of quitting but I have lots of opportunities to learn here. :) –  arunmur Mar 8 '12 at 4:32
    
+1 - The skill level of the team has a huge impact on their perception. The less skill, the less likely they'll see any benefits of moving away from BASS. –  Dunk Mar 8 '12 at 22:57
add comment

Economics - that's what you MUST do and COMMUNICATE. Let's say they do it they way they want to. And then we have your way. What are the benefits?

Can you 'break down' the benefits? (Keep asking so-what until you hit the end benefit). Now, can you quantify the benefits and convert it to a dollar-$ value? (if it's worth it, it should be quantifiable - if you are confused pick up Doug Hubbard's "How to Measure Anything" :)

Now, take the differences to the management. Show them how what you did helped them be well off, using economics (that's all they'll want to see/hear at this point owing to your situation). Use numbers: cost saved/earned, revenue estimated, future savings, operational efficiencies etc., whatever it is that you think is/was the benefit of your design. Create a simple business case and SHOW it to them. Keep it believable please.

Your managers/bosses should see this with ease and be more confident rather than just "technically better claims." If they can't you are in the wrong company - they can't understand business economics!!

(You may want to look at Steve Tockey's excellent book - "Maximizing return on software" - it's all about showing the economics of anything technical)

Best of luck!

share|improve this answer
    
Good point. Unfortunately, this is a small company with some 8-9 developers. At this point people dont see code changes as either experiments or economical improvements. There is also too little team mechanics. I have been trying really hard the last few months in asking the developers justify the economic value of their work or implement it as a small experiment. I can try to pitch the improvements as economical but I dont think they will see it that way. I will also read the book you suggested. –  arunmur Mar 8 '12 at 3:46
add comment

It's just entropy.

If you keep your objects--or at least their external view, the methods, properties, etc.--as small and as simple as possible, there is no limit to what you can do and to what you can maintain and enhance. Systems of near-infinite capabilities and complexity become possible. But it can take extra work and self-discipline to stick to this on a day-to-day basis.

Consider a display table (Class DT). You want to know which row is selected. If all your classes are small, you will need to use one of DT's few methods to get a Row object. Then you will need to use one Row's few methods to get a Selection object. A Selection method will finally tell you which row is selected. Your typical developer will want to add a DT method, "getSelectedRow". It's easy to add. Saves time in use. Can be spotted in documention far more quickly. All in all it's a win-win idea and you can't argue against it. There are no flaws.

Of course, once DT has 500 methods, etc., finding that one method can get real tricky. When it's got 1000+ it can be impossible. But it's impossible to explain that to people. First they're only going to add one new method/property/whatever. When there's too many, they have no idea what's wrong, so they're not going to fix it even if they would pay the cost--which they won't. I think some people like this situation because they've memorized all 500, and there won't be so much competition for their job--they're one of very few people who can use the class effectively.

Every now and then someone does something right and great software is produced. But the usual trend is to bury the simplicity that makes useful complexity possible beneath all kinds of enhancements that, indidividually, make life easier and, collectively, make a system unfixable and unenhancable. I have seen, in both small companies and in immense, core IT companies, a continuing need to scrap old systems and build entirely new ones because no further work could be done on the old ones. I have seen both individual programmers who had to get new jobs because they could no longer make sense of their old code and major software companies that had to produce brand new systems because they could do no more work on their old ones.

I think all you can do is: Keep your own code clean. Try to sell your ideas to one or two of the other programmers. Hope management notices that your stuff has fewer bugs, gets produced faster (in the long term), and is enhancable. And if management becomes too oblivious to what you are accomplishing, get another job and hope it works out better.

share|improve this answer
    
I understand what you are telling. I have kept extensibility in mind. Like your Class DT example, to add more functionality you just have to add another class. In case of my file loading example, to add support for another type of file, you just have to add another class, implement 5 functions and import a role(perl Moose), which hides some boiler plate code. –  arunmur Mar 9 '12 at 5:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.