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.

Cheers,
Francisco