I am looking for an efficient way, that also doesn't come off as an insult, to introduce OOP concepts to existing team members? My teammates are not new to OO languages. We've been doing C++/C# for a long time so technology itself is familiar.

However, I look around and without major infusion of effort (mostly in the form of code reviews), it seems what we are producing is C code that happens to be inside classes. There's almost no use of single responsibility principle, abstractions or attempts to minimize coupling, just to name a few. I've seen classes that don't have a constructor but get memset to 0 every time they are instantiated.

But every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking about. Knowing the concepts is good, but we (some more than others) seem to have very hard time applying them when it comes to delivering actual work.

Code reviews have been very helpful but the problem with code reviews is that they only occur after the fact so to some it seems we end up rewriting (it's mostly refactoring, but still takes lots of time) code that was just written. Also code reviews only give feedback to an individual engineer, not the entire team.

I am toying with the idea of doing a presentation (or a series) and try to bring up OOP again along with some examples of existing code that could've been written better and could be refactored. I could use some really old projects that no one owns anymore so at least that part shouldn't be a sensitive issue. However, will this work? As I said most people have done C++ for a long time so my guess is that a) they'll sit there thinking why I'm telling them stuff they already know or b) they might actually take it as an insult because I'm telling them they don't know how to do the job they've been doing for years if not decades.

Is there another approach which would reach broader audience than a code review would, but at the same time wouldn't feel like a punishment lecture?

I'm not a fresh kid out of college who has utopian ideals of perfectly designed code and I don't expect that from anyone. The reason I'm writing this is because I just did a review of a person who actually had decent high-level design on paper. However if you picture classes: A -> B -> C -> D, in the code B, C and D all implement almost the same public interface and B/C have one liner functions so that top-most class A is doing absolutely all the work (down to memory management, string parsing, setup negotiations...) primarily in 4 mongo methods and, for all intents and purposes, calls almost directly into D.

Update: I'm a tech lead(6 months in this role) and do have full support of the group manager. We are working on a very mature product and maintenance costs are definitely letting themselves be known.

  • Possible duplicate - programmers.stackexchange.com/questions/67579
    – ChrisF
    Commented Jul 28, 2011 at 9:20
  • 3
    Are you their supervisor or boss in any way? If not, do you have support of the technical director who is the boss of all of you? If you're just one of the guys and development has been steady and productive for years without using deep OOP designs then you're in for an uphill battle to convince programmers that working code doesn't work and management that you're not wasting money better spent generating code. Commented Jul 28, 2011 at 16:36
  • After I made this post, related linked popped up that sounds very much like my situation: programmers.stackexchange.com/questions/43214/…. I'm worried about exactly the same thing. The problem is that their team had 2 developers and I could definitely manage that with code reviews. I'm looking for an approach that would work with our team size (10+) I just don't get to communicate with every developer one-on-one as much as I'd like to.
    – DXM
    Commented Jul 29, 2011 at 3:45

5 Answers 5


Why don't you develop a short training in the SOLID principles and give them this training? It seems to have worked quite well for me in my current organization and I find giving short trainings is actually fun (for everyone involved).

When I gave my training I took some time to search for pathological "bad" examples in the existing code (of various projects), and refactored them in the presentation, step by step, using the principles. This demonstrated that

  1. It's not that hard to do these refactorings
  2. It doesn't take a long time
  3. The end result (carefully chosen ;-) ) is clearly better than the original code.

Code reviews have been very helpful but the problem with code reviews is that they only occur after the fact.

On one project, we did design reviews.

15 minutes. At the white board. Talk through the design prior to coding.

The most important part is scheduling the design review prior to any implementation work.

We also had "Critical Design Reviews" which were a big, sweaty deal. They involved lots of documents and a lengthy presentation. They were hard to schedule and almost always got pushed out until after coding had started, reducing their value to zero.

