I have been working for a big company (8000+ employees) for almost 2 years now, and was hired just after I finished my study course.

Everyone here has to deal daily with legacy code which is often very badly designed and full of hacks. At first, I kept a low profile, trying not to criticize things too much. But the situation, as it stands, has become very difficult to live with and it seems no one is willing to improve/replace the tools we use.

To be more explicit we have:

  • An obsolete source control tool (Visual SourceSafe)
  • Plain old makefiles which only support full rebuild
  • .def files which must be maintained manually and separately for all existing architectures
  • monolithic headers files and projects with very few different files (but each has around 3000 lines of code, which sometimes takes care of very different tasks)
  • no use of the "new" languages facilities (well std::string is not that new but nobody except me uses it)

I decided, a few months ago to do something about it, by designing a new compilation environment. I could get incremental builds to work reliably, faster compilation times, better structured projects, automatic .def files generation. I even created a bridge from/to Git to/from Visual SourceSafe.

I showed my achievements to several collegues and our boss but it was like nobody cared. They were all like "Well... people are used to do it that way now. Why would we change things ?"

The changes I suggested were designed so that we could have a soft transition from the old system to the new one. Each improvement could be applied separately and safely.

I even tried to get some of my coworkers involved in the changes. But so far, no success.

Have you already faced a similar situation ? What can one do when "lead by example" doesn't work ?

  • 10
    "I decided, a few months ago to do something about it, "... "I showed the result to my boss". Sounds like you got the order wrong there.
    – user1249
    Jan 27, 2012 at 12:40
  • 3
    @ThorbjørnRavnAndersen: Not sure to get it: How am I supposed to show something I haven't done yet ? Or perhaps you meant that I should have asked before doing it ?
    – ereOn
    Jan 27, 2012 at 12:56
  • 21
    I've been there, and IMO, you need to get out of there, because, as the saying goes, "an idiot will always beat you -- first he'll dumb you down to his level and then beat you with his experience". If people fail to recognize the need to upgrade, that's professional stagnation, and stagnation in our field is death. You can put the things you've done on your CV and if you're good, you'll probably get a good job within a month anyway.
    – TC1
    Jan 27, 2012 at 13:34
  • 8
    Holy cow, 8000 developers? Who do you work for, Facebook? Google? Microsoft?
    – Kyralessa
    Jan 27, 2012 at 16:08
  • 5
    @Kyralessa: i don't think facebook nor google use VSS. Jan 27, 2012 at 16:16

9 Answers 9


Aim for the head: "Lead by example" should have improvement in mind, but it should be targeted on people not on technology. Maybe you have invested too much time in improving technology, but not enough time in what is going on in their heads. Think about the driving factors why there is an opposition for new things. In many cases they just fear some risk. Identify those risks and find counterarguments for them.

Grab the fresh meat: It is easier to win over employees who want to change things. You notice them immediately when you see them.

Avoid the rotten meat: Some will never sympathize with your ideas. Leave them aside.

Grow to a critical mass: Find people who sympathize with your ideas. Win the over one by one. At some point if a critical mass is reached, more and more people will follow your example voluntarily.

Management vocabulary: Managers are not interested in better designs. Their language is money and time. Make clear how much man hours are wasted for bugs. Make clear that unsatisfied customers who encounter bugs are not profitable. Demonstrate how much faster you can implement a new feature. You need to choose another vocabulary for managers.

It is all about processes: Better technologies do not make better programmers and programs. If you have good running processes, even outdated technologies lead to good results. Think about were effort and time is wasted. Maybe it is not the technology, but something in the processes is going awfully wrong. In most cases it is a lack of communication.

