We have a couple senior (i.e. older) developers on our team that have no interest in improving. They write solid code, but they don't want to add unit tests or improve their efficiency. They are old-school C programmers using .NET, but everything they write is purely procedural. When confronted about their development speed (most code they write is far more verbose than necessary) or their lack of tests, they just say "Hey, it works, right? What's the problem?"

These developers also write surprisingly bug free code. Unfortunately they are also the only ones who can interpret it when an enhancement is needed (3000 line functions are not abnormal), so it's good job security in a way.

For example, the other day one I was doing a code review and the developer had a 100+ line function to filter a List. Basically it did this (slightly more complex, but it could have still easily been done in LINQ expressions):

 decimal avgAmount = locations
      .Where(d => d.Type == LocationType.Internal || d.Type == LocationType.Hospital)
      .Average(y => y.BillAmount);

His method had a bunch of for loops, accumulators, etc. that basically did the same thing. I thought this was a great opportunity to show him some basic .NET 3+ stuff, but his response was just "So? That makes no sense, why would I want to do it that way? Mine works, right?" When I asked him if he tested it, he said "sure, I ran it in our dev environment and it worked ... why would I write even more code to verify that something I know runs works?"

These two guys have been there for 15 years, and know the systems inside and out. Upper management would never let them go, particularly because they know that these guys' apps never break. Any suggestions for getting these guys to follow a more modern approach, or is it hopeless?

+62  A: 

Sounds to me like an immovable force. If their code works, and management loves them, maybe the best thing to do is to turn a blind-eye, pray that you don't inherit one of their projects, and focus on making your code leaner, faster, and better.

Jonathan Sampson
Lead by example. I like it.
+1 I agree. I think that by recognizing the issue @Andrew is already ahead of the game!
I'd have to agree. As others look at your code they'll notice that it's better (if it's truly better).
Esteban Araya
Yeah, I haven't had a problem convincing the other devs to follow a better approach, but it's been interesting to try to isolate the two senior guys to projects that don't impact the rest of the team (I'm their supervisor as well).
Hm, agree. The whole point of fancy new .NET stuff is that it gets you the same result faster, easier and more maintainable. So... prove it.
+1 Keep your head down and learn.
Tj Kellie
+1 Trying to teach a pig to whistle is a waste of time and it annoys the pig. How much code could they write in the time it takes them to learn unit testing, OOP and other modern practices? How much code could you write in the time it takes to convince them?
+21  A: 

Particularly because they know that these guys' apps never break

End of story.

+1 "Sad but true." I knew all of that Metallica from my youth would make sense someday.
Jonathan Sampson
Not end of story. You've got to consider what will happen when someone besides them tries to add functionality in the future, and they've got to hack apart a 3000-line method.
Kaleb Brasee
Indeed. They should follow courses until they can write *maintainable* code that never breaks. Management might like them, but when push comes to shove, management likes money more.
You are going to get downvoted by everyone who worked with somebody who had "working" code that couldn't be modified.
@Kaleb - there's actually one function that is >10,000 lines. I've had to modify it a few times (when the maintainer is on vacatioN), and it's a bear. This single fn handles all the core automated web billing for our company, so it's ridiculously critical.
At one job, there once was a guy whose code never broke, although it was unreadable. He has left, many moons ago. Monkeys were hired to hack in new functionality. Now there's a huge blob of code that sorta-kinda-almost works (when the stars are right) AND is even less readable than the original. Nobody is brave enough to go in and mess with it, lest they break critical (as in, "if-this-breaks-the-company-likely-goes-bankrupt") functionality.
How is that, in *any conceivable way* “end of story”? When was “never breaks” ever the only requirement? And who redefined “never” here, anyway?
Konrad Rudolph
-1: Yeah sorry, not end of story. Maintenance includes adding new features not just bug fixing. So unless those two guys want to implement **all** the new features on **all** the projects they wrote you're going to need a codebase maintainable by mere mortals.
Cameron MacFarland
+4  A: 

It's certainly going to be difficult. I only had one of those nuts to crack and it took me 3 years to do it and we're still hammering the finer points of OOP, n-tier client server/etc. He's starting to drink the kool-aid, but it has taken a lot of brow beating and a couple of disasters for it to occur. It also helped that he was outnumbered. He was 1 senior lead among 6 that was still using older techniques.

I'd say keep on keepin' on. Persevere. Try to get one of them onto a project that you're running. Set the standards and refuse code that doesn't meet the standard. For my guy, I flat out refuse to assist with old methods. I'll explain how I'd do something or look at a problem, and the moment an older technique comes out I say "Awesome, have a blast working that mess out."

Good luck with it.

Joel Etherton
+2  A: 

[No answer, just musings] Maybe they might get interested in PLINQ, or anything out of PFX-stuff from .NET4. You can dangle some really cool tech and they might jump at it. These guys might like automatic parallelism.

They are smart folks, but they should understand that the largest contributing factor to bug count is line count, in any language. I wouldn't believe that their code is "perfect", the bugs just haven't been discovered yet, you know they're in there.

The largest problems with the pure procedural approach is that is doesn't solve all problems and it doesn't interface with the rest of the system very well.

Nice Lambda by the way.

Edit: Actually, some concrete advice for you: get into the habit of discussing hardware with them, i.e. cache coherency, SMP, architecture or whatever and how it relates to "new" programming tech. If nothing else, you'll have exciting conversations, but maybe they'll be more willing to listen to your code suggestions.

Chris O
Between the two of them they have contributed over 1,000,000 lines of code that are still in production, ranging from old 16bit DOS C to COBOL to .NET. Given the scope of our organization, it's uncanny how little blows up. We're talking like 5 critical bugs in the 9 years that I've been there, vs. ~100 for the other 6 members of the team. One thing they've taught me is that it's much harder to make mistakes if you understand the business, rather than just understanding how to develop/design. On a different note, you can probably tell I've drunk the kool-aid on new .NET features, I love it.
@Andrew "contributed over 1,000,000 lines of code"... nice. With that track record "why mess with success?", these folks are extremely good at what they do, so exploit this great talent.
Chris O
@Chris - That's why I usually stick them on code that somewhat makes sense to be procedural ... like ETL stuff and reports. These are often ridiculously complex, to the point that other devs really struggle with testing it.
@Andrew - Be interesting to put them onto something that really lends itself to the OO and see if they can deal with that... As people have said they seem to be doing a good job, the only way you'll get them to accept change is if they decide they need to do it.
+6  A: 

