Tips about how to spread Object Oriented practices

Question

I work for a medium company that has around 250 developers. Unfortunately, lots of them are stuck in a procedural way of thinking and some teams constantly deliver big Transactional Script applications, when in fact the application contains rich logic. They also fail to manage the design dependencies, and end up with services which depend on another large number of services (a clean example of Big Ball of Mud).

My question is: Can you suggest how to spread this type of knowledge?

I know that the surface of the problem is that these applications have a poor architecture and design. Another issue is that there are some developers who are against writing any kind of test.

A few things I'm doing to change this (but I'm either failing or the change is too small are)

• Running presentations about design principles (SOLID, clean code, etc).
• Workshops about TDD and BDD.
• Coaching teams (this includes using sonar, findbugs, jdepend and other tools).
• IDE & Refactoring talks.

A few things I'm thinking to do in the future (but I'm concern that they might not be good)

• Form a team of OO evangelists, who disseminate an OO way of thinking in differet teams (these people would need to change teams every few months).
• Running design review sessions, to criticise the design and suggest improvements (even if the improvements are not done because of time constraints, I think this might be useful)

.

Something I found with the teams I coach, is that as soon as I leave them, they revert back to the old practices. I know I don't spend a lot of time with them, usually just one month. So whatever I'm doing, it doesn't stick.

I'm sorry this question is spattered with frustration, but the alterative to write this was to hit my head on the wall until I pass out.

Answer 1

This should have been a comment, but since I'm apparently not yet able to comment on stuff, might as well be an answer.

The most important thing ever in this kind of breakthroughs (be it OOP or any other paradigm-shifting, say, functional programming or whatever comes out in the next year) is DO CODE REVIEWS AND PEER PROGRAMMING. Accompany them, walk the teams into a different way of doing stuff that will help them.

My personal path to object oriented programming started when some random asshat doing code reviews chastised me for doing stuff in a modular way and mantaining state without going full C++ OO; think code like

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(note that clients_total may be entirely redundant, being a particularly poorly planned example)

And I ended up doing this only when more senior coworker just pointed at my screen and said "look, if you write the same thing more than once, use a procedure or a function and just call it over and over".

Talks and meetings and optional practices won't make them make a paradigm shift or introduce a new practice, since there's no real drive to do it besides pure curiosity. On the other hand, making not doing it a bad or just generally frowned upon thing increases the adoption rate really well.

Be prepared for the whining and class-oriented development that will ensue until they incorporate proper design into what they're doing though. You'll see plenty stuff that'll make you die inside a bit, but that's how the path to learning looks like.

Answer 2

You Already Have Good Ideas

The ideas you outline in your question sound excellent. It is a big surprise that you are not finding success. It is 2012 and the object-oriented revolution has long since passed from state-of-the-art to state-of-the-practice. It seems like unless you have very low turn over and very little hiring, you would have a hard time not getting several dozen or even a hundred good solid object oriented programmers.

Agile or Object Oriented?

You mention some Agile technologies like TDD and some newer concepts, so don't be too harsh on people for not embracing something that is still actively fought by some management teams. Some claim to embrace Agile, but when they talk about it, it means what they say it means. The organization is not characterized by teams that make decisions and adapt, but instead by strong hierarchical contract-style control.

But back to object oriented. You don't mention object oriented analysis or design, and I am not quite sure which programming language is giving way to which object oriented programming language. I know UML is having popularity problems among many object-oriented programmers. Having been thoroughly trained in OOAD, I believe that it may be like learning the culture and history of a country whose natural language you want to learn. For example, if I wanted to learn Greek, I could learn the alphabet, vocabulary, and grammar, but if I ignored the rich history and culture, I would miss a lot. In any case, if you learn all about an object oriented programming language, but nothing about OOAD, I think an important opportunity has been lost.

Problems to Overcome?