Find a new company: You already have done a lot. You can still try to improve things, but it is also up to you to decide how long you want to try it and how much energy you want to invest. Keep in mind: Even if you cannot achieve a lot of improvement, you will learn a lot out of your efforts. At some point you need to move on.

  • 3
    Related to "grow critical mass": youtube.com/watch?v=V74AxCqOTvg
    – back2dos
    Jan 27, 2012 at 10:02
  • 2
    @Farmor if you cannot convince them without say "go read a web page", perhaps you is the one who need to brush up on the communication skills.
    – user1249
    Jan 27, 2012 at 12:41
  • 1
    I mean if they are stubborn and don't listen to the young. You can make your point by referring to documentation. For example if they say your points are not correct and almost all versioning experts writes your point they will be forced to submit. And I like to tease the arrogant, For example if they like Torvalds you can say Torvals says "If you like SVN you are stupid and Ugly" as he did in his google speech. I don't understand why referring to documentation when a stubborn person won't believe you is the wrong thing. You could even do it on your phone and show them right away.
    – Farmor
    Jan 27, 2012 at 12:53
  • 6
    -1 for ageism. Sometimes you need to listen carefully to the "fossil expert" and allow yourself to have a little humility. Then with the knowledge you've gained make your idea even better. Sidelining others just because they're old is a sure way to lose valuable know-how and the support of influential senior devs.
    – Doug T.
    Jan 27, 2012 at 13:35
  • 1
    @Lundin: Managers should have technical expertise, but the higher you climb the ladder the more money and time become important. There is nothing wrong with it, because someone need to keep track of the commercial aspects of a company. It is vital to give managers the right arguments into their hands so they can justify their decisions to their managers. As a developer you can win over a manager if you serve him the right arguments. Jan 27, 2012 at 15:46

Have you ever stopped to consider that you might be wrong?

So you read some designs and patterns books in school and you are disenfranchised with what seems like comparitively antiquated practices where you work. No doubt they are probably better ideas and new projects should start with these in mind, but it seems like you are on a completely different level.

Herding developers is like trying to herd cats, they inherently have a mind of their own, and a preferred way of doing things, whether right or not. I have a hard enough time enforcing best practices and managing a team of 2 developers, but you work for a company that has 8000.

That is a staggeringly huge number. Even a simple process change that states all developers must schedule meetings and out of office time on the public calendar becomes an enormously complex and difficult policy to implement across the board. It would also require a significant push from management to make sure the policy is accepted and adopted across the board.

You may not think it, but something as simple as moving from monolithic to multiple header files, or moving version control from SourceSafe to Git requires an enormous effort and investment on the part of everybody involved. It would require:

  • Significant management support

  • Company wide acceptance

  • Investment of meeting hours for all developers to inform them of the new initiatives (Meetings cost man hours, man hours cost money)

  • Training needs to be planned and established to make sure even the stupidest developers know what they are doing

  • Even assuming an hour of training, across 8000 developers x €50/hr = €400000 cost of training. This is more money than my one software development team gets budgeted in an entire year for salary, software and hardware. That is an exceptional investment you are proposing.

But you are saying, "Think of all the time that could be saved through productivity increases." Rightly so, but significant investment is significant risk, so I better be damn sure that you are right about this before I sign off on it. If none of the senior guys are backing you then I can't justify the expense. Ultimately we may be inefficient, but we are consistent and with 8000 developers across the company, consistency is the most important.

To do this you need sign off from multiple senior level people, and you need to accurately and objectively find a way to measure lost developer time to inefficiency. That time equates to dollars and only dollars and politics will help you win this battle.

  • 4
    Thank you. To be honest, at first, when I came, for some weeks I was all: "What the hell, these guys have no clue !" then realized how wrong I was on many points. But after two years there, I am pretty sure some processes can be improved, and could solve many of the complaints I heard. I understand it is also a matter of opinion but if someone came to me with evidence that I'm doing something inefficient, I would at least listen to the guy because he is doing me a favor. My departement is only composed of 40 people, and only us do this kind of development.
    – ereOn
    Jan 27, 2012 at 13:15
  • 1
    I am sure that they can improve, but like I said, it is different for me to change my behaviors and practices to improve, than it is to train and force 40 developers to do this. A non-technical manager is not going to listen to you without politically important senior people backing the idea.
    – maple_shaft
    Jan 27, 2012 at 14:22
  • It's not just "could things be done better?". Replacing a source repository is a huge change. there are big costs to making the switch, not least of which is retraining all the staff. Then there is the risk. Are you 100% sure that there won't be some capability the old source code repository needs, that you aren't aware of, and which the new one wouldn't have? Jan 27, 2012 at 20:06
  • @DJClayworth: The VSS repository is only used as a basic storage system. Nobody ever looks at the history and they usually erase everything before copying the entire directory again.
    – ereOn
    Jan 28, 2012 at 15:50
  • 1
    @ereOn Please remember you work for a business, and a business is to make money, not code. Unless it's a not for profit. In any case, your prime value to your customers is probably not "we will deliver you code with the quickest compiling makefiles in the industry". You should work out what matters to your boss (eg cut costs) and then work out the costs. Factor in people, and tool costs.
    – jasonk
    Jan 30, 2012 at 9:12

