The other day I had a brief discussion with one of my colleagues. We were talking about an ongoing process of standardizing things in the company. It is happening now on different stages from project management methodology through development practices up to organizational level.
I can’t deny there are valid reasons which stand behind these actions. This is out of discussion. However, during the discussion, we agreed that there are situations where we’re throwing out the baby with the bathwater.
Take a discussion about coding standards for example. The discussion is good since I believe every project should be written according to some, predefined, schema. This improves quality, helps to maintain code and makes it easier to overtake the code when a newbie developer joins the team. If we’re going to bring better quality at the end of the day I’m all for the initiative.
At the same time the discussion is wrong because it went to a place when we’re trying to set a single coding standard for the whole company. If you have a couple of dozen development teams there’s virtually no chance everyone would agree on a single set of rules. So we’re stuck with discussions whether we should have loads of comments inside code or rather no comments at all. Or the one whether Hungarian notation is a good thing or a bad thing. Hey, maybe we should start .NET versus Java flame war? Would suit here fine.
A problem with standardization is with deciding how far it should go. I believe we should be told we have to define and follow coding standards. But I don’t want to be told whether I should use this funny prefixes in names of functions and variables. OK, I’m not coding anymore so example is irrelevant but still it makes the point. I believe we should be told we have to implement continuous integration (hey, why anyone would wait to be told that?) but telling us how exactly we should configure our build process is a bit too much for me.
If you standardize things too much you probably end up with two things:
• People turn off their brains. Why should they think when procedures tell everything?
• New ideas aren’t going to be implemented. Even when someone comes with new procedure-breaking idea it won’t be used since it’s, well, procedure-breaking. On the other hand procedures won’t be changed so easily because so many folks already follow them and it would so hard to change people behavior.
It doesn’t have to be bad automatically. If you have a factory making T-shirts in one of developing countries this may be even good. Unfortunately I don’t expect to have many cloth manufacturers among my readers so we may skip to another paragraph.
OK, this is wrong. There’s no such thing as a single, universal way of software development. If your developers are forced to use practices they hate they’ll underperform, become frustrated, eventually quit, fund their own startup, go IPO, buy out your business and fire you. Or they’ll just go to another company in the area.
If one team is willing to use one set of rules and another one prefers different ones go for it. There aren’t many software development or project management principles which are just wrong. You can have a great code no matter whether you use Hungarian notation or a different one, add hundreds lines of comments in the code or none at all, define old-fashioned customer requirements or user stories, having project management methodology PMP-like or Scrum-like.
Standards are good. But too strict standards or too much standardization is shortsighted. When you deny people to adjust their processes to the specifics of their work, team and project you reject opportunities to improve your work and invite a lot of frustration among your people. That’s why I’m always aware when it comes to standardization.