best way to "introduce" OOP/OOD to team of experienced C++ engineers

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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