16

I work for a large humanitarian organisation, on a project building software that could help save lives in emergencies by speeding up the distribution of food. Many NGOs desperately need our software and we are weeks behind schedule.

One thing that worries me in this project is what I think is an excessive focus on coding standards. We write in python/django and use a version of PEP0008, with various modifications e.g. line lengths can go up to 160 chars and all lines should go that long if possible, no blank lines between imports, line wrapping rules that apply only to certain kinds of classes, lots of templates that we must use, even if they aren't the best way to solve a problem etc. etc.

One core dev spent a week rewriting a major part of the system to meet the then new coding standards, throwing away several suites of tests in the process, as the rewrite meant they were 'invalid'. We spent two weeks rewriting all the functionality that was lost, and fixing bugs. He is the lead dev and his word carries weight, so he has convinced the project manager that these standards are necessary. The junior devs do as they are told. I sense that the project manager has a strong feeling of cognitive dissonance about all this but nevertheless agrees with it vehemently as he feels unsure what else to do.

Today I got in serious trouble because I had forgotten to put some spaces after commas in a keyword argument. I was literally shouted at by two other devs and the project manager during a Skype call. Personally I think coding standards are important but also think that we are wasting a lot of time obsessing with them, and when I verbalized this it provoked rage. I'm seen as a troublemaker in the team, a team that is looking for scapegoats for its failings. Since the introduction of the coding standards, the team's productivity has measurably plummeted, however this only reinforces the obsession, i.e. the lead dev simply blames our non-adherence to standards for the lack of progress. He believes that we can't read each other's code if we don't adhere to the conventions.

This is starting to turn sticky. Now I am trying to modify various scripts, autopep8, pep8ify and PythonTidy to try to match the conventions. We also run pep8 against source code but there are so many implicit amendments to our standard that it's hard to track them all. The lead dev simple picks faults that the pep8 script doesn't pick up and shouts at us in the next stand-up meeting. Every week there are new additions to the coding standards that force us to rewrite existing, working, tested code. Thank heavens we still have tests, (I reverted some commits and fixed a bunch of the ones he removed).

All the while there is increasing pressure to meet the deadline.

I believe a fundamental issue is that the lead dev and another core dev refuse to trust other developers to do their job. But how to deal with that? We can't do our job because we are too busy rewriting everything.

I've never encountered this dynamic in a software engineering team. Am I wrong to question their adherence to coding standards? Has anyone else experienced a similar situation and how have they dealt with it successfully? (I'm not looking for a discussion just actual solutions people have found)

Improve this question
12
  • 5
    Remember that coding standards are intended to increase long term productivity. This comes at a cost of short term productivity if the existent project was not following any standard for a long time.
    – Arseni Mourzenko
    Commented Aug 29, 2012 at 18:11
  • 2
    Just program Eclipse and PyDev to autoformat your code according to the coding standards. It's a matter of filling out a few dialog boxes.
    – user16764
    Commented Aug 29, 2012 at 22:48
  • 2
    @DemianBrecht - Collaboratively authored coding standards which are defined and agreed by all coders are a good thing and can improve long term productivity. Authoritarian coding standard, imposed from above with no buy-in from the team are a huge waste of time and can doom a project to stagnation or even regression, as exemplified by the so called lead developer throwing away tests because the code re-factored to the new standard failed those tests. Honestly WTF?
    – Mark Booth
    Commented Aug 30, 2012 at 11:14
  • 1
    @MarkBooth: You can't please everyone. I agree that if it's simply imposed from above it's more difficult to get buy in from other members, but it's still not a "huge waste of time". In having the standards in place, the code should be much more consistent and therefore you would run into less diversity in code throughout a project, which increases readability. But yeah.. Throwing away tests due to standards would lead me to believe that there were bigger problems under the hood.
    – Demian Brecht
    Commented Aug 30, 2012 at 14:18
  • 2
    @Demian Brecht: I'm sure the fundamental point in this question isn't the coding standard as such, but the fact that cosmetic issues with the code gets higher priority, basically than anything else in a project that is late and of high importance.
    – Buhb
    Commented Aug 31, 2012 at 6:39

8 Answers 8

Reset to default
26

The coding standards aren't the problem. The problem is that management can't figure out what the problem is. This leads to "Do something…anything!" mode. You're looking for a rational solution, but it's an irrational problem. The best you can do is:

  • Give constructive criticism of their ideas, but once the decision is made don't continually whine about it.
  • Do whatever you can to make the rewrites easier.
  • Stop stressing. Missed deadlines are management's problem, not yours. Do your best, but don't assume responsibility for their poor decisions.
  • If you know something that might help, tell them. Your mention of standups makes it sound like you're trying to do agile, but the rest doesn't sound very agiley. See if you can deliver limited functionality earlier instead of trying to meet one big deadline with everything. Create user stories for the rewrites so it's clear how they are impacting the backlog.
  • Start looking for another job. Seriously. Companies in such a state aren't far away from starting to fire people.
  • Get some "told you so" T-shirts printed up :-)
Improve this answer
2
  • Good points. Actually I'm not against coding standards, e.g. the new addition to the standards during the last meeting was to mandate docstrings on every class and function, which makes sense to me, and I mostly do that anyway. The money is way too good to look for another job. I tried out the code reformatters, although I suggested it to the team the lead dev banned their use. I work remote and this rule can't be enforced, so I'm finding pep8ify is the one to use because it makes code just pass the standard, so it looks like human edits. I.e it does minimal modification.
    – Shroatmeister
    Commented Sep 1, 2012 at 9:25
  • 1
    I would add that the deadline will be missed, almost certainly. This is a death march and someone will try to blame you. Just be sure you document everything: keep track of how much time you spend on each task, archive all mails and/or chat logs so that you can defend yourself.
    – coredump
    Commented Oct 23, 2014 at 9:32