What you've described doesn't sound like "lead by example" to me, it sounds like you made a proposal and were rejected. To lead by example you need to show people that your way is better. Of the problems you listed I see three that you can start using your own changes yourself.

Plain old makefiles which only support full rebuild.

Create your own makefiles locally and show how much more efficiently you're able to work with them.

monolithic headers files and projects with very few different files (but each has around 3000 lines of code, which sometimes takes care of very different tasks)

Either break up existing ones when you touch them (without breaking the build) or introduce smaller header files when you write new code. As people start to work with them, they'll realize they don't need the duplication.

no use of the "new" languages facilities (well std::string is not that new but nobody except me uses it)

Continue introducing new language facilities any time you touch old code or introduce new code. Make sure you're simplifying things. Don't be discouraged from this one. Most of us are lazy. If we see that a new language feature makes things easier, we'll adopt it.

After a few months, if other developers start adopting your improvements, then you can approach your boss again about more radical changes like upgrading your source control system. You need to make sure the other developers see the benefit though, or it will never go through. One way to approach it might be to suggest trying out Git on a small project that only a few developers are active on. That way you can promote it as an evaluation, not a full scale transition to an unfamiliar system.

Finally, if after several months of trying no one seems interested in improving how things are done at your company, you need to really consider whether it's a good fit for you.


In addtion to Lionel Barret (which I mostly agree), consider also the possible motivation to the resistance.

  • Evaluate the cost of the actual process
  • Evaluate the cost of the process as it will be like yours

But also:

  • Evaluate the cost of the change in term of
    • Money to spend to setup the new environment for anyone
    • Time to spend to train everyone to be accustomed to the new mode (it may be easy for you, but not that easy for people who are not aware of what you are doing)
    • Elapsed time required to manage the change in a non-disruptive way.

I have a suspect: How many are in your company the people like you in term of age and culture (I men "school" and "type of school")? How many people like you are expected to be hired in the next 2/3 years and how many will retire or change their role in the organization?

My suspect is that you are in a position with not enough strength to change the company. In that situation, either the company will change you or will "expel" you (In the sense it will become your own wish to go away), if you're not able to wait for more time.

But may be the company is evaluating that the additional costs I told you can be saved allowing the change process to happen spontaneously by waiting the natural replacement of the people to happen. You're just at the beginning of a process you cannot see because has nothing (yet) behind you.

  • 1
    Your guesses are spot on: I am indeed one of the youngest in my department. Some of them seems to realize that despite my young age, I have some valuable knowledge. I know and understand I still have much to learn (and believe it will be so until the day I die), but a lot of them seem offended by things they don't know. I don't want to push them away or steal their job or whatever: I just want to improve things so that everyone can work/live better. Will I have to wait to be older to gain some weight ?
    – ereOn
    Jan 27, 2012 at 9:51
  • 1
    @ereOn: your driving is so noble, every sane person should want to work with you.
    – o0'.
    Jan 27, 2012 at 13:01
  • @ereOn: "Will I have to wait to be older to gain some weight?" Not necessarily. Age is a value in term of experience in manage complexity. Is not a value in understanding new things (they are new to anyone, and having no backlog can be an advantage). It's not a "personal" problem. It's a problem of "critical mass". Until the people wishing the change are less than 20% they will be suffocated. If they are more, leadership become visible (and is not a matter of age). If a leader can reach 40% of a population the "new thing" will have proper citizenship. From 60% change is spontaneous. Jan 27, 2012 at 13:30

At this point I can only add a reference to the Joel Article Getting Things Done When You're Only a Grunt. The sections include:

Strategy 1 Just Do It

Strategy 2 Harness the Power of Viral Marketing

Strategy 3 Create a Pocket of Excellence

Strategy 4 Neutralize The Bozos

Strategy 5 Get Away From Interruptions

Strategy 6 Become Invaluable

I'd summarize the article as "Change has to start with you."

  • 2
    I found GTDWYOG to be not very helpful. In my opinion, at least the title is misleading: someone who "is involoved in hiring" or has the freedom to ignore the rest of the world while working in the cafeteria is not a grunt. A grunt is someone who has to do as told, with little to no control over the circumstances he is in. In my experience, despite the idealistic picture painted here at stackexchange, that is the case for most developers. And for those, GTDWYOG is more a recipe for beeing fired for disobedience.
    – keppla
    May 7, 2012 at 12:45

