Over the past year, my company has been growing fast, and we had to recruit another programmer. I am a younger programmer, I have always worked alone, well-read but never been in a team.

I prefer an agile coding style and SOLID principles.

My colleague, however, despite having worked as a programmer for ~10 years longer than me, has no interest in code standards whatsoever, and it's causing major issues in our line-of-business applications. Our main CRM application (which was built over a number of years and contracted to the company my colleague used to work for), which my colleague was originally brought in to fix, now suffers database crashes several times a day, and the team of people using it are losing lots of productivity.

  • My colleague considers unit testing a waste of time
  • 4000-line long classes, never using interfaces, and procedural style are the norm for them
  • Through my colleague's successive attempts to "speed up" the CRM and solve database issues, the CRM now uses 3 different ORMs throughout.
  • My colleague prefers to roll their own, unconventional approach to common problems. For instance, our CRM loses customer data without trace due to a home-grown caching layer built with stored procedures and temporary tables.
  • Projects set up by this colleague have the bin and obj folders in version control

Because we're stretched thin across multiple projects, and I haven't seen alot of what they've written, my colleague has had free reign to write bad code without checks. My boss asked me to ask this question because there need to be some unit tests and code quality checks in place, the business is severely hemorrhaging money from bad code.

We need to know, having never managed a software team before:

  1. Is writing faulty code like this 'normal'?
  2. What do software teams usually have in place to stop bad code being committed like this?
  3. I'm looking for techniques that are maybe specific to a two-person team, where one person is unwilling to follow code standards
  • 9
    This is more of a question for Programmers as it's strictly about software development and best practices, which is not specific to a workplace environment. – Lilienthal Nov 23 '15 at 10:08
  • 2
    Take ownership of a more stable release branch of the code and then refuse to accept the dev's changes into that branch until they pass all of your tests. The tests should at minimum test that known bugs are not reintroduced after a change. Gradually make your tests more strict, such as requiring certain coding guidelines are followed. – Brandin Nov 23 '15 at 10:17
  • 2
    @Lilienthal this question is a poor fit for Programmers - it would be quickly voted down and closed over there, see meta.programmers.stackexchange.com/questions/6483/… – gnat Nov 23 '15 at 13:13
  • @gnat Note that I'm not recommending migration, just pointing out that the core of the question is related to programming not the workplace. I make no judgements on the merit or usefulness of this version of the OP's question on that site but a few of his questions could possibly be reworded to something that is useful there. – Lilienthal Nov 23 '15 at 13:26

I worked in a two person team and I will tell you what I feel worked very well for nearly two years.

  1. Chain of command, I was the junior coder and the other coder was the senior. This gave us a clear point where someone had to 'make the call' if we disagreed.
  2. A formal company coding standard, written by us but put in as a company procedure. That meant that anything that didn't follow this was wrong regardless of if it worked.
  3. Peer reviews, I looked over his code and he read mine and gave each other feedback.

I'm still good friends with the guy I worked with under these rules and any time we disagreed we had a clear framework to resolve the issues.

To address your other questions:

  1. Bad code/hard to maintain/difficult to read code is fairly endemic either because people are under pressure to produce or they just don't have the skill or motivation to improve it.
  2. See Dawny33's answer.
  3. I tend to agree with Dawny33's answer but I would say to focus on quality. There are a lot of blogs and tutorials that are out of date, contain errors or flat out contain a bad solution. Don't just take the first search result as gospel. You might want to try writing code for a problem and submitting it for peer review. https://codereview.stackexchange.com/
| improve this answer | |
  • Good answer. Very helpful suggestions I can go back to the boss with. Do you think if we ended up with a team of 5 programmers in the future, this kind of process would still work? – glcheetham Nov 23 '15 at 10:36
  • +1 company mandated quality is always best even if you have to get a third party in to write it up. – Kilisi Nov 23 '15 at 10:48
  • I think it does scale to a small team. Eventually the company had four programmers and a technical manager (former programmer) and it pretty much worked the same way with the technical manager resolved disputes. The main thing that helped was there was someone who understood code who could make a ruling in a dispute. – Dustybin80 Nov 23 '15 at 10:49
  • @glcheetham: The listed suggestions are the least that needs to be in place for a team of any size. Even large teams have these procedures in place, possibly extended with a few more. – Bart van Ingen Schenau Nov 23 '15 at 11:05
  • 1
    I think codereview.stackexchange is for code, there is a programmers stack exchange that might be more appropriate. – Dustybin80 Nov 23 '15 at 11:27

In addition to Dawny33's answer and Dustybin80's answer, I would add some kind of build system to your workflow. Today there are many systems that are easy to setup and are cloud hosted, some examples are Travis CI, Semaphore, and Bamboo. Learn how to make the build fail with test failures. Enforce as a team that tests failing means that the task is not complete.

I would also suggest publishing unit test coverage, which can be easier or harder depending on your workflow, but the general idea would be to look at current test code coverage, and as policy do not let test coverage fall below current coverage, since it sounds like you do write unit tests. What this does, is force some amount of test coverage, and prevents your colleague from @Ignore-ing any test that he breaks.

My colleague considers unit testing a waste of time

I have encountered this attitude, and I have found that some of the resistance is unfamiliarity with how to write unit tests, and how to write testable code. Usually, the uninitiated write their app code first, test it manually, try to write a unit test, get into dependency hell, and decide that the few hours they just spent trying to write a test would have been better spent writing new app code. A 4000 line method is not easy to write unit tests for, and that is what they currently see. Suggest that the 2 of you pair program, and walk him through writing a simple unit test first and then a more complicated one. Then enforce testing through chain-of command and code review that he follow this, and coach him through training.

| improve this answer | |
  • 1
    Pair programming is a great idea, that I didn't consider. We already use TeamCity, but because most of the big projects don't have any tests, we're missing out on the best CI stuff. I'm currently re-writing one of colleague's smaller projects with TDD, so hopefully I can lead by example. – glcheetham Nov 23 '15 at 15:56
  • leading by example is a great way to change habits :) – adeady Nov 23 '15 at 17:09

Is writing faulty code like this 'normal'?

Depends on the company, team and the practices followed by the team

What do software teams usually have in place to stop bad code being committed like this?

Code Reviews Having code reviewed by some other person in the team or by a senior helps a lot. It would help in identifying bugs which the author might not foresee.

What can I personally do to learn common code quality workflows and checks and how to implement them?

There are tonnes of resources in the form of tutorials, blog posts, etc from which you can learn best practises. Having them documented down for the team would also go a long way in ensuring the team writes good code.

| improve this answer | |
  • 2
    We use TFS, with a review step incorporated for every check-in. The task is not complete until it has received a satisfactory review by a peer. It works surprisingly well and reduces bugs quite significantly. – Darren Young Nov 23 '15 at 11:35
  • 1
    Yes, even we also use stringent code reviews, which is conducted by peers in the team. It works really well. Bugs, which you might not even identify, would come out then :D – Dawny33 Nov 23 '15 at 11:37
  • 1
    @DarrenYoung We're using git, but this is a great idea and I'll look at achieving something similar. Perhaps with git hooks or our CI/build server? – glcheetham Nov 23 '15 at 15:59

Not the answer you're looking for? Browse other questions tagged .