Bridge too far? If you ask people to learn one small thing a week, in a year, among the people who participate, there will be a lot of change. If you ask them to change everything they know, it will be welcomed by a few, hard for many, and impossible for others. Some changes like source control are localized. You transitions from not doing it before, you had training that was not stressing the limits of memory, someone walked you through it the first time, and then the day-to-day was pretty easy.

Other changes are pervasive. For example, dumping C and switching to Java requires significant training, setup, and big changes in the day-to-day to adopt a new IDE, new compiler, new language, new API, new deployment model, etc. This is the kind of thing that happens most often in conjunction with a pilot program or corporate restructuring.

Leading a Revolution? If the people currently doing the work have a history of being rewarded, and the company does not seem in danger of failing, what is their motivation for change? If you seem like an outsider who wants to point the direction and leave them accountable for results they can't predict, it may seem like all risk, no reward.

Position Power or Idea Leadership? Many organizations operate based on position power. If you lack visible support from managers, sections heads, directors, and Vice Presidents, you are merely an idea leader. Some people are in the dangerous position of having one idea, and not being able to entertain a second one. If you can show them instead of telling them, that will go a long way to quiet skeptics and to interest talented allies.

Base of Support Too Small? Do a triage among those 250 people and sort them into three categories: ready to embrace, willing to learn, and unwilling to learn. You have good reasons to be frustrated with some of the people who have no interest in making a change. You might as well be pushing on a rope. This is wasted effort. If you have a feel for who supports change, you can find out what interests them.

Unlike a medical triage where the ethical and practical choice is to help the middle group that can make it with help, you can invest your energy and time based on your judgment and preference. For your success, why not cultivate the group that is ready to embrace new ideas? They may be few a first, but like a snowball, your visibility and credibility as an advocate will grow. Soon people will be asking you when the next training will be.

In it for the Long Term? Until you cultivate a champion to carry things after you, you should expect to invest time building relationships. You may need to stay with the teams you coach for more than one month. Until the team owns improved practices for themselves, you are just a technology or methodology cop. Mentoring is a process that can take years. There are a lot of things your developers don't want to do that you think are important (you specifically mentioned unit testing I think). It may take a while to build a shared vision of the value this brings. I know this by experience because I once advocated for a code coverage tool at a Fortune 500 company that had a great reputation for quality, but managers and peers alike were wary about committing to it.

Expert or Grassroots? Much faster than mentoring would be to foster grassroots support that comes from each team member. Starting with a team of ten software specialists, if I had my choice to have one person work on process all the time or ten people work on process ten percent of the time, I would pick the second. Grassroots process permits the advocates to feel the impact of the approach, and for the approach to be tailored to best solve the problems of the team who owns the work.

Do you see the Freedom Line? Part of introducing "Best Practices" is to get people to give up some freedom to do things in a common way. Giving up programmer's discretion will be more palatable if you look for opportunities to leave many choices to developers. What they pick is delineated from what is mandated by a partition that we can call the freedom line. It may be necessary to similar, well justified divisions about organizational, regional/site specific, team, and personal practices.

Answer 3

Don't try to push OOP, it will only make things worse. Not because OOP is a bad idea in general: it's not. But because it seems that whoever is responsible for that hairball code not only lacks the tools to avoid these problems, but also the experience and, more importantly, the motivation.

People who have a desire to write clean code will do so in any given paradigm, be it OOP, procedural, functional, etc. But not all programmers are like this, and if you push any clean-code tool onto people who don't understand the need, you will end up with these tools abused just like the tools that are already there. You will see unrelated methods grouped into a class, classes inheriting from unrelated classes, method visibility set based on trial-and-error debugging rather than conscious design, static methods that shouldn't be static and non-static methods that should, in short, you'll be wasting your time.

