I am a contractor to a big company. Currently, there are three developers on the project, myself included.

The problem is the other 2 developers don't really get it. By "it" i mean the following:

  • They don't understand the best practices for the technology we are using. After 6 months of me and others giving them examples there are terrible anti-patterns being used.
  • They are "copy and paste" programmers that produce primarily spaghetti code.
  • They constantly break things, implementing changes but not doing a basic smoke test to see if all is good
  • They refuse/rarely to ask for code-reviews.
  • They refuse/rarely even do basic things like formatting code.
  • No documentation on any classes (jsdocs)
  • Afraid to delete code that doesn't do anything
  • Leave commented code blocks everywhere even though we have version control.

I find myself getting more and more frustrated as I format others code, fix bugs, discover functionality that is broken, and create abstractions to remove the spaghetti.

I really don't know what to do. I try not to get to frustrated, but it's just a mess. I like these people as people, but I feel like the coding situation is so bad that I could move faster if they simply browsed the web all day.

Would it be out of line to ask our manager to review the others svn commit access; commits can only be done after a review by someone who is knowledgeable in what we are doing? As a contractor, I'm not sure if that's the best move.

Is there a subtle/not so subtle way of making it clear how many things I am fixing?

  • 1
    I opened a question in response to this one, which I think generalizes the real problem your team is having: programmers.stackexchange.com/questions/127117/…. As far as introducing automated tests, I strongly agree with Martin Blore's post: martinblore.wordpress.com/2010/06/02/… -- without good principles and foundation, TDD effort is going to be much wasted. I tried to zero-in on that foundation in my post as I'm also curious.
    – DXM
    Dec 27, 2011 at 5:23
  • the problem I have is that tests only verify functionality is working. They don't address the other 7 items I listed.
    – hvgotcodes
    Dec 27, 2011 at 14:09
  • 1
    have you tried pair programming with these guys? they would see your point and you would see theirs if you sit on a single machine and develop a single functionality. Do it for a month, 3 days a week, 3 hrs a day. It may help. Also establish CI and publish code coverage and test case pass rate metrics. Let the build fail if any of those are violated.
    – user43894
    Dec 28, 2011 at 8:31

3 Answers 3


I'm having something like this on my team. I tried hard to get people to do the right thing and it didn't work as expected so I moved to a different solution.

First, I went to my manager and we worked out a deal, no code whatsoever gets into the source control unless it's covered by unit tests. If code gets in without unit tests I have veto power to undo the commit right away and ping whoever was responsible to they can work on tests and then push the code.

With this rule in place, I regularly run code coverage tools (in this case, jacoco in our sbt build) to make sure pieces are correctly covered and I'm also doing refactorings and code reviews constantly in any code pushed by them. As this is a Java and Scala project I have plenty of tools to help me catch stuff that should not be there or that doesn't work the way we think it should, not sure how you can do the same with JavaScript but maybe there is a solution.

The main thing I believe is helping me on keeping up with this is that I do have a clear view of what I expect of the project and it's main architecture, so whenever I see something that does not reflect this view, i can go there and fix it. You should do the same, define your view, the patterns that should be used, the way code should be written and keep yourself on top of this, always letting them (and your management) know what's happening and what's keeping the project from moving on faster.

