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 
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 , you’ll develop code that is much more compreensible, manteainable and well documented.
Cheers,
Francisco
8 Comments
franktrindade on October 18th, 2008
Agreed!
I just think that this idea isn’t applied that much in the software world. At least not pratically.
Cheers,
Francisco
Bruno on October 18th, 2008
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!)
Cheers,
Bruno
franktrindade on October 18th, 2008
@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.
Cheers
Anthony Williams on October 22nd, 2008
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.
franktrindade on October 22nd, 2008
@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…
Cheers
thekua.com@work » Death by a thousand differences on November 1st, 2008
[...] One of the most common smells I see on projects is the desire to do things slightly differently for no good reason. Triggered by many different reasons such as new people joining a project, or when new functionality is being added, or when bugs need to be fixed. Each individual difference isn’t a problem on its own, rather it’s their accumulative effect that has a significant negative impact on projects that force developers to continually context switch when trying to match their mental model against the code or to navigate their way around a new area in the system. I find the death by a thousand differences is especially a significant problem on iterative projects where change happens rapidly such as the project Frankie describes. [...]
Delaney on November 3rd, 2008
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
Daniel Wildt on October 17th, 2008
One thing I’m discussing a lot lately is about standards… the thing is that I don’t see problems using standards. The problem is to standardize…
Here is one post I like, about this subject.
http://www.leanblog.org/2008/05/standard-vs-standardized.html