Programmers love to optimize their code and their tools. Why then is there so much slow and bloated code and so many arcane and fragile tool chains? Because programmers aren’t always optimizing for efficiency. There are many things programmers can optimize for, and a team can quickly end up working at cross purposes when everyone is optimizing for something different. Here are just a few of the things programmers optimize for:
Speed, memory usage, efficiency
What most of us think we mean when we talk about optimizing: making the code as fast and efficient as possible.
Conciseness
There’s a line between concise expression and obfuscation that we recognize when we see it, except in our own code. If you can’t easily understand someone’s code because it’s too terse, and they defend it by citing Occam’s Razor, that line has been crossed.
Complexity
The flip side of conciseness. Some programmers enjoy making code more complicated than necessary, but usually this optimization is a side-effect of forgetting YAGNI (You Aren’t Gonna Need It) or going off into the weeds with a new language.
Obsessive-Compulsive Disorder
When a programmer spends a lot of time lining up comments, converting tabs to spaces, converting all variable names to a single style, etc. they are optimizing to relieve their OCD. Converting all variables to Hungarian notation and forcing the team to comply “for consistency” is an extreme form of this optimization and may require an intervention.
Showing off
Looking ahead to the next code review or scrum, the programmer writes code that they can show off to the team. The code will be just clever or obscure enough to require the author to explain it to everyone and show how clever he or she is.
GitHub, StackOverflow, etc.
Showing off in public, and usually looking forward to either adulation or picking a fight in an online forum.
Job security, technical debt
Code is written with an eye to making maintenance and future enhancements difficult for anyone else. When a programmer is recognized as the only person who can work with a code base they are guaranteed employment.
Ritual, ideology, purity
Everything must comply with a methodology or fad. Programming decisions are defended by appeals to the authority of scrum, TDD, functional programming, etc.
Passive-aggression, being right
Failing to persuade co-workers to do it their way, the programmer changes a big chunk of code over the weekend to force the team to come around. Replacing a crucial piece of the testing or build process with something written in that cool new language is an example of this optimization.
Style, usability
Nothing will be released until everything conforms to the opinion of an expert. Tufte and Nielsen will be referenced.
Novelty
The project is optimized to make a new language or tool seem like a good solution. Programmers read about something cool online and suddenly the project can’t succeed without it.
Testing
The code is optimized so all unit tests are green.
CYA
Not wanting to be blamed for anything leads to code that can be defended against any criticism.
Meetings
Creating roadblocks and diversions in the code to force a meeting about the new problems. Meetings are an opportunity for schedule and specification changes.
Marketing
The code is optimized to meet ever-changing marketing requirements. These are frequently in conflict with each other, to say nothing of core business requirements, leading to HAL 9000 syndrome.
Ignorance
Code has to be written so the least-skilled programmers can understand it and work on it.
Comments
Alex, 12 May 2013 at 6:38 pm
Testing The code is optimized so all unit tests are green.
Isn’t this part of expected optimizations? Along with speed and efficiency it should also, ya know, work.
“If it’s not tested, it’s broken.” –Bruce Eckel
Danyel Lawson, 13 May 2013 at 5:05 am
The road to programming hell is paved with the quotations and rules of thumb of self proclaimed experts. Not one of which seems to be at acquainted with the scientific method.
Scott McClure, 20 May 2013 at 10:38 am
Frankly the quote from Mr. Eckel makes sense. Programming does not fall in the purvey of the scientific method. We are not formulating a hypothesis, we are writing code to solve a problem.
John, 27 August 2013 at 5:52 am
From my experience I can say that, the most visible reason for the programmers not seeking to optimize their code is plain laziness and then many a times there are stifling deadlines, which give little time to organize and optimize the code.
Greg Jorgensen, 13 September 2013 at 11:51 pm
@Alex, this article is satire, and what I’m poking fun at is the kind of TDD that only does unit testing and cherry-picks tests to get that green light after a build. Nothing necessarily wrong with TDD but passing all of the unit tests doesn’t say much about whether the app is bug-free or correct, nor does it insure the app meets requirements. It’s just one dimension of development, and if programmers optimize just along that dimension they are doing it wrong.