Instead, see if you can invest in raising consciousness for maintainability and elegance. After all, core goals of OOP aren't any different from any other complexity-management strategy (which is what programming paradigms are really all about): encapsulation, modulatisation, loose coupling, low degree of interdependency, keeping mutable state and its scope to a minimum, etc. etc. OOP certainly isn't the only paradigm that gives you the tools you need to achieve this.

Which brings me to the last point: OOP is a great idea, and it works well for certain kinds of problems, but (and I'm speaking both from my own experience and paraphrasing the opinion of some great minds here) for many kinds of problems, it is completely unsuitable. When you're fresh into OOP, and semi-procedural spaghetti code is the only alternative you're familiar with, OOP naturally appears as a gift from heaven (and in a relative way, it is), and you're likely to approach all problems as nails for your OOP hammer. That's only natural, and driving OOP to (and beyond) its limitations a good way to build up your OOP skills, so it's not all negative. But maybe (just maybe) this particular codebase does not need OOP after all. Maybe it would benefit much more from a procedural architecture, albeit a more structured one with proper design, a decent project layout, the right abstractions, and appropriate encapsulation.

TL;DR: If you want to evangelize anything at all, let it be (platform-agnostic) good coding practices, not any particular paradigm or methodology.

Answer 4

My experience is that switching from procedural mindset to OO mindset is a big hurdle. It requires perseverance which many developers fail to endure. This is mainly because the fundamentals of OO are looked over.

Form a team of OO evangelists, who disseminate an OO way of thinking in differet teams (these people would need to change teams every few months).

is a good idea. This should be thorough and OO should be talked about from ground up. When I was learning OO historical anecdotes helped a lot.

I would also suggest,

• Since motivation is the key, motivate them detailing how OO can improve their work, especially code maintainability.
• Do code review and show how to refactor applying composition, inheritance, polymorphism, and patterns.
• Introduce a good process like SCRUM and engage developers in it.
• Make reading books like 'Refactoring' and 'Refactoring to Patterns' mandatory.

Answer 5

I agree with Shuvo Naser. It's a big hurdle, so treat it more like a climb. Learning how to design an entire application using OOP is going to take time.

1. Identify those that understand OOP and move them closer to team leaders, trainers, designers, code reviewers, etc.
2. Use an existing project as a training reference. Possibly those in #1 were on that team.
3. Refactor some existing projects. This can help some people build a bridge between their procedural code to OO code. Start with basics. They have to see when, where and why you use these principles.
4. Involve them in design sessions with people who know what they're doing.
5. Put them on dev teams with someone who can provide design guidance and make sure the project sticks to OO principles (Assuming the reason you want to do this in the first place is because it will improve developement.).

Adoption rarely precedes seeing the benefits. We're talking about complex design and not using T.P.S. Report Cover Sheets.

Answer 6

You can't make anyone change who doesn't already want to change. Which is why the teams you have coached have reverted to their old ways.

So really, your question should be "how do I make developers want to change to OO approaches?"

Start simple, start small, let things build from there. Show the benefits to the individual developer instead of abstract or philosophical benefits to the code, other developers, or the company.

Show how the various OO techniques will lead to less code that they have to write as well as faster development times. Almost any developer will listen to a proposal that will make their job easier.

Then start demonstrating how OO techniques will lead to more easily maintained code. Everyone in that type of environment lives in fear of making "the change" that obliterates a third of the production application. Encapsulation is the key to avoiding this risk and allows each (soon-to-be) layer of the application maintain its contract with the other layers.

I would look at how data is being passed around. If it's a long list of variables every time, consider wrapping some of those up within a structure (or gasp! a class!!!) as a preliminary step. Simply wrapping the data within an object is the beginnings of contracts between layers.

At a broader level - consider getting management buy-in for this effort if you haven't already. Management needs to see the concrete benefits of decreased defects and lower risk from making changes. Eventually, the refactoring process should lead to faster development times, but that is a long term benefit.

Your ideas of review teams and OO evangelists are good ones. It needs to be more than just you who is pushing this agenda.