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 come from a strong OO background, and I have recently started working in an organization which, although the code is written in Java, has a lot less emphasis on good OO design than what I am used to. I have been told that I introduce "too much abstraction", and that I should instead code the way it has always been done, which is a procedural style in Java.

TDD is also not very much practiced here, but I want to have testable code. Burying business logic in static private methods in large "God-classes" (which seems to be the norm for this team) is not very testable.

I struggle in clearly communicating my motivation to my co-workers. Does anyone have some advice on how I can convince my coworkers that using OO and TDD leads to more easily maintained code?

This question about technical debt is related to my question. However, I am trying to avoid incurring the debt in the first place, as opposed to paying it down after the fact which is what the other question covers.

share|improve this question
11  
What is your role? Grunt developer? You're screwed--get a better job. Lead Developer? You may be able to make a difference... –  Matthew Flynn Apr 4 '13 at 19:59
2  
Not so much tech debt, as dealing with poor design and people that won't change –  Ozz Apr 4 '13 at 20:13
1  
I am aware of the technical and business arguments, I am asking how to best bring this knowledge across to my coworkers who seem to be oblivious of this. They see a lot of classes, I see a testable, extensible system –  ThuneGrill Apr 4 '13 at 20:33
    
Agreed that the code you describe is not good OO design. It sounds more like the kind of !@#$ code that leads to people erroneously favoring tests over maintainability as the primary driving force behind their architecture in the first place. And no, being alerted to the fact that your code is breaking in 20 places by tests every time you make a change rather than your compiler or run-time error-handling every time you make a change is not what I meant by maintainability. –  Erik Reppen Apr 4 '13 at 21:10
3  
Sorry, you have to leave. You are talking over the heads of your colleagues. It's not going to change until the project becomes unmaintainable. If you don't like manual testing and death marches, you better go somewhere else. –  kevin cline Apr 4 '13 at 21:34
add comment

3 Answers

You didn't complain about it being unmaintainable, just not to your liking. If it's a deliberate style choice, it may just be a case of irreconcilable creative differences, and you should adjust your style to fit, or find somewhere that fits your preferred style.

People can and do write modular, efficient, well-abstracted, relatively bug-free code in a procedural style all the time. Java is an odd choice of language for such a shop, but I can see it happening if external factors decided the language, like needing to develop for Android, for example.

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. — Albert Einstein

If it was a deliberate choice, you can't really judge them by how well they adhere to good object-oriented design principles, you should judge by how well they adhere to good procedural design principles, and also refactor accordingly. Java doesn't let you write code outside a class, so the mere presence of one doesn't mean they intended a module to be object-oriented.

On the other hand, if the code is a mess in either paradigm, you should probably just cut your losses.

share|improve this answer
1  
it is procedural and messy. But I am talking about new code that I write being called "too object oriented" –  ThuneGrill Apr 4 '13 at 20:58
3  
messy procedural code being extended with OO code might not be an improvement after all, just adding confusion. –  wirrbel Apr 4 '13 at 21:25
7  
@ThuneGrill, You're assuming they chose their coding style out of ignorance of object oriented design, that if you could just educate them, they would see the light. If someone with a profitable software business in a strongly object-oriented language hasn't looked into the benefits of OOD by now, there's no way the "new guy" is going to convince him. Take my word for it and the word of other commenters. If you can't or won't adjust your style to make it easier for the team to read, you should cut your losses. –  Karl Bielefeldt Apr 4 '13 at 21:41
3  
@ThuneGrill: Karl's right. Stick to pragmatic reasons, not religious ones. OOP is certainly a good idea, but I've seen it carried to ridiculous extremes. The result is making mountains out of molehills. Things that could be done in 1000 lines of code end up being 10,000 lines of code with classes galore. Then, Gee, it's hard to maintain, and the performance sucks. (No matter what collection classes get used.) –  Mike Dunlavey Apr 4 '13 at 21:51
1  
I wouldn't necessarily give up on the idea that you can convince people on this one. It's tough, but it can be done--I have done it. Since this question seems closed, see workplace.stackexchange.com/questions/9703/… –  Amy Blankenship Apr 4 '13 at 22:55
add comment

Reading your question, I remembered one tip of book Pragmatic Programmer.

One of its tips is Be a Catalyst for Change:

You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes—you know it's right. But ask permission to tackle the whole thing and you'll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called "start-up fatigue."

It's time to cook Stone Soup. Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say "of course, it would be better if we added…." Pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

So, I think If you start to do a good job with your OO and TDD knowledge, soon they'll start to look and ask about your job.

share|improve this answer
    
Trying to be, but the uber-architect (who does not code) will have none of it. –  ThuneGrill Apr 8 '13 at 5:41
    
As soon as he notice benefits of TDD and better OO (reliability, productivity, ...), you will get your attention! –  Rodrigo Apr 8 '13 at 13:35
add comment

You can only convince them by taking on a small chunk of code and implementing TDD and better OO practices on it to realize the benefits. You have lead them to the promised land, not just show nice post cards of it.

Certainly, I think there are cases of over abstraction in use in many code bases today. Only put in what you need, and that includes abstractions as well.

share|improve this answer
1  
Just did, that's whats caused the whole discussion. An I only introduced 3-4 abstractions on top of existing functionality –  ThuneGrill Apr 8 '13 at 5:40
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.