In my career as a programmer I’ve seen lots of projects go off the rails because of strict adherence to some practice, rule, or fashion. It may be something the entire team has bought into, like OOP or TDD. It may be something a single member of the team bullies everyone else about, like tabs vs. spaces or braces style. Even a programmer working alone can sabotage a project by honoring fetishes above productivity.
Here are just a few of the fetishes I have observed wasting hours and days of programmer time:
- Spaces vs. tabs, how much to indent each line
- Braces style
- CamelCase, mixedCase, names_with_underscores, etc.
- Variable naming conventions, especially Hungarian notation
- No function can be longer than 50 or 100 lines, or no function can be more than one printed page
- Never use GOTO, eval, operator overloading, singletons, or some other language feature deemed evil
- Functions can have only one return
- No global variables
- Pure OOP, pure functional
- Design patterns
- TDD (test-driven development)
- Gannt charts, Agile, Scrum, Extreme, User Stories
- Never use SQL stored procedures, or always use SQL stored procedures
- SQL vs. NoSQL
- Never use PHP short tags
- All web interfaces must be RESTful
- HTML must validate with W3C
- Strict XHTML
Not all of these things are necessarily bad ideas. And it is important for programmers on a team to follow some guidelines so their code is understandable and plays well with the rest of the system. The problems arise when a programmer or a team decides that purity according to an arbitrary rule is more important than delivering a working solution. If someone is paying you to develop an application or solve a business problem it really isn’t important how the source code is indented. It is important to the customer that the programmers not waste many billable hours debating whether singletons are bad or not, or if all of the variable names follow one person’s favored convention.
The problem is similar to cargo cult programming. It’s bad enough when newbie programmers do things without understanding why. It’s worse, I think, when experienced programmers turn their own preferences and biases into fetishes and then force themselves and everyone they work with to follow them, even when that means putting the project at risk.
For the last few years I’ve specialized in debugging and fixing code, a lot of it abandoned when the developer and the customer divorced over budget and schedule overruns and missed expectations. I see code that doesn’t even work sprinkled with self-congratulatory comments referencing the GoF patterns. I see badly-written replacements for library functions that exist only because the programmer decided that the standard version’s name sucks. I see specs full of justifications for technical choices that don’t mention important business rules.
I also see lots of code that doesn’t use my preferred indentation, tabs, braces style, variable naming, etc. Spending time “fixing” the code to satisfy my aesthetic sense would be a waste of time and money for my client. I’ve figured out that code that wasn’t written to my tastes is really no harder for me to read and maintain than my own code.
Methodologies, techniques, and best practices should be understood and used to solve problems, not worshipped as rules that must be obeyed no matter what the cost. If you are spending more time debating naming conventions with your colleagues (or yourself) than you are writing code that solves a problem you are wasting time with programming fetishes.