How do I tell my colleagues that the codebase they've built is a total mess and their practices are ancient?

Question

The situation

For a few months, I've been working with a new team in a new company. The company offers some web services and the team's role is to develop and maintain those services.

Problem #1: the team is not a team, it is a set of individuals. They do not collaborate with each other. Everyone works on his own piece of code in the way he likes, with his own conventions and methodologies. The closest thing to collaboration I've seen so far is: "I've finished implementing this feature, now you can start building something on it".

Problem #2: There is no modularity. Well, actually, each developer's work is in its own repository, but those repositories are highly heterogeneous and mix different stuff (often reinventing the wheel and duplicating code).

Problem #3: The development practices are really ancient. They know the word 'agile', but they don't understand the concept behind it (probably because they've never tried it). There are no code reviews, there are no tests, software is really hard to configure and adapt. The overall development process is slow and inefficient.

There are many other defects but they are probably consequences of the three problems listed above. In short, the codebase is a mess

How to deal with it?

Working here, I've quickly noticed these problems, and at first I decided to drive by inspiration: I've worked on my first project with some agile development practices and the feedback has been good.

However now I'm in a situation where I'd like to touch other people's code/practices and I can't drive by inspiration, because I need their collaboration.

I tried to make them understand that they're a team that is building a product and they're not individuals working on their own projects. However they couldn't understand what I meant and simply ignored me.

Now I'm thinking to change my approach: I want to explicitly state that they're making mistakes, analyzing each mistake, their causes and proposing solutions. I want to start from the low level (e.g. "this piece of code is slow/wrong/inefficent") and then slowly move to the high level (e.g. iterations vs. waterfall). But I fear that they would think I'm attacking them, which is not the case.

Is it the right approach? How should I proceed?

EDIT 1: Based on your answers, clearly this is the wrong approach. Starting from today, I'm going to continue leading by example and explicitly point out the benefits brought by my methods. (Untill now, I have constantly asked for feedback, but actually have never asked explicit questions like "hey, do you like the fact that I have written acceptance tests? Do you think they will improve the overall quality of the project?") Let's see if it works!

EDIT 2: As I said, I started leading by example and speaking with teammates and with managers. The result? I've been nominated "master reviewer", i.e. my role now is to actively participate in all technical discussions, give suggestions on the architecture and establish new approaches to the development process.

Answer 1

tl;dr

This is not a technical problem it's a people problem. Treat it as such.

---

I ain't changin' anything!

You are off to a really bad start and it has nothing to do with the code.

It sounds like your people skills are lacking. You don't start charging into a new job telling the current team how bad they are.

People don't like change. And they really don't like it from the "new guy."

I want to start from the low level (e.g. "this piece of code is slow/wrong/inefficent") and then slowly move to the high level (e.g. iterations vs. waterfall). But I fear that they would think I'm attacking them, which is not the case.

I'm not sure what culture you live in but telling someone "this code is wrong, I am better and you should do it this way" will always be an attack.

What to do?

1. Stop thinking "me vs them." Unless you plan on quitting you are part of this team. It isn't those "awful devs" vs "me the superstar" and if you communicate this to your team you ARE going to have problems. No one will ever respect your ideas. It doesn't matter if the team works as individuals. It's still a team and you even describe it as such.
2. Find out if expectations are being met. Is the team meeting manager expectations/desires? If so, you are not going to find much motivation from anyone to improve. "If it ain't broke don't fix it." But if the team is struggling to meet performance goals then you have a different way to approach it and can present everything as, "hey, we aren't hitting deadlines - do you guys want to try to change this? I think doing X might help us do so."
3. You aren't the manager, your boss is. It sounds like you want to manage the entire process yourself. This works great -- for managers/team leads. Getting your boss's input is important.
4. People care more about results than fuzzy feelings. Your manager is going to care a lot more about your perspective if you actually demonstrate why what you are saying is better than the current state. Not just "because the internet said so!" but actually through demonstrating.
5. Ask people for help. Find ways to build team trust. Asking for help/guidance is a super easy way to do this. Even if it's minor, do this with your team. They will respect you much more if you actually show you listen to their opinions.
6. Lead by example. People who don't want to change normally do not take in new information and go "you know you are right I never once considered the way I was doing it was inferior, now I am enlightened and shall change my ways." People change by changing small things, slowly, in a sustained way. You can demonstrate this.
7. Pick your battles wisely. Your example sounds like your fundamental problem is the team has people who are bad at their job. Is it really that bad if code is inefficient? Is it actually affecting end performance? Or would focusing the next project on iterations vs waterfall matter (note that if you focus on agile vs waterfall types of things you sure better get your boss on board).

