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.
Comments
mike on 30 September 2013 at 9:14 am
Coding out of a fetish is stupid… coding with reason is logic.
Eldc on 30 September 2013 at 11:27 am
There still is usefulness in having a consistent coding style. Enforcing things too strictly is certainly a problem, but having gotos everywhere is still going to make things difficult. As always, seek balance: http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
Anton on 1 October 2013 at 5:18 am
You forgot that code line should not be longer than 80 symbols.
Greg Jorgensen on 1 October 2013 at 10:30 am
@Eldc I agree that a consistent style is useful, though not as important as some programmers think it is. Agree on some ground rules and move on. Do code reviews and if someone is writing truly unreadable code do something about that.
@Anton I haven’t forgotten, just blocked it out. The 80 line limit came from punch cards and was perpetuated by dumb terminals for way too long.
Dave Goldman on 2 October 2013 at 12:10 am
Greg, your use of blank lines between left-justified paragraphs is simply wrong. Proper paragraphs should be first-line-indented (5 spaces or 0.5 inches, depending on medium), without extraneous vertical spacing.
I’ll be happy to discuss this at length.
Greg Jorgensen on 2 October 2013 at 9:08 pm
@Dave I have compiled a list of references and style guides refuting your statement about indentation. I’ll be happy to send those to you separately and then arrange a series of meetings to discuss. I don’t have enough free space on my hosting account to upload all of the materials.
Gjorgji on 3 October 2013 at 7:33 am
Nice post, I had experience with a really Nazi-style senior java developer. I coded some functionality for couple of hours and then send the patch to integrate into the system. I can tell you that we spent good 1-2 hours, just on style of one comment.
A good engineer know how to apply good coding practices, bad developer just blindly follows them.
Vasiliy on 4 October 2013 at 7:49 pm
I haven’t seen any projects “go off the rails because of strict adherence to some practice, rule, or fashion”.
I have seen projects that became irrelevant during development or soon after, I saw a project that could not find enough customers. But I don’t remember any serious problem happened due to strict following of a rule.
Disclamer: I am not a big fun of coding style guides and rules.
Sherial on 6 October 2013 at 8:06 am
Thanks a lot for sharing this. It covers a lot of questions that were bugging me for some time. I started a blog recently about my journey to become a professional programmer, decided that it might be cool for people to see the entire process. Please let me know what you think: http://www.syntaxthis.com.
Paul on 11 October 2013 at 2:44 am
“I can tell you that we spent good 1-2 hours, just on style of one comment.”
@Gjorgji the more worthwhile discussion he should have had with you would have been, why is there even a comment their in the first place.
John on 16 October 2013 at 4:21 am
Modern IDEs make implementing a common style as easy as pie.
The successful projects that I have worked on have all insisted on (and implemented) a basic, common, style. I agree that spaces vs tabs and braces styles shouldn’t be the most important thing – but when the team can’t even agree on those how on earth will they agree on the more detailed stuff.
I’ve seen plenty of devs arrive on a well established and well run project and insist that they are an “artist” and should be allowed to choose their own style. It RARELY works out well.
Eclipse on 4 November 2013 at 11:17 am
With right tools such as Eclipse or InteliJ you can format all java files according to your style with one keyboard shortcut press. So this will not take you any time at all. Just initially 1-2 hours to setup common style.
Edward Patel on 11 February 2014 at 5:14 am
Think this also comes down to “open mindsets” vs “closed mindset”. Maybe it’s more “close mind” programmers around… http://aynrandlexicon.com/lexicon/open_mind_and_closed_mind.html
Angelito on 9 April 2015 at 8:01 pm
Excellent post.
Nowadays many developers spend more time discussing techniques (often unnecessary) instead of spending time writing really good code.
And if you do not use their techniques, is an amateur, beginner, asshole…