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

share|improve this question
    
look at modular programming - en.wikipedia.org/wiki/Modular_programming –  Yusubov Oct 7 '12 at 14:49
    
ElYusubov, the "standard" is to do TDD, which again not every teams follows. And some teams even do BDD with quite good results. (TDD and BDD are Outside-in, like modular programming). –  Augusto Oct 7 '12 at 19:16
9  
Please, don't see OO as something heaven send which will or should solve your problems. That is of course far too shortsighted. OO may have benefits but here are some different views on the subject: existentialtype.wordpress.com/2011/03/15/… Try not to focus on OO or even paradigms themself but look for best practices, which work for you, cs.brown.edu/~sk/Publications/Papers/Published/… –  AndreasScheinert Oct 7 '12 at 19:19
    
Andreas, I would love people to learn FP and apply the principles in OO!!! I agree with you 100%. The problem I have is that quite a few developers are comfortable doing things the same way they've been doing them since they started working, and in the journey they haven't improved their solution skills. –  Augusto Oct 7 '12 at 19:28
2  
Don't try to "Spread the Word". Proficiencies of doom and destruction preached from a pedestal don't go down as well with 21st Century University Graduates as they did with 15th Century Peasants. –  mattnz Oct 7 '12 at 21:05

6 Answers 6

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.
share|improve this answer
    
Thanks for your answer Shuvo. We already do SCRUM and code reviews (but often the reviewer is one of the people who don't know OO principles)... And I'm failing on the first thing you suggested. I'm trying to motivate teams, but with very little success :(. About making mandatory to read some books. I've never seen it work, as people take a copy and never read it, preventing other people from reading it. –  Augusto Oct 7 '12 at 19:05

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.

share|improve this answer
    
Thanks for you answer Glen! I have the feeling that I'm doing what you suggest. There's quite some management buy in and some teams leads are tired from being slowed down by teams that don't follow good practices, and as a consequence it makes their work more difficult. What you say on your first sentence is very true and it's part of the problem. I think some people are too used to do things wrong and don't have a motivation to improve. –  Augusto Oct 7 '12 at 19:00

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.

share|improve this answer
    
-1. This answer is almost as if it was for manager, not for normal developer. He cannot "move" people and he cannot "involve" people. IMO. –  Euphoric Oct 7 '12 at 15:08
    
+1. This is a management problem, and it is to be addressed as one. It's middle and lower management (the team leader is management) who dictates the style. Change in a company comes from below only when it is transparent to management. Switching to OOP requires a change in thinking at the top. Keeping the development process procedural / waterfall is a bit anathema to OOP. –  David Hammen Oct 7 '12 at 15:37
    
@Euphoric - you just need management approval. The OP mentioned "teams I've coached". Maybe he's not management but does have influence on how they work. –  JeffO Oct 7 '12 at 16:40
    
@JeffO Yeah, you are right. But it all comes down if management wants to support such efforts. At my last work, it was impossible to do something like that, because management was not interested in education of developers. –  Euphoric Oct 7 '12 at 17:28
    
Thanks for your comments guys. I'm not a manager, just a frustrated architect. I have some clout with the managers, specially if it means: faster, cheaper and better. Unfortunately, there are not enough architects in the company to help on each project, and most of the projects where the quality is not good enough, don't have a dedicated architect. –  Augusto Oct 7 '12 at 19:13

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.

share|improve this answer
3  
+1 : For recognizing that OOP won't save them. Evangelists often forget that..... –  mattnz Oct 7 '12 at 21:01
1  
+1: But I would upvote 10 times if I could. While it is true that OOP offers better support for structuring code than procedural programming, OOP alone is not sufficient. Same with SCRUM, TDD, and all the rest. I think these are all useful tools but they cannot replace (1) the basic attitude of each programmer to write simple, clean, modular code, (2) the work of one or more architects that are recognized as such by the whole team and that ensure that the overall code architecture stays coherent. Without these prerequisites a team can easily produce a big object-oriented ball of mud. –  Giorgio Oct 7 '12 at 21:02

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.

share|improve this answer

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.

share|improve this answer

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.