8

Someone needs to decide if shipping or slavish adherence to coding standards is the real priority. I know what my preference would be; if it's passing unit and acceptance tests, I say ship. Once it ships, the company can decide whether or not to spend the time and money to fix the technical debt.

Problems with spaces after commas are easily solved with a code prettifying tool. Find a tool that enforces all of your coding conventions, and run that tool on all modified code before the build and testing takes place. Decent IDE's already do this, while you're writing the code.

Improve this answer
1
  • I've found pep8ify useful for this reformatting. It seems to do minimal modification to meet standards, and the code is easy to modify, although command line configurability is somewhat limited.
    – Shroatmeister
    Commented Sep 1, 2012 at 9:34
4

Am I wrong to question their adherence to coding standards?

It depends on the group. Personally, I think that everything should be questioned. Some people take that questioning to be an affront; that I don't trust them.

Has anyone else experienced a similar situation and how have they dealt with it successfully?

I asked how these standards improve productivity. I measured the time I spent screwing around with the standards vs 'getting stuff done'. In the end, the powers that be decided to stick with the standards. It happens. I complained about them louder than usual when they were the cause of me not getting stuff done, but otherwise focused on getting my work done. Fighting about things continually isn't good for productivity either...

If, as you say, things are measurably worse due to the standards, then adhering to the standards should invalidate the lead's argument and leave yours. If people cannot see that (largely) objective correlation between the standard's implementation and the drop in productivity, then there's not much more you can do. Learn to deal with it, and if you can't, look for somewhere less bureaucratic.

Improve this answer
3

Standards are something that shouldn't be put in place late project with a deadline looming. It's something that should have been put in place early in the project or when there's time put aside in the project schedule (preferably post initial ship) for (potentially) large offending code refactor.

If this was in fact put in late in the project, then it's a mistake made by your lead (IMHO).

However, this does not mean that if you disagree with your lead that you should just charge ahead with mutiny. This is your job. You work as a team. You have a lead. There should definitely be some level of democracy in the team, but at the end the lead is the dictator. If he says to do something, you do it.

In the end, in complying with his requests and standards, you don't provide him/her with an easy scapegoat for missing deadlines.

Also, I'm a huge advocate of coding standards (especially as the size of a team grows), but they should be implemented when it makes sense.

Improve this answer
1

Your question was ''Am I wrong to question their adherence to coding standards?'. http://c0x.coding-guidelines.com/Introduction.pdf (for C programming language) has some referenced studies on the value of coding guidelines. See section 9 starting on page 39.

Coding standards are implemented for a reason. One thing that seems missing from the original question is an understanding for the reason for these particular standards on the particular project (or in the particular organization). The decision to implement them on existing code was based on some logic. Without knowing the logic, it is hard to comment of 'goodness' of that decision.

I'll second what someone said that standards are implemented for 'long term productivity' - issues like maintainability of the code. Maybe some event occurred which set the project back severely because of confusion and misinterpretation.

It sounds like there is a lot of emotion on both sides - try to get to reasoned discussion.

Improve this answer
1

As you've probably seen by the other answers and comments, your project has big problems, so what I'm going to suggest doesn't have a big chance of success, but it's something you can try without too big risk with regards to your own skin.

Ask for a meeting between four eyes with your lead developer. Say that you are interested in thoroughly understanding the benefits of being so strict with the coding standard and why the codebase was in such a bad shape before introducing them. It's very important that you keep a very open and "I'm trying to learn" attitude during this discussion. Your lead developer is probably already more stressed than you or anyone else on your team is, and will probably be very defensive as soon as he smells some critisicm.

Try to nudge the discussion into the direction of trying to figure out ways to meet your common goal; delivering working and maintainable software promptly.

For example, some low hanging fruit is to not add anything more to the coding guidelines. Everytime that happens, code that previously adhered to the guidelines no longer does, and this results in that you need to rewrite chunks of code. Hopefully your lead dev can see that even if the added rule adds value (from his point of view), it might not do as much good as to motivate the rewrite at this phase of the already late project.

If this works, you can try to have him remove the more arbitrary rules that can't be autoformatted with some tool.

Improve this answer
-1

Coding standards are good. Changing coding standards is expensive (well, it's expensive if you make them less permissive; if a change to the standard leaves all existing code still compliant, it's not a problem), so should only be done when absolutely needed.

One thing to to, maybe, is to have the lead check all code prior to commit/merge/whatever to make sure it complies with the standard, since apparently the existing tool-chain seem to be unable to check it automatically.

Improve this answer
-2

software that could help save lives in emergencies by speeding up the distribution of food

I believe in good coding standards, but I believe also that saving lives is much more important.

Your biggest priority must be saving people's lives. Imagine if this software is distributing food to your family, or your team. Anything else can come next.

The good news: you have tests. Tests will help you comply with your coding standards without breaking functionality, but this should happen after shipping, not before.

Improve this answer
2
  • 1
    What should happen after shipping? Comply with coding standards without breaking functionality? Having tests?
    – Martijn Pieters
    Commented Sep 25, 2012 at 8:12
  • After shipping, he should work on following the coding standard.
    – Mohammad Tayseer
    Commented Oct 3, 2012 at 15:37

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.