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.

  • 17
    What is your role? Grunt developer? You're screwed--get a better job. Lead Developer? You may be able to make a difference... Commented Apr 4, 2013 at 19:59
  • 2
    Not so much tech debt, as dealing with poor design and people that won't change
    – ozz
    Commented Apr 4, 2013 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
    Commented Apr 4, 2013 at 20:33
  • 5
    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. Commented Apr 4, 2013 at 21:34
  • 4
    Without seeing code in question (yes, it's hard to provide good enough sample, so we just have to trust your judgement here), it is hard to tell if there's indeed lack of OO, or if you are pushing over-engineered cargo-cult OO abtractions for no good reason. I think everyone has seen examples of over-engineered OOP, where abstractions rest on layer of abstract factories producing abstract factories, etc.
    – Kromster
    Commented Jan 19, 2016 at 9:06

4 Answers 4


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.

  • 3
    it is procedural and messy. But I am talking about new code that I write being called "too object oriented"
    – ThuneGrill
    Commented Apr 4, 2013 at 20:58
  • 5
    messy procedural code being extended with OO code might not be an improvement after all, just adding confusion.
    – wirrbel
    Commented Apr 4, 2013 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. Commented Apr 4, 2013 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.) Commented Apr 4, 2013 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/… Commented Apr 4, 2013 at 22:55

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.

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

To sell new ways to work, you need to show obvious benefits. Writing more layers of abstraction, without a clear benefit but a vague: "it can be beneficial for the future" won't work.

Make factories where the factories make more then one type of object. Use dependency injection, where it immediately shows benefits. Make interfaces that are actually going to be implemented by more then one class.

What I see too often in "true OO" is that advanced techniques are used to solve really simple problems in an overly complex way.

How can you show the benefit of a factory if it is only ever going to make the same object? Find a problem in your code that benefits from advanced techniques and shows your point and work from there.

Wars are won one battle at a time.


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.

  • 1
    Just did, that's whats caused the whole discussion. An I only introduced 3-4 abstractions on top of existing functionality
    – ThuneGrill
    Commented Apr 8, 2013 at 5:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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