Answer 2

This is not the right approach. All you will do is alienate your co-workers. How much would you like it if someone took it upon themselves to analyze all of your mistakes?

Your best bet is to work with your manager or supervisor, and how you do this is important. Instead of pointing out all of the things that your co-workers are doing incorrectly, you should carefully prepare a list of ways that you think your processes could be improved and how your company would benefit. In other words, don't attack the people - point out what's broken about your processes and ways that the team could improve if those things are fixed.

If the manager sees and understands the value behind what you're saying, he/she is likely to take action; maybe not the exact action that you want, but things are likely to improve. If not, you can continue to try to lead by inspiration and hopefully things will get better on their own. However, if you want to preserve any kind of working relationship with your peers, don't try to tell them how to work if how they work is not your responsibility.

Answer 3

I would definitely not start low level - "this code is inefficient" or the like. That is just going to cause a lot of defensiveness for very little gain.

Mixing and matching an agile project and a waterfall project is insanely hard. The waterfall people want to establish the interface between your projects (file format, table layout, api, whatever) in advance, then go away and write to that interface. You want to just get started with the simplest possible interface, the pieces you know for sure you'll need, and then come to them saying that you need to add or change something and have them react to it. To you, this is responsible, agile, and fast, because you didn't spend forever arguing about design at a time when you couldn't possibly know the answers. To them, this is cowboy, jerking them around, constantly changing the ground underneath them. It's a recipe for disaster.

I suggest you surface this difficulty to the next person you have to work with. Talk it through and decide together whether you will fully design your overlap/interaction together first, or start simple and be prepared to change it as you go along. Really listen to the resistance you get from the other developer. They are not automatically wrong. Agility is great when you own all your boundaries, but it can cause extra work when you don't. On some projects, that extra work is still less than the days or weeks of speculating and arguing that led to the creation of a suboptimal design you were stuck with. But not on all projects. On this one, it might make sense to fully design the boundary between you and the other developer before anyone starts. Then go ahead and be agile inside your silo.

For the larger issue, that you think they (a) write crappy code, (b) should be agile like you, (c) should use a consistent and modern toolbase, and (d) should be doing more testing and more sharing code between projects - tread very carefully here. You've tried just being great and seeing if they want to copy you, and they don't. It's not at all clear to me that you see the benefits to them of keeping right on the way they have been. You will never persuade them to change their ways without understanding why (beyond inertia) they don't. You will probably also need the explicit support of your manager to lead a "best practices" drive that changes existing code dramatically and teaches these developers how to do it from now on. Doing it on your own? They're just going to keep brushing you off because they don't have time for that, they have code to hammer out.

Answer 4

I have tried to stick to the following principles in my past, and it seemed to work out fine:

• I forced myself to start with a "quiet learning period": For a period of a few months or so,

  Be quiet and learn. Do not judge anything. Integrate yourself into the team and the company. Be productive. Build trust and reputation. Show your competence.

  (I take it that you have already tried a similar take, too.) Often you see things you think are bad but a few weeks later you learn why they are the way they are.

• If you notice issues or face things that you think are not optimal,

  Collect data: Hours spent on a simple change, bugs popping up, angry mails being sent around, etc.

  Any change you ever plan to suggest needs facts to show it is necessary and helpful. I like to make notes in my personal "diary" (one of these good old blank books made of real paper).

  In one of my projects I had the feeling that making a change was very expensive in particular because there were no automated tests and manual testing was very combersome. So I tracked the hours I spent on each task, keeping hours for actual implementation separate from testing hours.

• After a while your observations (or notes) will help you

  Get a clear picture what the main issues are. Spot them (only!)

  I can't imagine that you can do that "bottom up" as you mentioned. It is rather top down: A issue surfaces and you try to find the root cause for it.

• Only address one issue at a time. Use the data that you have at hand and try to

  Elaborate a suggestion to improve this one issue,

  showing the issue and potential win by using your data. Use a good moment and pick the least offending way. Also, try to suggest a change as small as possible with the biggest positive impact. Small changes are much more likely to be accepted/approved by the team than big ones.

• Do never finger-point. Make yourself a valuable friend of each of your team.

  You make mistakes, too, by the way. And I guess, more often than not, bad things that you encounter have not been "made" by a "bad guy". They have evolved because one did not take enough care of preventing that. It is always a good advice not to blame people for an issue but to address the processes, the way the team works together, etc.