Depending on their character, it can be very hard to teach a senior developer anything new. IME, it requires foremost a lot of patience, and holy communications skills. Hanging out with them in bars might also be a good idea.

Edit: I wrote it jokingly, but I'm actually quite serious. In one way or another, you need to open up a dialogue with them. They will be reluctant, but you are their manager, and you not only have the right but the obligation to ensure their productivity since you are responsible for anything they produce. In this dialogue, it is foremost important that you listen to their arguments for doing things their way. Otherwise, they will not even bother listening to you. After that, bring up your arguments, and listen to their defence. It will be tedious, but if your arguments are sound, and your tactics are good, you should be able to make your point to them in time.

@littlegreen - nice one. Neither are drinkers though, both family men that do nothing but work and chill with wives/kids. We are all on good terms though.
Minor comment, "very hard to teach a senior developer anything new" not always true, I work with a fair amount of "older" developers, they are quick learners and quite open to change/new concepts, it is a real pleasure to work with open-minded people.
Chris O
@Chris O: it **can** be very hard.. luckily most seniors aren't that way. I happened to be stuck though with a very narrow-minded senior in my previous job - and the only thing that helped with him was very, very careful communication. Many seniors have seen so many "young dogs" come and go, and received so many suggestions, that they've developed a filter for these things. It's a challenge to still make your point to them.
+1  A: 

Programming != development. Programming concerns the correctness and efficiency of the code, which they have down. Development concerns the correctness and efficiency of the development team, which includes the affects one developer has on other developers.

You could try to convince them of this or find some way of piquing their interest. However, after 15 years it's possible that development is just a job to them, making this quite hard. See if you can find out what, technologically, makes them flush with excitement.

+19  A: 

It sounds like these guys write code that is more reliable than yours, without even writing unit tests. Management also seems to emphasize the reliability of code developers produce over efficiency. If these guys are as slow as you say, you should be running circles around them in terms of development time, and have more than enough testing time to make sure your code works.

If your code is less reliable than theirs, you'll need to slow down, because in your environment, reliability is king. Maybe these guys stick conservatively to language features they have absolutely mastered because they know they can write bug-free code that way, and they have learned over time that dabbling in the latest and greatest techniques means a major bug more than once a year.

Eventually your experience and suite of unit tests will make you even more reliable than they are, and you'll have room to talk. You'll develop a reputation with your managers for being both fast and reliable. You can probably negotiate for nice raises based on that fact, but once again, don't expect management to crack down on employees they see as reliable contributors. Unless you can credibly argue that these guys are being grossly inefficient through laziness, you have no leverage over them.

But then, let's back up a second. How long have you been in this position? Is there a culture of coding excellence at your company? There is the possibility that these guys just want to put in their time and collect their check. That isn't what you or I would want, but there isn't necessarily anything really wrong with that, and there might not be anything anyone can do about it. If that isn't the kind of person you want to work with, and management doesn't care, you might have to change jobs.

No, it's about the same reliability as mine, but far more reliable than the rest of the team. The only difference is that I code about the same amount as both of them combined, and still have time to manage the small team. I guess that's why I get paid a lot more (>2X more to be exact), but these guys don't really care, even when I tell them they could get an increase in salary if they start changing their development approach.
Yeah, I hear you. If the prospect of doubling their salary doesn't motivate them to learn, and they aren't inclined to do it for its own sake, you're low on carrots. And it sounds like you can't use sticks because upper management wouldn't have your back. You have exhausted my storehouse of advice!
Dang, I'm be all over doubling my salary :) Sign me up.
Alex Baranosky
+2  A: 

You mentioned in a comment that you are their senior, but are you their boss?

Start writing tests for code assignments they've been given and let them know you will not put into production until it passes. You may catch one of those rare bugs. This may also shorten your code review; they might like that notion. Next, have them write a test, do a code review on their test which should not take as long. I can't imagine they enjoy code reviews with you.

Show management some numbers. How long you take compared to how long they take to write the same code (I mean code that accomplishes the same thing.). The effectivness of code test in avoiding bugs. Are there performance issues in their code compared to yours? Can you get user feedback indicating how some sections of the application take so much longer than others. Maybe you can come up with some specs as well.

Find one simple coding technique that you know could replace a lot of their code. Make them implement it in the next code review.

If upper management doesn't mind spending more money on projects because these guys take so long, you need to put in for more vacation because profit is not important to this company.

Jeff O
+120  A: 

This has little to do with being "senior" and much more to do with attitude and motivation.

I'm 64, I've been at it continuously and professionally since I was 18. I can still outdo most folks with less experience. The keys are never stop learning, the joy of productivity by using great tools and techniques, and the experience to know what a blind alley looks like before entering. Some new stuff is shit and I can usually tell. "Getting it" requires active learning. Oh, and you can't fall victim to the "I don't have time to learn how to save time" syndrome!

Your cement-head co-workers stopped being professionals when they stopped wanting to be better at what they do. They're frozen in time and should be eased out of critical-path positions.

Bob Denny
Want to join my team? ;^)
Finally someone that makes a strong point. It's not a question of how good you are or how much you know, even if that is a good point. It is more of a "are they right to team" question. Even though they do make the code work, but stil is a crap non stoppable code. The just "stable and 'secure'", are not parameters for a good code. Perhaps in another time it was. Bob knows a thing or two when he says: "Your cement-head co-workers stopped being professionals when they stopped wanting to be better at what they do". They are bad examples, and they might be influencing other developers. Be careful.
Very well written, Bob.
Spot on I am in the same boat. I make sure I learn something new everyday. Even in different aspects - last week I coded an isometric world in Flex.
Ian Warner
I like working with people smarter than me, it keeps me on my toes . . . good thing I don't mind being out numbered :)
Binary Worrier
Technically - this is not an answer. On the other hand - short "You can't" would be misunderstood and down voted furiously.
Arnis L.
Bob, You sound like someone I would enjoy working with. Great answer.
I fully agree with you on this Bob. Nice response.
I agree with most of the response, but sometimes people can be rehabilitated. Most likely those guys have stagnated because they have been there so long. Could you share some of the ways that you keep motivated that the OP could use to maybe encourage these guys?
Andrew Mellinger
Aren't the upvotes just sign of sympathy? ;) Regardless, this is truly a nice answer which represents the *real world*, +1.
Thanks all ... Andrew, I keep motivated because I truly love what I do. Not a day goes by that I don't look at my systems and other stuff and say to myself "this is amazing". And it is! When I learn something new it's like getting a new gadget that opens more vistas for my creativity. If I can do more per unit time it means I can solve problems in more ways and maybe find an elegant solution!
Bob Denny
+3  A: 