Sadly people get stuck in a rut and develop the mentality that 'it works, everyone uses it okay, why change it' And it gets infuriating.

You have gone about it the right way by not just complaining but by developing a workable solution as a replacement, now you just need buy-in.

Show your direct line manager (or technical lead). If they are uninterested, do you have anyone in charge of change control or innovation?

Potentially though, your ideas and work could be ignored and the situation will stay as it is.

  • 2
    ah but the number of times I've heard "lets rewrite it, it'll be so much better and cooler in new tech x" only to find that the new one was no better than the old (and in many cases worse). Quite often, until there is a need, it's best to not break something that works.
    – gbjbaanb
    Jan 27, 2012 at 14:13

You need to state your case in a way that get your boss on your side. BTW, This kind of change is proposed by a technical director or project manager, so will need to commit yourself to the project. (As an alternative route, you can propose a technical audit, an outsider is likely to say the same things as you but will have more weight.)

So far, he doesn't see the need to change, it looks like cosmetics change to him : Costly without obvious benefits except to satisfy the fancy of a dev. Only two things matter to him : the flow of money and a stable team. The tech is a black box, if it works, that's enough.

First money, you need to proove that the current setup is costing him money. What the cost/hour of a dev and how many hours faster compilation times would save him ? Do the math. Also, compile articles or testimonies about the risks of the current code pipeline and show him scary numbers : "because of SourceSafe/Bad Coding Practices, our company lost $XXXK".

Second the team, your boss may be stuck with old grumpy coders who don't want to change their ways. If the first point is established, you also need to propose a solution to this problem. How many are you ? It could interesting to underline that it will hard to replace someone because the current coding pipeline is bizantine. You need to propose a plan to update the team. Learn them the industry best practice and check they are following the new rules.

Finally, you need to propose a plan to change the codebase, divided into small projects, with milestones and resources allocation. In fact, you're selling yourself as a project manager and the changes as mandatory to have a solid code pipeline.

  • Thank you for your advices. The thing is that the person in charge seems to like very much all the old developers (because in the end, they get the job done and don't count the hours). I feel I have very little weight because I am young. Several people in my department come to ask me things about good practices though but even when I explain things very humbly, at some point they don't want to show they know not much about it and try to defend their old ways.
    – ereOn
    Jan 27, 2012 at 9:41

Do you work at an organization that believes doing things well, efficiency and innovation lead to success and profitability; or that the pursuit of revenue, and concentrating on maintaining sales are the tenants of success?

Companies that behave like you are describing are technologically entrenched. In a competitive market they wouldn't be able to compete with a company who focused on individuals and innovation.

If you are the person you say you are, then work somewhere that honors and rewards your spirit. Eventually after years of settling you will start compromising for the same philosophy that your superiors embrace. Go work somewhere else (probably a smaller organization) that values hard work, inspiration, creativity, and progress.

If you don't take a risk and do this soon you will eventually settle and you will not be able to continue to feed your curiosity and creativity because it is philosophically opposed in your current peer group.

Excellence is an attitude and a world-view.

Just know that this experience gave you the insight to know what to avoid, keep your keen eye for complacency and protectionism so you can detect it early.

In your next interview ask questions like "What kind of innovations come from your employees", "What are some changes that came from individual creativity?", "What individual talents can I bring to this team?", "What drives your organizations success?", "How is your organization continually embracing technological innovation?"... The answers to questions like this are extremely telling. Many organizations have no vision, or those that created the vision are gone, and the organization is ran by accountants. If you are interviewing with the Director of Technology - ask him if he sees the organization as a technology company.


If you do not like the environment you are working in then you are doing a disservice to yourself. You need to be surrounded by people who have similar interests and goals as you do professionally. I know sometimes that is easier said then done, but the feeling of looking back several years and feeling as though you have wasted your time is worse than the fear of taking a risk.

As an alternative, if you want to develop in a system or an environment that uses specific technology and/or methodologies then I suggest you find a project outside of work that you can contribute to. At the very least the variety of working on both systems will satisfy the need for something different while you find where you belong.

Seems to me you are fish out of water. Go find your body of ocean and swim!

Not the answer you're looking for? Browse other questions tagged or ask your own question.