Informal design reviews -- prior to coding -- no pressure -- no documentation -- allows better discussion of how responsibilities are assigned and how objects will collaborate.

  • yep, we already do design reviews exactly as you've described them. The problem is mid-size tasks. If the task is large enough, I generally take the time to come up with initial class diagram which then gets refined by the team. If the task is small, then existing high-level design is already good enough. However, for medium-size tasks, I do not have the capacity to put enough thought into the design so the basic rule is "use best judgement and follow OOP". If I was to do these tasks myself, I'd start with coding and intermingle that with continuous refactoring and...
    – DXM
    Commented Jul 29, 2011 at 4:02
  • ... let the code decide what the final design would look like. However, when I leave these tasks up to some team members, what I sometimes find in the code review is stuff like that which I described in my initial post.
    – DXM
    Commented Jul 29, 2011 at 4:06
  • 1
    @DXM: What? You're doing them? Or not doing them? If large, then you're not doing design reviews -- you're doing design for someone else -- who learns when you do design? If small, then you're not doing design reviews -- the "existing design is good enough" -- who leans when you ignore design? If medium, you don't do design, and you don't review their designs, either? It doesn't sound like you're actually doing actual design reviews. Why do you say you are and then give three examples where you're not?
    – S.Lott
    Commented Jul 29, 2011 at 9:51
  • @Lott: upon reflection on your response, my only conclusion is that you are absolutely right. I guess what I should've said is that I've brought up this exact idea at least 8 times and everyone always agreed, but yeah, if I look back at the rhythm we settled on, we are not really doing any of it. I'd like to discuss this further, but I already got disciplined by mods for having a discussion on a strictly Q&A site. Could we move into chat? I'd like to explain the situation more and maybe pick your brain (or anyone else's who wants to join) a bit. Never done chat, you know how it works?
    – DXM
    Commented Jul 30, 2011 at 5:46
  • @DXM: Chat's trivial. And not too helpful. If you have further questions -- more detailed than this initial question -- you should ask those more detailed questions. That's the point. In a few cases "further discussion" amounts to "I don't like your answer to my question for the following reasons..." which is kind of silly. Not liking an answer is simply not liking an answer and doesn't require any discussion. In a few cases, discussion amounts to "my question is not vague, you just can't read." Unhelpful, really. Ask your questions. As questions.
    – S.Lott
    Commented Aug 1, 2011 at 11:02

I'm assuming you're younger than some of the developers, but higher up in the food chain.

At the risk of getting burried in downvotes, it could be that the 'experienced engineers' are in fact doing the right thing - or since this is a mature product that may have been around for decades, what was once the right thing.

Older code tends to have been optimised to run quickly on the hardware of the time; amongst other things this means cutting down on the levels of inheritance and avoiding function/method calls for trivial operations.

Compilers have got a lot smarter over the years, so not everything that was once true now is - for example, a compiler may elect to inline a small function.

Perhaps a route forward would be to adopt a different approach - ask the developers to explain how/why their method is better than the theory you were taught - and be sincere about it.


Would pushing for unit tests with a 100% branch coverage of each new/changed method not lead to minimize coupling between methods.

  • UT is a good idea, but I'm not convinced this would achieve the desired result. Besides, one of the fundamental principles of OO is that coupling between functions is unavoidable, so you better make that explicit and group such coupled functions in a single class.
    – MSalters
    Commented Jul 28, 2011 at 9:44
  • I agree that "coupling each between functions is unavoidable". However good design reduce the number of other functions each function is coupled too. (A class is just a means to this end)
    – Ian
    Commented Jul 28, 2011 at 10:01

You might want to pick up the "Design Patterns" book from the Gang of Four. It's not specific to C++, so you're not openly criticizing your colleagues C++ knowledge when you refer to it. Yet at the same time it does address topics that you consider relevant. Also, the book is widely accepted as relevant, so they can't easily dismiss it as theoretical or impractical.

On the other hand, consider that C++ isn't a pure OO language, neither in design nor in practice. The whole constructor/memset story sounds you should introduce RAII, which isn't an OO technique at all but specific to C++ (unfortunately - .Net's IDispose shows what happens when RAII is an afterthought). The relevant books here are (More) Effective C++ and (More) Exceptional C++.

  • 2
    But the authors clearly state that design patterns is not an introduction to OOP/OOD in general! The audience should first be familiar with the techniques OOP offers before diving into a hardcode design patterns catalogue! "Head First Design Patterns" will make a good introduction.
    – Falcon
    Commented Jul 28, 2011 at 10:41
  • 2
    It appears from the OP description that they do know OOP/OOD, they just don't use it (maybe from fear it would be too complicated), in which case a book that explains why it's useful may motivate best than code examples.
    – wildpeaks
    Commented Jul 28, 2011 at 11:10
  • @wildpeaks: The OP sais the contrary. They don't know OOP/OOD. They're programming OOP in a procedural manner. They need something to introduce them to design techniques and the GoF book does not suit this scenario imho.
    – Falcon
    Commented Jul 28, 2011 at 12:29
  • I was referring to the sentences But every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking about and My teammates are not new to OO languages, but I can see how it's a bit vague indeed as they may just be lying about knowing OOP when OP talks to them about it.
    – wildpeaks
    Commented Jul 28, 2011 at 12:59
  • 1
    @MSalters - Preface of Design Patterns: "This book isn't an introduction to object oriented technology or design. Many books already do a good job of that. This books assumes you are reasonably proficient in at least one object oriented programming language and you should have some experience in object oriented design as well." This book does not fit the requirements. They should read some entry level OOD stuff.
    – Falcon
    Commented Jul 28, 2011 at 15:23

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.