Joel Spolsky wrote a great article on a very similar topic: The Duct Tape Programmer

My take: it's not really broken so why try and fix it?

Think about your programmers as a black box resource. Input goes in and output goes out and it always seems to be correct. Now the contents of that black box may be a Rube Goldberg invention but why worry yourself over that? Just use them as a valuable resource. Your attempts at trying to make them more efficient will more likely than not result in lower productivity. Heck, i would even support their hackery.

Final thought: i suggest that you look think about you point of view as a religious argument similar to Java vs. C#. Which one's better? Does it matter to the end user? As far as modern programming processes go, yes, there's a school of thought solidifying out there that preaches (correctly IMO) TDD, OOP, MVP, ETC. but in the end we just need to get the work done. And no end user is going to ever wonder what's under the hood as long as the hour glass doesn't turn too long.

Paul Sasik
Good point, but if you ran a .NET development environment and one of your developers kept submitting Java code, wouldn't you be concerned? It's not quite that bad, but their code is borderline impossible for anyone else to maintain.
Java just plain wouldn't work. i'm trying to frame the issue in a way that it might just be best left alone. i'm wondering though, is maintenance a real issue? And if so why not let them handle it and show them how such maintenance could be improved with better structured code?
Paul Sasik
The just ship it mentality can lead to lawsuits later on lol. Find a middle ground! (ABC Software Company) "We're sorry to inform you that your identity has been compromised because of our rush to get our product out on the world wide web and make a profit at your expense."
@OutOfTouch: i am not at all trying to espouse "just ship it." All i'm thinking about is a way to compartmentalize the issue and make it workable. Don't forget that Andrew's question mentions that these guy's work is of a high quality and that is a core assumption for my suggestion. If these guys sucked and had no respect in the management my answer would have been quite different.
Paul Sasik
+2  A: 

If at all possible, you should try to add tests to their code. If not unit tests, at least integration tests. It's all well and good that their code works now, but what happens in the future when they're not around, and someone has to add functionality? Even a few tests have a decent chance of letting future maintainers know if they've broken something.

Kaleb Brasee
+2  A: 

I have had exactly the opposite problem.

I had a bunch of pure Java OO developers who refused to use SQL for manipulating sets in our tables and insisted on populating collections of line item objects from the database, filter them according to some simple criteria and agregate a single quantity from the collection.

They were reading more rows than they needed from the database, they were reading in columns they never used, the whole thing would have blown up when they hit production volumes -- but hey reuse is kool and SQL is so yesterday.

I quietly replaced their mess of six or seven interdependent classes with a 30 line "JDBC" program which fired off the appropriate SQL before the system got to UAT.

James Anderson
Thank you, thank you, thank you for saying that!
+44  A: 
How do you teach a senior developer how to be more efficient?

Wait a minute, from what you yourself said it seems that their code never breaks, that they produce a fraction of the number of critical bugs as the other developers, and that management values those accomplishments.

Shouldn't you be at least as interested in how you can learn from a senior developer as you are in how you can teach one?