There will surely be a moment where either they give up and do the right thing or the management gets the message and removes them from the project.

  • 5
    the problem here (and I'm not sure if this question is too localized because underlying cause I think is very common) is how to do you inspire the developers to learn and grow instead of relying on their "true and tried" practices of copy/pasting and keep spaghetti'ing things up. If OP moves into overseer/reviewer/approver role, it will cut significantly into his own time. At the same time, people who write bad code, write even worse unit tests. They'll go even slower, write unmaintainable tests, and then they will point out that unit testing doesn't work and blame you for suggesting it
    – DXM
    Dec 27, 2011 at 4:03
  • dxm, yes this is an issue. The point of my question is how to bring this problem to management, although I admit that probably wasn't very clear.
    – hvgotcodes
    Dec 27, 2011 at 14:11
  • 2
    I think the best option to take this to management is to show how much rework their code requires and how much momeny is being wasted on this. Dec 27, 2011 at 14:18

I'm sure by now you've seen my comments and my other post, so I won't pretend that I actually know the answer. Best I can offer is a summary of what I've heard/read from others and add some of my own experience into the mix.

First, I want to say that a little while ago I came across a blog which belongs to one of our own Programmers SE members, Martin Blore and IMO this one specific post about TDD self-actualization is very accurate. TDD is the last, highest level that ties everything together but without previous levels, especially the largest one, principles and practices of producing clear and readable code, it will be very difficult if not impossible to make TDD work.

In my company, both Agile and TDD were imposed on us by management, and at first we simply did them because we were told (which is the opposite of agile). We've tried TDD twice and while I'm a huge proponent of using automated tests, I've personally thrown out all the ones that the team slapped together in the last release. They were fragile, gigantic, copy/pasted up the wazoo and riddled with sleep statements that made them run really slowly and unpredictably. My advice for your team: DO NOT DO TDD... yet.

I don't know what your situation is because you mentioned you've been with the company for only 6 months and that you are a contractor. Are your long-term goals to stay with this company or is the contract going to run out? I'm asking because even if you do something, it might take quite some time to actually see results.

Also when you join a team, it usually takes time before you get enough credibility and respect of your team where they (developers and management) would even consider anything you propose. In my experience, it helps if you put out few fires and demonstrate that you have skills and knowledge that others can depend on. Not sure if 6 months is enough. Quite frequently a new, ambitious person would join the team, then make a post here asking how they can change the world. Sad reality is that they simply can't.

So assuming you have your team's respect and attention. Now what?

First, both management and developers need to be aware that there is a problem. Management measures results in terms of work delivered. If they are happy with the current quantity and quality of features, then sad reality is that they won't listen. As others have pointed out, without management's support, it will be extremely difficult to introduce any kind of change.

Once you do get management support, next step is to dig deep and identify the root causes of why the team operates the way it does. This next topic is something that's been a personal quest of mine of a little while now. So far this has been my journey:

  1. Once you have management's support. You can start introducing a lot of centrally-dictated practices/processes that MainMa suggested in response to my question. We've done a lot of them (except for paired programming) and you definitely see benefits. Code reviews especially helped to standardize on styling, documentation and also allowed us to shared knowledge/techniques among the team. Even though, code reviews were dictated, the team actually likes them and we review every piece of functionality that is checked in. However...
  2. You notice that the code that is generally written is still too coupled, design is bad or completely lacking. Code reviews catch some of it, but there's only so much you can rewrite. Why is design bad in the first place? -- A lot of developers have never been introduced to good practices and were never formally taught OOD in the first place. A lot of people "simply coded" whatever task they were given.
  3. With management's support you can introduce more process, such as discussing design before any coding takes place. But you are only one person and it seems that as soon as you don't pay attention the team reverts back to what they've always done. Why?
  4. Can better practices or habits be introduced and taught so you don't have to constantly monitor? -- Turns out this part is not so easy.
  5. Why are other team members reluctant to learn and pick up new practices and why are they so resistant to SOLID or DRY when it's been written about so much in modern software methodology literature? With all positive changes we've had in my team, 2 weeks ago I had an argument were I refactored 2 functions that had identical 15 lines of code and the reviewer called it heroic, unnecessary effort because there's nothing wrong with copy/paste of only 15 lines. I strongly disagree with such views but for now we've settled on agreeing to disagree. -- So now what? Now we've reached the topic of my other post.
  6. As maple_shaft and nikie pointed out in their answers (sorry, MainMa, you got the most votes, but you are so 5 steps behind :) ), you have reached a stage where "process" can no longer help you and nobody on this forum can tell you what the "fix" is. Next step is to approach individuals, maybe one-on-one, maybe as a team, probably both at one time or another and talk to them. Ask them, what works and what doesn't. The only way to identify the root cause of what drives them is now to talk to them individually and find that out. As part of this step, I recently came across a completely different team problem, but I think Joel's answer here, which is very detailed and insightful, would apply to this case as well. In summary, while using management as "short leash" is a possible approach to just about anything, we need to remember that we are dealing with humans so to truly understand motivations we have to cross more into psychoanalysis than pure management or technical leadership.
  7. So now you are talking to your teammates? What do you ask them? I'm not sure about this next part because I've never been here. Here's a possible scenario: Q: How come no SOLID? A: I don't need it. Q: It might help. A: I do alright as is. -- somehow you need to generate a series of sounds that would leave your mouth and cause the listener to recognize that things could be better if they give whatever you are peddling a chance. If you fail here, they won't ever be convinced that whatever "the process" makes them do actually has any value. On the other hand if you get past this point, you'll probably find you don't even need "the process" any more.
  8. IMO at the very root, your teammates won't learn if they don't see anything wrong with their current habits/practices. So maybe next step in all this is to find a way to illustrate, highlight the problems and make them obvious. After all, we are not writing readable code, using SOLID/DRY principles or maintaining documentation just because it gives us a warm and fuzzy feeling. We do it because it produces better quality code and frankly makes us code faster. Can that be measured? Maybe this is where software metrics come in?
  9. Here's a crazy idea and I have no idea if it would actually work (it might be a standard industry practice, or it maybe completely invalid. I just made it up in the last 24 hours), but I'm very tempted to bring it to the table as soon as next year starts:
    • Against opinions of many others, introduce the idea of Author/Owner for all source files. As The Pragmatic Programmer suggests this will give a sense of ownership and responsibility to a single person who will be responsible for a piece of source code. It doesn't mean other people can't modify the code, we are all working as a team, but at the end of the day, person that owns the code is responsible for reviewing changes.
    • Create a source repository trigger that monitors all check-ins and specifically looks for those which are bug fixes. Make it a process so that every bug fix has a reference identifier right up front in the check-in description. Now write a script that would parse a list of files that were changed and strip out the "Author" from the file header comment block. Create a SQL database that would track # of defects checked in per file/per project/per author.
    • Once you have enough statistics, hopefully you will notice that your code has fewer defects/changes than some of the other code. This is hard data you can use. If a single project has significantly above average defect rate, bring it up as a candidate for next clean-up/refactoring effort to pay back some technical debt.
    • If a project or file has significantly above average defect rate and it has one owner, talk one-on-one with that person. Ask them, very politely, non-confrontationally what they can do to address this. Since they are the owner, they should drive the change, but offer any and all help from your side. Hopefully, the owner will trace a lot of the causes to their own spaghetti code and as soon as they ask for help, that's when you spring into action and lay down some SOLID.
  • 1
    this is excellent, thank you. I have tried before some of these techniques (Jen*, why don't you change your code formatter to do x, y, z, it takes 2 minutes) before, and I always get lip service and nothing happens. Also, one of my colleagues is clearly stronger than the other; on the line where she could be very good, but fails to execute. I hear her talk about code quality all the time, but also sort of reverts into a shell when its time to take action: "we only have 5 weeks to release, I don't want to refactor anything now". And i facepalm. * name changed
    – hvgotcodes
    Dec 28, 2011 at 15:10
  • what if you don't focus on code formatter (or anything else specific). Instead just talk to Jen and bring up some of the issues as team issues (e.g. "I noticed some of our code isn't very readable, I think it's causing us to make mistakes that could be avoided"). Don't suggest anything, but let Jen just think about possible solutions. Also I found that it helps when you backup your suggestions with sources. Instead of saying, "I think we need to work on better naming of variables", what if you say, "I read Clean Code and I think author had a very good point, let's try..." To argue...
    – DXM
    Dec 28, 2011 at 20:30
  • ... with that Jen would have to find a book that suggests naming is not important. And I know what you mean about people reverting back, that's natural and reason being is that when you are under pressure, you go back to your comfort zone to free up your effort for "important" things. Even if you get your team on board with improving quality and learning, it will take several releases before they start reverting to good habits. Just need to be patient, pick your battles and let some things slide
    – DXM
    Dec 28, 2011 at 20:35

I suggest that you speak to your manager about the issue, but he is almost certainly not going to want to review every single check-in.

Instead I suggest that you suggest a suite of unit/regression tests, to be hooked into SVN, and run for every checkin. That will at least help you avoid broken builds. You can gradually suggest other best practices.

If he turns out to be entirely unreceptive, maybe you should go over his head. If you do decide to do that, you will need to bring your best game. You will basically be pitching to management to be hired at a higher level if you do that.

  • 1
    i didn't mention that this is client side work. automated functional tests are the pipeline, but they aren't unit tests so the feedback would be daily, not immediate.
    – hvgotcodes
    Dec 26, 2011 at 20:14
  • 2
    @hvgotcodes: I don't see why that prevents you from creating unit tests to run on each checkin.
    – Marcin
    Dec 26, 2011 at 20:35

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