Answer 5

Welcome to the business world.

Change takes time. In a large company it can take decades if what they have is working well enough (and indeed may have been industry-leading years ago when they adopted those practices). Working for IBM, I'm still using some tools whose back-ends date back to the "green screen" era, because they DO work, are heavily integrated with other tools (and thus hard to replace individually), and because nobody has found sufficient funds and time to invest in switching over in a way that doesn't involve unacceptable risk.

Similar issues apply at the business practice level too. Changing tools involves risk... either the risk of underestimating the cost and failing to meet your commitments, or the risk of overestimating it and looking like you weren't aggressive enough. Management wants to be able to make predictions, so they may be afraid to commit either way and stick with what they've got.

Change can come, but it has to start small and be built outward. You start by setting an example of how the new approach helps YOU, over an extended period. Eventually you have enough evidence to convince a team leader to try it in a small group (or you become a team leader who can do so), in a way that doesn't adversely impact the rest of the company. Build outward from there. Expect change to take time; battleships neither start, stop, nor turn very rapidly.

Ditto code quality and coding practices. Remember that consistency (being able to read and maintain each other's code) trumps pretty, and learn to work with the coding style they prefer. (A good programmer can read almost any style -- though the guy who thought semicolons belonged at the front of statements may have been an exception.) Remember that if you're maintaining existing product code, you need to minimize the risk of introducing new bugs, which means local patches are preferred unless you can demonstrate STRONG reasons that larger ones will be easier to create, easier to maintain, and will have benefits for the customers. To put that in perspective, remember that many customers run years-old code rather than the latest release, and upgrade only when they absolutely must, precisely because they aren't willing to risk that a new bug will take their business down.

And, yes, minimal patches add up to ugly code. Eventually that gets fixed, but not before the next major release and not unless there's an actual problem with the old code.

When the opportunity comes to implement something new, THEN you can consider pushing for the advantages of a new approach. But maintenance, by definition, is beholden to the old processes and changes very slowly. Unfortunately, academic best practices take a long time to be adopted... and often, by the time they are, something else is the new latest-and-greatest.

Take it one small change at a time, until/unless you are in a position to implement larger changes. Show, don't just tell. Be patient and persistent. Remember that things are as they are because they DO work, and learn to operate the current system well enough that you can explain exactly what both the benefits and risks of switching over would be.

Or do the high-risk thing of starting your own company, and doing things your own way... which will quickly teach you why everyone is so nervous about risks they don't yet know how to quantify; some young punk will come in with this week's trendy approach and you'll have to explain to him that the company needs to wait for a clean opportunity to cut over... and meanwhile you need him to work on what you've got now, and if he can't do that he doesn't have a future with the company.

Answer 6

Good answers so far, especially from Roger, enderland♦, and Kate Gregory, but I'd like to add to it.

TLDR

Start with the high-level methodologies because they will result in higher quality of the low-level part. Make your manager and your coworkers understand what they'll benefit from adding the high-level methodologies, make them want it to change, the only way for their culture to change is by having them wanting it to change.

Original answer

I suggest that instead of beginning with criticising inefficient code of your employers that you start slow, cooperating with your manager, with new methodologies, one by one, where every step's gain is thoroughly explained. A company culture can only change if the employers want it to change, understanding why it should change, ending up with them wanting it to change.

Suggested order of methodologies:

Standups - Starting very slow

Start with stand-ups. If you can make your manager and your employees understand that migrating information about what's being done and by whom and in which project then your company is less likely to be screwed if someone is suddenly not able to continue his work, making it a pain in the arse for the next employer who has to pick up his work. If your coworkers think it will be easier for them to take over someone else's work by migrating information by only spending five minutes per day doing it then it's a potential start.

TDD - They're still able to do their things, but in a more structured way

I think it's a good next step. It's hard, and almost pointless to do unit tests on legacy code (actually, the definition, according to some experts, of a legacy code is a code base which has either none or few unit tests), but writing unit tests for new methods ensures that the new methods will actually do what's expected of them -- resulting in fewer bugs which the developers have to think about, less expenses for the company (your manager should be found of that), and it shapes the flow of the systems instead of the other way around. Read up on test-driven development (TDD) and find out how TDD will make your coworkers lives become easier, and they'll end up doing it, especially since they can do it on their own and don't have to interact with anyone else doing it. The most important part is that a unit test can be written in a matter of seconds or minutes, if done on the before hand, making it not sound as boring, and actually inefficient and pointless as it is, if it's written afterwards.

Invent the concept of SOA - Get rid of tightly coupled systems

Service-oriented architecture (SOA) will ensure a loosely coupled architecture which enables modules to be replaced and maintained easily, by anyone, without requiring any knowledge of the other parts of the systems. Ask your coworkers if they're willing to maintain someone else's super tightly coupled systems after five years of development and maintaining and ask them if they're more interested in having to understand every single concept in the system or if they'd rather like to only having to understand very small subsets of the system, even allowing them to rewrite that very specific part from scratch if they like, because it's only possible with a super object-oriented, or SOA architecture.

Code-review - Migrate knowledge without needing to interact too much with others

You can ask your coworkers if they'd like to be more valuable. Having knowledge in the various systems that are around makes them more valuable. It migrates risk which your employer will very much like, and it gives your coworkers very much of an advantage if one of them is not able to continue his work. 15 minutes a day would change a lot, and you'd allow them to point out each others' flaws, not making you look like the bad guy, unless it's your turn to review, then it's okay because well, you were supposed to review the code.

The list goes on

The point is to start with the high-level stuff; it will end up in higher quality of the lower level stuff.

The things I said of each thing will possibly not convince everyone, but the key is to make your coworkers want to change, otherwise they won't. Let them see why they should change by finding the catchy parts of the high level methodologies and things will improve.

Answer 7

You've listed three problems. Most of them sound like acceptable best practices (nothing wrong with that), but there is one that I think you should focus on, because it may be the main problem as everyone in the company will see it, "The overall development process is slow..." You also give the reason, inefficient.

The word "agile" gets thrown around, but like all of this, it's relative. You should focus on some real problems that everyone is having. How long does it take for change requests? Are changes incomplete, i.e. "The new fix showed up in Section A but not Section B. Why not?" These are the things users care about. You'll get more buy-in from the rest of the company if the results of your suggested changes benefit them. Of course, being able to implement things faster can be better for everyone.

You mention duplicate code. It is a no-no among programmers, but for larger projects and especially those with a lot of legacy code, refactoring is not going to be easy. It sounds great in theory, until you discover that no one is going to grant the team the time to do it at the expense of current requests. Making an argument against technical debt is not easy.

As an initial task, try to get the team together and discuss developing coding standards. You're the new person, so you recognized this right away. See what everyone's reaction is. You may get pushback because they can't agree or "we tried it but no one complied". Maybe the current mess is enough motivation to get everyone to want to do something about it. Again, you may not get the time.

If you see that this group has a difficult time getting along, start with something basic; go have lunch together. In these informal situations, you may find what the real problems are. It could be lack of knowledge or maybe the environment created in this company is more concerned with putting out the daily fires.

Don't give up, but don't expect it to change overnight either. You have a major task in front of you my friend.

Answer 8

Unless it's your job to change their working practices AND you have that in writing, don't do that, because as others have said, it won't work.

The person who should be doing that is your manager. He's the guy you need to persuade. Try a pragmatic appeal to efficiency, with examples.

If he's not interested? Learn to live with it (and make sure your arse is covered) or find another job. It's horrible, I know. Been there.

(It's possibly not about people, but about politics -- or someone would have picked them up on these practices long ago.)

Answer 9

Sounds like you really know what you're doing, but be careful you don't get off on the wrong foot with your new colleagues. If you're that good, you should be able to make positive contributions to each person's repositories. The better programmers are likely to not mind you improving their code, so if you can work with them, do so. The ones that reject your improvements are probably not the types you want to work with.

But a word of warning: be absolutely certain that your contributions have no negative tradeoffs. If there are downsides to your suggestions, you'll be held to blame if things go wrong.

My personal standard is that I insist that any changes I make on code developed by others, where I'm not architecting things, have absolutely no downsides (or if potentially intangible ones exist, i.e. "is it more readable?", that they are minimal.) Using this as my standard, I'm still able to:

• refactor code, write and improve unittests, raise more specific exceptions
• correct errors created due to deprecated code usage, and replace structures that are being phased out with the newer constructs
• reduce lines of code by using builtin functions and methods that cover the use-case, improve code efficiency by eliminating materialization of data structures where unnecessary, and replace awkward control flow with more streamlined control flow
• improve docstrings/documentation (from spelling to semantics) and make improvements to code style (as we have a style guide!)

And I do all of the above without changing the inputs and outputs of established code, so nothing in production breaks.

By doing this, you're able to build a reputation for knowing what you're doing. As you do this, you'll build credibility with the knowledge workers you're working with. If you're able to replace clunky or bad components with better ones, they'll appreciate you even more. By building your credibility, you'll build your ability to persuade them to adopt the practices you feel will have strong payoffs.

Answer 10

I've been in a similar situation twice and I've discovered as many others that there's absolutely no way of improving things unless your colleagues want to change.

There's a simple way of testing whether or not they're willing, suggest the team goes to a conference or take a course on the relevant programming subjects. There may even be user groups or even general programming interest groups that have open meetings every now and then that your team could visit. Suggest some reading material or videos for people to look at (Uncle Bob's videos work wonderfully in this situation).

With this you don't have to point out any problems or errors you think they're doing, the team's response to these suggestions will tell you all you need to know about how interested they are in improving things. If they're enthusiastic about trying these things you have a chance, if they're not interested you should save yourself the suffering and get out of there as soon as possible.

Answer 11

You have to think about what motivates people. "It would be easier for me to replace you in your job if you had adhered to the following practices:" is not a big motivator: most people do not want to be replaced. Spending extra effort to code in a manner that somebody else takes over does have its value even outside of a hire-and-fire philosophy since code not tied to particular persons allows top react more flexibly to changing work loads.

But in a "nobody but $x is going to touch this code anyway before the project is finished" situation, the maintainability-by-anyone vs effort question has different answers.

Regarding code reuse: one philosophy of C++ is to provide the tools for creating generic solutions. 95% of the "reusable code" that aspiring programmers produce is not reused. And the reason for that is that for many straightforward tasks the cost of "reusing" is higher for an experienced programmer than just writing off the cuff, specifically catered to the code in question.

If you tell a bestselling author that he can double his output by using your text templates that are already pre-checked for spelling and grammar errors and he just needs to fit in the right proper nouns and verbs, and you also have parameterized a number of places for adverbs -- can you imagine just how excited he'll be?

Can you imagine how excited he'll be if someone else can maintain his novel if it is just properly documented and parameterized?

And nobody wants to consult manuals and documentation for some trivial stuff he can write down in what at the very least feels like taking less time, and most certainly taking less mental effort.

If you have a highly skilled team of organ builders working on one instrument, you'll find that everyone has his personal tool set he honed over the years himself. And everyone has his own specialties and signature work styles.

If you state "here's Management. We decided that we are going to standardize on Paul's tools. We've bought/made 20 tool sets exactly like Paul's, and everybody is now going to work with them in future.". Even if everybody agrees that Paul is the best organ builder in the company, few will be happy about that change. The tools will likely not work well for inexperienced builders, and they will work differently than their own tools for the experienced ones.

Not even Paul will be happy because everyone will keep running to him and blaming him.

The point of a team is not that everyone can be replaced, but that they manage to work on a coherent whole. If you are trying to dumb the processes down to lowest common denominator that you feel happy with, you are not improving the output or work morale.

Develop your style. Play your part in the team. If you are doing it well and convincingly, eventually it will lead to "let's ask user1807, this sounds like something he might have prepackaged in his bag of tricks."

What you should check after being there about half a year is not how work is done but rather how it is communicated: do you feel that communication/team meetings happen in a manner that the really substantial wheels are not in danger of being reinvented very costly?

But being able to pin that down in a manner where people will agree with you including "we could and we will do better" is something that you will need years to arrive at.

Do the the things, as a team player, your way. You'll see how that helps the projects or not, others will see how it helps the projects or not. People learn, and that includes you. And management.

Doing things consistently differently than one is inclined to is a matter of discipline. Self-discipline is fine, but you are not in the situation of disciplining others.

If it becomes apparent to management that this might be a good step, you'll be team lead at some point of time. There is no point in trying to prod management for that outcome: a team lead that is not accepted by the team will not achieve anything unpopular. You'd get stone-walled. So be a good team lead for yourself, and a good team member to others.

Answer 12

Problem #1: set of individuals

If a developer can provide and maintain a consistent API, why care about conventions? They are the person who knows the code. No one else is going to maintain the implementation. Do care mainly about the API.

Problem #2: reinvent the wheel

Indeed this is a problem. Common code should be separated in a company or team repo. This should be decided over the course of several dedicated meetings with the whole team.

Problem #3: no agile

Please do acknowledge that agile is not the only true best possible approach to software development. It ensures mediocre developers.