Good thought ... I try to do both. These guys claim to have 2 secrets to their success: write almost everything in a single fn (hence the source of our many 3000+ LOC functions), and know the business REALLY well. I contend that the 2nd point is far more valuable, and have followed that myself. As a a result I can cover twice as much business functionality with the same level of quality as these guys, while using unit tests and still having time to manage the team. They have the skills to do the same (both write far more LOC/unit of time, but it's very inefficient), but lack the interest.
There are advantages to single funtions. Badly designed modular code is an absolute nightmare to deal with. Whereas a single big function can be more explicit (as long as you wrok with it long enough to keep the whole thing in your head). Encourage them to modularize functions (i.e. anything that won't have side effects) so their code is easier to read. Baby steps.
Andrew, in all your comments you're rather taking the position you're right. Time to learn from them.
I take it this company doesn't add new features that often. Large code is impossible to change. Unit tests are a trick to help with code that changes a lot. It would seem useless to these seniors if the code doesn't change once written.
@Andrew. LOC is not a measure of productivity. You say they write far more LOC/unit time, but at the same time you complain that their code is too verbose. A better measure would be working features per unit time. And keep in mind that .net didn't exist when these guys started, and will not be so popular in another 15 years.
While code stability is a good metric to judge the performance of a developer by, so is maintainability of code. 3000+ LOC functions/methods are inherently fragile, and therefore unmaintainable, even by the original author -- given sufficient time between writing and maintenance. Verbosity, on the other hand is a double edged sword. On one it can ensure maintainability, on the other it can obscure it. Finding the right balance is tough.
Jason D
+18  A: 

i am, frankly, amazed. On the one hand, writing a 3000-line function with no bugs is extraordinary - and hard to believe. Have you verified this claim with your own unit tests?

On the other hand, if you showed me how to replace a 100+line function (though I would never write a 100+line function!) with 3 lines of LINQ I would buy you lunch, and a book on LINQ.

If I understand the situation correctly, these gentlemen need retraining. Please do not write C in C#! [Yes, I know, "real programmers can write FORTRAN in any language", but professionals don't]

If you're their boss, but upper management doesn't support staff improvements, you should bail, and bail fast.

Steven A. Lowe
Steven, thanks. The company is great, and the rest of the team is great. I try to focus on results, and these guys produce good results/$ pd. If someone else had to maintain their code they'd scream though. I haven't written the tests to verify their code, but QA has never found any faults and we've only had ~5 serious issues with their stuff in the 9 years I've been here. Pretty good track record. A 100 line function is atypical for these guys too ... it's rare the'll write one with <1000 lines. Their longest is ~12000 lines, runs our entire billing process. Impressive, but scary.
@[Andrew]: if you're serious about demonstrating the value of the techniques you want to teach these fellows, I suggest that you write unit tests for one of their remarkable functions (like the billing process) and note any bugs that if finds, then refactor the code to take advantage of C# language facilities and re-run the tests. If you find no bugs and can't refactor the code, then leave these savants alone. Otherwise, use it to demonstrate that you do have something to teach them. I'd be surprised if 12000 lines of C-style code was actually necessary in C#!
Steven A. Lowe

Nagging might work. I bet you that these guys hate meetings more than anything. Push for a policy of code reviews.

They may soon realize that difficult code takes longer to review.

Also consider changing their code to "aid readability". They'll really hate that.

+30  A: 

Personally, I think this is a living example of Joel Spolsky's Big Macs vs. The Naked Chef essay from so many years ago.

Rigid processes are useful for floundering developers who write a lot of buggy code and need a constant guiding hand. When you have development leads who can run circles around the vast majority of programmers in the wild, the worst possible thing you can do is stifle their talents by forcing them into a process they hate or that goes against their way of thinking/working.

Don't get me wrong, I'd personally go insane without lambda functions; but great developers are more important than whatever methodology is currently in season. Which is better: a zillion unit tests that all pass, or a single cohesive application that actually does what it is supposed to?

This is a great thought, thanks.
unit tests of course!
Arnis L.
+1  A: 

The corporate answer is: it can be done by relating salary to performance according to an established norm. That means you need a design standard that is endorsed by management, a review process for code that is based on the standard, and performance reviews to set salary that relate, at least in part, to good outcomes in this process. You can augment these things with statistics relating to bug count in code and time to repair. If your contention that their code is unmaintainable is true, that will be reflected in the statistics. if you gather good statistics and they show that bug count and resolution time are reasonable, you do not need to do anything.

The personal answer is - it is probably not worth the aggravation. Programming is based on personality, which is not very malleable in a mature person. The result of following the corporate line is a colder, less friendly workplace in which you have forced people to do something they didn't want to. You might not want to work in that place. You certainly would not get any thanks for trying change their ways.

That is not to say you should do nothing - you can proselytize, and hope something sticks. But there is no royal road. I have had a related experience with trying to get people to use boost pointers to help avoid memory leaks in my company for years - it is truly remarkable how resistant some people are to using them, or even considering that it might be a possibility.

+2  A: 

Go fix something that is broken.

These guys are not a problem. Focus on making their job easier, but let them run.

-1 This is treating the symptoms, not the cause.
+8  A: 

First off, this is a function of temperment, not age. I've worked with developers 20 years my junior who resent having to learn anything new. To this day, I'm stuck writing code that interoperates with Btrieve because the owner of the application played around with SQL Server for a while in 1997 and decided there was nothing there he needed, and he wasn't even 40 yet at the time. (He really never got over the trauma of porting the app from COBOL to VB3, which it runs under to this very day.)

A lot of people feel that the bargain they've made with their employer doesn't obligate them to improve, and that their actual goals in life aren't tied up with their profession. They aren't necessarily wrong, mind you. There are employers aplenty whose performance on their end of the bargain deserves no more than that.

On the other hand, even people counting the days to retirement embrace change if the change will stop them from hurting. These guys will learn LINQ and design patterns and anything else thrown their way if it makes their job easier. Right now, they don't. If you want to change their practice, you have to change the structure of incentives. It has to become expensive to not do things more efficiently.

Not monetarily expensive, mind you. But expensive in that it deprives them of things they like and piles on things they don't. For instance, programmers hate meetings. Is there a way for you to contrive things so that the longer a programmer's methods are, the more time he has to spend in meetings?

Obviously a workable solution won't be as transparently manipulative as that. But if you can implement procedures that are annoying for people who don't use LINQ and shruggable for people who do, people will beg you to teach them LINQ.

I got 8 developers working under me to wholeheartedly embrace XSLT by doing this, and XSLT is horrible. (Also, horribly, I love it.) So it's got to be possible to do this with LINQ.

Robert Rossney
VB3! . . . OH MY GOD! There is no emoticon for how this makes me feel!
Binary Worrier
+2  A: 

Perhaps it would be useful to explain that, while their code is rock solid, it's impossible to maintain. They seem to pride themselves on being really good programmers, so explain to them that they're leaving the task half finished. Unit testing and documentation are programmer responsibilities. At least they should be.

Ask them some questions. Something like this: 'You wouldn't hire a carpenter that put up the frame of a house, and then abandoned you to work out if the frame was good enough to pass the relevant building codes, right? Why should I accept your work when you're leaving me to go find out if it's good enough? It's part of the job, and only doing half of it isn't good enough. Even if the half you've done is superb.'

+1  A: 

Writing in a single fn does not guarantee a bugfree code or neither does a sturctured code. You said they understand the business well. That is the point that needs to be considered. These guys understand the business so well that writing code for it seems like a piece of cake for them. Another reason for their current coding style can also be the result of job security. If they write maintanable code with their bug rate they can easily be fired or relocated to another job position which they might not like.

Couple of suggestions would be

  1. Tackle one by one, take one of the guys and handle him personally, keep drilling the advantages of code refactoring and latest features of the technology to keep his/her code clean. If you get one into your bag, the rest will follow.

  2. Another way is to reject their code changes until they write clean, its aggressive approach and it might backfire on you.

  3. Convince them the writing clean code is not going affect them in anyway.

  4. Last but not the least, if they understand the business so well, maybe they should analyze the business and the requirements for other developers.

+4  A: 

If they are good at what they do then perhaps we could learn from them instead of trying to teach them. I am one of these grumpy old men myself and although comfortable with OOP, I still use assembler to write Win32 applications and hardly need to use a debugger.

These days, the answer to "what did you write this application in?" is "the debugger!"

Trying to reduce the development time is false economy and most of the current methodologies, patterns, OOP, this, that and the other are developed to satisfy the accountants not the end-user. We usually end up with systems that are expensive to maintain and what we saved on the swing we spend on the roundabout.

If I ever end up in Intensive Care Unit connected to a computer which keeps me alive, I prefer one of these 3000 line functions written by your colleagues over the latest lardeeda instantiated over-ridden multiple-inherited encapsulated marshaled watchamajingies that has the same 3000 lines hidden under multiple layers of abstraction out of sight and out of mind.

You may say I have no class (duh!). But I already know that!

Square Rig Master
Do you really still use assembler to write Win32 apps?
Yes. And I am not alone. There is a very active group that do this. Here is an example It is easier than everyone thinks.
Square Rig Master
win32 assembly.. you have no class my friend, but you have style! :)
+4  A: 

Get these guys to do your code review:

  1. you can learn from their experience
  2. you expose them to the new ways, and make them familiar with them
  3. they will help you ensure the quality of your code

All win, even if it doesn't change their ways.

+1  A: 

Since your their Senior, give them a small module. They will write 1000 of lines and it still works with negligible bugs. Then you come up with another version of code that implements all the newer stuffs of modern technology. Add a new feature to the module which needs a complete rewriting of their code but a little addition to the code you wrote. Say them this is Why your insisting them to follow the new stuffs of modern technologies.

There can be numerous way to attain a goal but simple, easiest and which can be followed by others is the right way.

Sri Kumar
+3  A: 

Have them write extensive comments for their functions. Tell them you need the comments in a way that an new guy in the company would understand the function with just one read.

That way the code will be more easily maintained and on the off-chance they realize that they spend more time writing comments than code they will start coding better just to avoid such a hustle.

Since you are their senior you will have no problem enforcing the above rule, even if they object and take it up to management.

+1  A: 

Perhaps you should settle for getting them to comment their code extensively, so that all the idiots like yourself can have a chance of cracking into it?

Not that you're an idiot, but a position of humility, and a spirit of exchange will get you further than the attitude that they're just doing things wrong.

The fact that you're unable to satisfactorily explain why it's wrong, or what the benefits of your methods are is telling. Teach one thing at a time, and make it something that is genuinely useful, not just a load of more work, or some pile of new crap that you have to learn.

Is there much duplication in their code? Refactoring out duplications into their own methods (using the rule of 3: don't refactor if there's just one, or two, only when there's 3 duplications), will definitely reduce bugs and make maintenance easier.

When you give them an assignment, hand them a premade test suite, and just tell them their code has to pass all the tests. Try it once, on a small thing, as a trial. They might like it.

+27  A: 

These guys take pride that "their code doesn't break", that's good, that's not a problem. You need to point out to them how easy it is for someone else to break their code, it might have been some other dev making the change, but it's still their code that's broken.

The next time you get the opportunity, do this.

Get them to make a small change to an existing app that has unit tests, where you know this change will break some tests. e.g. Change the signature of a method AND it's internals.

They need to fix the tests to get the app to build, and I’m assuming the tests need to pass or the build will fail then also (if not this is a problem with your Build Process that you need to fix).

Review their code, and especially the work on the tests, did they remove any "inconvenient" test coverage, are there any big holes in the test coverage for the new functionality etc.

If so then this is exactly what you want. Sit them down and explain to them that the tests aren't for them (because hey, you know their code is good), they're for other developers that may change their code, or code that has a knock on effect to their code.

The tests verify that someone else hasn't broken their code.

Binary Worrier
+1 : Nice idea, frequently it's unit tests on other bits of code that people have written that spot a minor glitch in things I've done. Unit tests are just as good when you creating code as maintaining it later.
"The tests aren't for them" might not really be true, but it might be a good way to get them to hear the message. But if they don't want to learn, there's only so much you can do.
+9  A: 

Seems to me you don't need to be worrying about teaching the "senior" developers at all.

Let's just say they both suddenly decide LINQ and functions shorter than 100 lines are the best thing since sliced bread. Great, now you and your team are now on the same wavelength.

You now go to management and say:

"You know that 3000+ line business critical function that takes us ages to make changes to? Well we as the development team would like to re-write it using modern technologies and better design practices. What do you think?"

Management reply:

"How long will it take and what tangible costs will it save us?"


"Ahhh, well before we can give an estimate we will need to do a thorough analysis of the existing code and build unit tests over it. Once this is done then we will then know how to best make changes without breaking existing business rules."


"Oh, sounds like a bit of up-front work. But it currently runs pretty smoothly and it has caused us very few problems over the years. I'm not quite seeing where the real benefits are?"


"It will allow developers to make enhancements and do bug fixes much more quickly. Also, when developers leave the company the people they handover to will be able to understand the code much more quickly."


"OK, but those are benefits for developers only. What benefits will it give our customers?"


"As I said, it will allow us to do bug fixes and enhancements more quickly."

Management, now with a bored expression on their face:

"OK, thanks for your feedback, well take this off-line and get back to you."

6 months later:

. . . . .

So run a toy project "what good is LINQ" in which you write a small app both with and without LINQ and measure the difference somehow.
+1  A: 

I've had similar experience too. It's almost impossible to get my senior to listen to me. He always play the "it works" card and say I can implement myself if I think his way is wrong... which is a waste of time. Even simple things like giving functions distinctive names so people don't accidentally call the other (which I did), he just won't listen. In my case it was something like CommitResult() vs CommitResults()... he could've named the latter CommitMultipleResults()! I spent hours debugging that. Plus the other function haven't been in use yet, so there is absolutely no need to search and replace. He simply replied "don't use the other function, just leave it there".

Well he's the senior and like OP case, he knows the system inside out... so I gave up and that being one of the reasons -- I quit the job.

+3  A: 

There are two kinds of people in this regard: there is the "team guy", and there is the "solitaire professional". It seems that the two guys you have mentioned are of the later, and no matter how good they are in writing code, they are putting your team into danger. Your team will inevitably find itself in situations, in which it will have to take desperate measures to make it. Just recall the time when you had to modify the code of these guys in their absence, and you will get an idea of this.

If you cannot change these guys, your only solution remains to say good bye to them. They are good people, as solitaire professionals, but they would cause your team to fail.

If management can’t see this, their company will not survive on a long term, or will remain small, and they will never be as successful, as they could become. If this is the case, then this might be a good time for you, to start thinking about a new job, as you deserve a better team to work in, which is not that limited.

+1  A: 

Can you get authorization to send them on some courses? How about setting some specific goals in their annual appraisals - and making their salary raise dependent on actually working towards those goals?

One thing though... it might take time even if they were willing. Changing how you do something after decades is not easy. Getting them interested is the key part.

+1 You took the words right out of my mouth.

  Perhaps someone said that, but, you might try to improve the rest of the team, and make them as reliable as those two developers.
  If your management goes for reliability, you need more of you.
  Try to improve those who want, make crash courses, lunch-n-learn classes, I don't know.
  If they are an unstoppable force, so will do you and the rest of your team.
  In little baby steps, you will succeed.
  The most important: get allies, endure yourself and don't give up.

  I wish my boss though like that, in here, i have the same problems as you, and I don't get paid more.
  Perhaps that's why I am thinking on leaving...

+2  A: 

The phrase "you cant teach an old dog new tricks" comes to mind - but I don't mean that in a bad way. If someone is very experienced then often its difficult for them to unlearn old habbits, but a good developer with 10 years experience who might write slightly versbose cose is still going to be vastly superior to a frash developer who does know how to use lambda expressions but only has a year or so experience.

Definitely don't take it upon yourself to try and teach them to use the new "superior" syntax - if you force it down their throats then its likely to be met with resistance. If on the other hand you just make them aware that it exists then you will probably find they adopt it themselves if and when they appreciate how it will benefit them.

+3  A: 

Wow what a kewl question...

Well this is my 2cents:

I would have developers that are on par with my way of thinking and have them shadow the senior citizen developers until they understood all of their work. Then I'd simply fire the seniors for being outdated and have the shadows pick up the slack. This happens alot in companies where management wants to get rid of someone that they can't get rid off; the give them people to mentor: i.e. train to do their job.

You can justify to management that you need to train other people to do their job because it is posing a HUGE risk to the code base if those individuals suddenly die. You can justify that if they depart this earth there will be no one who can maintain their code. It's a good business practice to ensure that your organization doesn't have people who are irreplaceable; even at the CEO level. Irreplaceable people create points of failure in the organization that could cause the collapse of the company. You wouldn't build a computer system today that relied on 1 single machine that had 1 special thing about that that allowed the entire system to operate fully. You would have at least 2 or more such parts in the event that the first part fails.

If management still doesn't budge then you could always throw in the old "By doing the code this way anyone and their dog can maintain it. In that regard we can save money by hiring cheap labor" Saves money = It's got my vote :)

Also what happens if said individuals suddenly realize their importance and begin making demands on salary and benefits? Time to Panic?


You could remind them that as a race we've only been able to get this far through progress, which is a process of change over time. Change being the only constant.

+1  A: 

I recently read a book by Dr Spencer Johnson, called Who Moved My Cheese. It is a book that can be read in just a couple of hours but makes you see change as an opportunity instead of something that has to be avoided. Buy them this book and encourage them to read it over their lunch breaks. They should be begging you to teach them NET 3+ in no time.

+1  A: 

I've thought of that, perhaps you need to tackle this with a little help from psychology of your pupils. Engage them in a quality discussion on better performance and code writing with the junior members. Let them come up with what ever they can and be a moderator and lets c what advices they can come up with for the junior resources. Now you have a reference point for them which you can quote to them and devised a quality standard for the organization.

Pretend that you are not trying to teach them a quality lesson but you are trying them to teach you and the junior resources about their idea of quality. Once they think they are in a leading role and are not being forced to follow a particular standard then they will be satisfied following the quality standards they think they have devise and implemented.

S M Kamran
+1  A: 

"Hey, it works, right? What's the problem?"

I would like to add a more practical point of view about this.

Since they are probably highly paid and can produce bug-free code, why do not leverage their strength and ask less experienced colleagues to write either wrappers or unit testing for them.

It would be somewhat a waste of time (at least in the short term) to make them change their habits. And it will be a waste of resources to ask them to write the unit testing.

As long as you wrap their code in appropriate interfaces everything should be fine, isn't it ?

Alternatively, the best way to make them change is to hire people who would be more productive because they use better methods, this would show them how to leverage modern methods to improve. As long as you cannot make this point, they will never change.

+3  A: 

Procedural programming is not wrong. Maybe you're better off insisting they don't create massive functions, than try and force them into OO and modern language features they might simply be too stuck-in-their-ways to learn effectively.

Would you prefer they write good procedural code, or bad OO code?

I'm not sure why you got downvoted ... most of the stablest software in the world is procedural.
+1, and good comment Andrew.
Marcus Lindblom
+2  A: 

It sounds like the problem is not that these developers are inefficient. I mean, their code never break, and well these 100 lines of code that you could write with a couple of lines using LINQ might not take that much longer to code. I rarely find that my typing speed is the limiting factor.

I do think that you have a case here, though: Their code is unmaintainable. So my suggestion is to switch strategy and focus on this point when you try to convince your superiors.

Jan Aagaard
+2  A: 

A third train of thought on this one...

I don't believe their code is unmaintainable or unreadable. Sure it makes it harder to get to grips with but remember a decent developer given the sole task of "understand this code" will be able to do it. Maybe it'll take days rather than hours, but in the grand scheme of things that's not the end of the world. Besides, having lots of classes can take time to get your head around too. And if you are actually having to make changes at a few hours' notice, that's probably a bigger problem in your system.

Developers are dumped on legacy code-bases with loads of uncommented huge functions and nobody to ask all the time. It's a specific skill that not all developers have, but many do. Lock a skilled developer in a room with the code and he will figure it out.

After all, a hacker can figure out your code and modify it from the raw .exe. You're spoilt to have the code at all!


You may try to introduce rejection from code ownership. E.g. anybody can write any code at any place of project. It is not "mine" or "yours". It means that team should use same naming, same principles which is understandable for both of you. Maybe you need to reject using of reflection, for instance

Motivation could be - let's say you will get sick/hit by train, but we need this fixed/changed/improved.

Sergey Osypchuk
+2  A: 

Explain to management that they are buying something that can't be maintained once these two "geniuses" leave, which will happen sooner than later given that they have 15 years in the can.

fuzzy lollipop
+1  A: 

The starting point is the business objective. Are these developers, on the whole meeting that objective, or should they be replaced? If they are to be kept, the ball is in your court to persuade them with carrot or stick. You should consider how are communicating you ideas/directives. Just telling them then waiting for the final build for the result is a failure on your part, if that is the case.

We all have limits, these people may not be able to change in the way you want them too. It is only natural. I will never be a good sales rep no matter what 'they' try to do to me.

This is a very tough leadership challenge, and you will learn a lot from it.

  1. Write some performance tests. It will be exposed that their code takes more time to execute if not taken use of the new features.
  2. Also no application is bug free, there should be some way of breaking it. (That may be an extreme step)
Actually, performance tests will almost always show procedural code to be faster than OO code (although it's usually negligible for non-scientific apps). This is why kernels, games, scientific apps, supercomputers, etc are all written with low level C procedural stuff.
+1  A: 

Assign these people to one or two people subprojects. If you can't find one person subprojects and have to assign them to two people subprojects, team them up.

If they fail to deliver the projects in reasonable time vis a vis the project schedule or they deliver extremely buggy code, then you can fire them.

If they deliver on time and non buggy code, give them another similar project. Keep it up, and don't worry about them. If they screw up after say the tenth project, well they will have caused less trouble then most of your people.

Thanks, that's what I've actually been doing!
+3  A: 

Set them to fix each other's bugs, and to make enhancements to each others' projects. Each will see that the other produces unmaintainable code, and may even take the hint.

John Saunders
Heh, like this idea. Actually, the real solution here is likely that after the nuclear fallout between them clears ("your code is wrong!" "No, your way is stupid!"), only one will be left... Already solved half your problem ;)

I gave up on trying to teach unwilling people anything.

The key is to have the pressure come from some direction that matters, like the management. You could try explaining to management the issue of maintaining code fo theirs...

So it doesn't seem to me to be the problem that these guys don't unit test, or don't do this or that methodology. The problem is that their code, while working great NOW, will be a dang disaster for any other person to go in and add or augment features on.

Alex Baranosky
+3  A: 

I had a similar experience with senior developers who would only write low-level C code, although we were supposedly using C++. I even found many cases where char buffer could be overflowed with strcpy, it just never happened to break anything. They didn't write tests for anything and heck, the version control they used was memory stick. But still, their code always works and does the stuff it is needed to do. So it doesn't matter!

... until YOU need to maintain their code. Not slightest idea what was changed last and why, and if you aren't experienced with C style coding and 3000 line functions, you will almost certainly break something trying to make a small change, or at least spend days figuring it out. That's why developers should keep in mind the others who might be reading the code someday.

But to your question, making people to do it in your way is usually extremely difficult. Attacking against their style will definitely not work. Judging from their harsh answer to your example, they probably don't like you in the first place. At least, they don't want to take advice from you. Become friends with them, make them like you and be more productive than them. Their attitudes might change.

Compare friendly "Hey, check this out, I found out that you can do this same stuff this easily with this new LINQ thing" vs. formal "Your code works but it's wrong! You should do it like this." coming from someone way younger than them.

Well, if it's really hopeless and you can't get over with it, quit. That's what I did (having also numerous other reasons).

Their answer wasn't harsh at all (more of a "why would I want to do that?") ... and we're on good terms. Thanks for the thoughts ... this certainly isn't something I'd quit over, just trying to figure out a different way to approach it.
+2  A: 

Wow! There's three things that sticks in my mind

  • Resistance to change
  • You can't teach an old dog new tricks
  • You can lead a horse to water but you can't make them drink it

By the sound of these senior developers, they have been in the business long enough and know exactly how the system works and that the management are relying on them, consider that the management view them senior developers as 'the backbone' in getting the code to work and producing bug-free code.

Resistance to change Well, what can you do? I wouldn't force it down their throats and make them rewrite their code to use the 'newly fangled technology', in one aspect, they are right, as the code works and the management knows that their software are stable which equates to happy satisfied customers plus profit! On the other hand, showing how it is done using Linq, they are probably wary (who can blame them?) and mistrustful of the new technology unless it is proven solid. Don't force it on them, just drop subtle hints in a very discreet manner, you will be surprised, they will approach you down the line begging to know what is the fuss about Linq and other new fangled technology.

You can't teach an old dog new tricks This is a tricky one, again, no one should ever be forced against their will to train them to the new technologies, and by the sound of the way you dealt with it, you did the right thing but.... do not get hung up about their response 'So? That makes no sense, why would I want to do it that way? Mine works, right?' will take time...don't push it, every one and then on a not-so-frequent basis, drop a line or two of Linq, like keep it subtle and discreet, in a subliminal way if you like...

You can lead a horse to water but you can't make them drink it Remember, the goal is to get them to back you with the new technology such as Linq right? The management will eventually cave in once they realize their senior developers have joined forces with you and adopting the new technologies. Push them, they will fight back, in the same way a horse will ignore the water if you tried to force them, no matter how hard you will coax the horse into doing so, even if it means having to be the 'horse whisperer', it will fail big time, but get three or four horses, near water, one of them is bound to lap up the water, the others will follow suit.

It will be your approach and your call, but do not dump it on the management in any way that they will perceive as 'intimidating' or 'aggressive', otherwise they will definitely think that you are trying to muscle in on them and will shoot you down...let it happen in at the right time, then the management will see sense and will be glad and happy to give the nod to the new fangled technology including Linq.

That is my input and opinion on it. Good luck with it.

Hope this helps, Best regards, Tom.


This sounds like a case where development doesn't scale, or the Bus Factor might become important.

What you need to do is to convince these guys to try to make their code easier to parse by others, since the current state makes the company more vulnerable that it needs to be.

By suggesting them to divide functions into smaller parts (one function per screen) and to introduce tests that work mostly as examples (and helps others change parts with less fear of breaking things), thus allowing them to focus on the really important work, you might be able to motivate them to change. (I.e. try to give them the carrot of more interesting development and less tedious maintenance. The stick could be to not allow them to code new stuff because it needs to be understandable by more developers.)

(FWIW, I've heard similar "it works, shut up":s from senior people who write code without much error checking, because their code never fails, and if it does, they know what it is so they don't need an error message, twenty return false is ok for them.)

Marcus Lindblom

While I'm not so sure they need to change if the code base is so rock solid, there is one way I've found handy to get someone to learn a new techique or improve where I think he or she has a weak spot.

Start have weekly one hour training sessions for the team (Not at lunch, lunch and learn is an abortion that should be eliminated, lunch is my time not the company's). Assign them to prepare and present the training on topics you want them to learn. If they have to work through it themselves to do the presentation, they may start to see the value. If not at least they will have learned something and so will your other developers from attending the sessions. And make sure to assign topics to everyone, that way you aren't singling them out(how to write rock solid code that never breaks seems to be a good topic). We did this at one place and had terrific results and everyone learned a lot of new things.

And make sure they have code reviews and that someone very junior is one of the reviewers. Don't let the code review end until the most junior person is sure he understands the code. Hey that way at least the junior guys will be able to understand what they did in case one dies. Let them know these code reviews are non-negotiable and that they are, in part, to train the others so that their code can be maintained. Make them participate in code reviews from people who use LINQ or other things you want them to learn. Again, the code review isn't over until everyone thoroughly understands the code. Code review is a great way to learn new techniques as well as identify problems.

+2  A: 

You actually have two problems you are trying to solve.

They do not believe your techniques are actually better. You need a better way to demonstrate that than "I say so", and "I make more money than you do" is not actually any better.

You quoted one as saying "why would I want to do that. This works." This may have been back talk, but it also is a real question. If you cannot quantify the benefits of your approach in terms that they agree with, then you have failed in the management task of selling them on the approach. You may still have the other management stick of "do it my way", but that lacks a certain elegance, and will not result in behavioral changes.

Start from the point of view that they are your most productive employees, but that they could be more productive. Find a way to surface their current high productivity, while making it clear that it can be improved and that such improvement will have benefits. For example, if their code really is bug free but unmaintainable, try to set up some kind of metric on both factors. Do not go deep into methodology, but instead go for something as simple as "big/medium/small bug/feature", and measure output. You should find that their code produces few bugs, but that changes take substantial time compared with another approach.

Be sure everyone on the team is on board on how these will be described, and how they will be rated. For God's sake, avoid a huge meeting or an "Agile is the One True Way" pep talk. Instead, find something that everyone agrees on as a good set of metrics, that you can calculate in a short time at the start of every day, and that you can publish in aggregate on a web page. I strongly suggest that at first, individual metrics go out privately, and only aggregated group metrics go out publicly.

Train everyone, not just the senior guys, in the most effective techniques that can be applied given the environemnt. If LINQ really does make for better code, and tests really do make for fewer bugs, you should see that in your code metrics in a brief time. Being senior, you can bet that they want to improve their craft, especially if the junior guys start creating code that also does not fail. They are likely not motivated by a theoretical desire for Code Quality, but instead by a desire for a product that works. If the new techniques produce that, they will be more likely to use them.

Finally, be flexible. It may be that LINQ will not work with this team. Fine - use the techniques that will.

The deeper problem is your credibility. It sounds like you have little with them.

You are younger than they are, in a position of authority, and you are telling them that you can do their jobs better than they can. This does not make anyone feel warm fuzzies. You have also told them that if only they did it your way, they might get a big salary like yours.

Try looking at it from their perspective - they have seen people come in with the One True Way, and the code they wrote The Old Way has consistently worked better - just look at the rest of the team for proof. Further, if they are older, I bet they have worked for a young and ambitious manager who claimed that he could get them a raise, a promotion, or a big reward, only to see after much work that 'upper management would not approve it', but that the ambitious manager did get a big bonus. If you have not gotten a commitment from upper management, in writing, for a raise of, perhaps, 20%, then it is not clear you can actually offer it.

Since good managers under-promise and over-deliver, you need to carry through to build your credibility with them. Figure out the realistic improvements in measurable output that they might see in a reasonable period like three months. Then get approval from upper management for a substantial raise if they hit these targets, and propose it to them in writing. You might be surprised what they do if they are given a real offer, rather than something vague.

Scott Ellsworth
+1.. sounds like they are not highly-paid if Andrew gets 2x their salary. I reckon I'd be demoralised in their position too. All that experience, all that knowledge, and some young whipper-snapper comes along and starts telling them how they should do their job!
+1  A: 

Excellent = Write bug free code + Write it efficientely
Good = Write bug free code + Write it inefficientely
Bad = Write code with some bugs + Write it efficientely
Worst = Write code with some bugs + Write it inefficientely

Those professionals are already "Good". If you want to teach them something, you must be better than them, it mean first make yourself "Excellente" (if you are not "Excellent" yet), then try to teach something to those "Good" guys.

I think, its better not to write any code than to write a code with bug (Not applicable when you are writing code for the sake of learning something).

+2  A: 

Certainly there can be cross-generational learning, but it isn't easy.

I'm one of the oldies and have moved into C# from a history in C, C++, Lisp, Pascal, Fortran, many assembly languages. I was not very good about learning C#, so I am still stuck with some things that I wish I had understood better earlier.

At the same time, there is a gulf between me and the younger programmers that I don't know how to bridge. A big area is in the design of class hierarchies. I find them making a great big monster deal out of their data structures, complete with GUIDs, pointers back and forth, properties and methods that call deep into the data structure when changes happen, etc. etc. These things are prone to having errors in them that would not be there if the data structure were minimalist. Then they need unit tests to guard against the errors. That is the reason for nearly all the unit tests.

Not only that, but the notification-style programming and excess layers of abstraction result in enormous performance problems that I occasionally have to wade in and show them how to fix. (They believe in profilers, but do not use them because they don't work very well, so basically fall back on guesswork. My method always works. If I tell them what the problem is, they listen, but they are not willing to learn the method because it's not what they were taught.)

For UI coding, which is a big part of our work, I was a big believer in OOP and MVC up until about 25 years ago, when I stumbled on something better. It lets me get work done in 1/10th the time, without bugs. I've published it and explained it endlessly, but it remains a large education gulf.

When I need unit tests, I write them. Most of the time, the kind of tests I need are not unit tests, but more like monte-carlo tests that exercise use cases that are difficult to foresee.

Mike Dunlavey
up until 25 years ago? that's a typo, surely. I'd be interested in your better method though - got a link?
@gbjbaanb: That's not such a long time, when you're at the other end of it :) Here's the something better, with lots of links, articles, sourceforge, blah blah
Mike Dunlavey
@gbjbaanb: and here's how to do performance tuning better:
Mike Dunlavey
I just remember when OO first came out in .. 1988? I'm not sure MVC has been around that long though. Can't remember though - I'm that old :)
@gbjbaanb: I was a student in the MIT AI Lab 72-77. (Most people got through quicker.) Back then Smalltalk at Xerox PARC was a hot new thing, Lambda Calculus was in vogue, Funargs and closures in Lisp in the air, and Carl Hewitt was going on about Actors. In spite of all that noise, some of us were trying to actually get some AI done. MVC started in Smalltalk. I thought "that's where it's at" until I stumbled on differential execution, after my academic career, on a consulting gig in 85.
Mike Dunlavey

What I would do is hop on and upload my resume. I never take a "if you can't beat 'em, join 'em" attitude, especially when you're trying for improvement and managements is satisfied with the status quo.

It sounds like eventually you'll be charged with maintaining these two dinosaurs code after they've both retired or died.

At your next job interview, you'll have some key questions to ask your interviewers.

  • "Do you write unit tests"?
  • "What version/framework/languages are you writing in"? (older tech might be a bad sign)
Don't forget, every dinosaur was young once, and vice-versa.
Mike Dunlavey