We Need Standards

Have you ever read a project codebase (yours or not yours) where you could find different ways of implementing the same thing? Different ways of implementing controllers, of writing tests. Don’t you think that is really bad?

If you answered yes to all the questions, I can say: me too :D

Recently I’ve worked in this codebase that has evolved trough time having different kinds of implementation for most of its basic components: different templates, different tests, different controllers, mainly because each developer had its better way, and no one bothered to synchronize with each other.

The result is that every time you open a specific file, you are not sure what to expect. And I had worked on it!
I wonder how someone that had never seen the code would react..

When looking back in the way we developed it, I kept thinking in how it would be much better if our team could develop code as one person would, having the same way of constructing the same things, having… standards.

But standards? How about innovation? We’ll just keep doing the same s£%^ code for years this way.. I know what you might be thinking, I had the same thoughts in the first time.

But there is where I think we can also learn from Toyota. They have standards, but they can change at any time, and I believe this could be easily applied to software projects.
Just because all the team decides how to build something, it doesn’t mean that they have to do it during all the project. Agile should be evolutionary, so the current standards should be always challenged. We only have to make sure that at any given moment, everybody should know the ways we write code.

And if I’ve found some case where the way we write controller’s tests doesn’t work, I can change it, and make sure that everybody knows what I’m doing. And to do this I might need just two simple tools: communication and (maybe) a simple wiki, where the team can write the standards being used.

And how about the benefits?

Well, having coding standards, the knowledge transmission among the team will be much better, since everybody will be forced to communicate and discuss why we are doing things this way. As a secondary benefit :D , you’ll develop code that is much more compreensible, manteainable and well documented.


  1. Agreed!

    I just think that this idea isn’t applied that much in the software world. At least not pratically.


  2. Bruno said:

    I agree with you point, but definitely not with your terms. I think it’s really easy to miss the point when using works like “standards”. It has a powerful connection with “micromanagement” or “top-down decision making” etc.
    I think it’s safer to say that in each project the developers should reach an agreement about the most common way to implement things – write it down, and use it when possible. Done.
    (because, of course, the point here is to reduce the number of different styles to a “manageable number” – not to eliminate all different approaches!)


  3. @bruno

    Agreed again.

    I think is easy to miss the point, but, as you noticed, I’m not supporting micromanagement, even because I don’t believe these standards should be set by one specific person, but by all members of the team reaching an agreement on “the most common way to implement things”, as you said.


  4. If your standards can change through a project, how does that help the “many different ways of implementing the same thing” problem? Do you go back and rewrite everything that uses the old way when you find a new improved way?

    Personally, I’m OK with leaving the code that uses “the old way” alone until I next need to touch it, but it does mean that my codebases might still have several ways of implementing the same thing.

  5. @Anthony

    I dont want the old code to be changed, and definitely agree with you about changing it if we touch it again.

    But despite still having different coding standards throughout time, we have one way of implementing one thing at any given moment. And I believe that this is much better that everyone implementing things their way…


  6. Delaney said:

    The problem as i see it is that Programming is an art and applying standards of any type would be analogous to asking Leonardo Da Vinci to constrain him self to a certain stroke and canvass. The inherent problem in our industry is that like artist some people have different degrees of talent and different ways of expression so the idea of code standards Although i my own option a good one will only be adopted by a thew and not by the mass so will have little effect on the majority of projects, But this phenomenon of only a thew enlightened individuals using sensible techniques is what keeps my rates high and Agile community /Religion Going! so long may it continue lol

%d bloggers like this: