Python Coding standards vs. productivity

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)

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 🙂

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.

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.

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.

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.

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.

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.

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.

Filed under: softwareengineering - @ 07:56

Thẻ: coding, python, standards

Thiết kế website giá rẻ

Danh mục

Python Coding standards vs. productivity