In the class of verbs known as modal auxiliaries, I don't have many axes to grind. "Might" is OK. I can deal with "Could". "Must" is often annoying, but a sad reality. However, the word "should" is the one which sends shivers down my spine. Its use is often a code smell embedded in the foundation of how we communicate, leading people down the primrose path to a faux nirvana.
Rather than just rant without context, I should give you some examples. Here's a great one.
Your test suite should run faster.
Please note that I have never assaulted anyone for saying that. However, I think another quote is in order.
But I say unto you, That whosoever looketh on a programmer TO commit grievous bodily harm on him hath committed assault on him already in his heart.
Ovid 5:28
OK, I'm guilty of assault.
Yeah buddy, I know my test suite should run faster. I know that having a test suite taking two hours to run isn't optimal and breaks the tweak/test/tweak/test cycle. I also know that I can sometimes use tools like Devel::CoverX::Covered to narrow down what I really need to test for a particular change, but when those tests still take 10 minutes to run, that's still killing the tweak/test cycle. The reality is, sometimes test suites don't run in 15 seconds. Deal with it.
Here's another quote, this one another annoyance.
The programmer should just read the documentation.
And another quote to illuminate that.
Do not think that I came to update the documentation or the comments. I did not come to update but to create. For assuredly, I say to you, till heaven and earth pass away, one jot or one tittle will by no means be changed in the documentation till all is fulfilled.
Ovid 5:17-18
At the end of the day, relying on documentation is simultaneously mandatory and a fool's game. CPAN documentation is very hit-or-miss. It's often underdocumented, poorly documented, or incorrectly documented. DarkPAN code, on the other hand, tends to be undocumented. So I have to read the source, but the source is often a confusing mess which reflects a poor understanding of requirements or years of maintenance and subtle bug tweaks that are critical, but poorly understood.
Here's another fun quote.
Programmers should choose the appropriate language for the task at hand.
And the requisite illuminating quote.
And Larry answering said unto them, Render to Management the things that are Management's, and to Programmers the things that are Programmer's. And they marvelled at him.
Ovid 12:17
When you know that Mercury is the perfect programming language to solve that thorny scheduling problem, you might get very annoyed when management says you must write it in PHP. But let's think about this for just a moment. If management says "everything is a nail and PHP is our hammer", you have every right to be frustrated at this short-sightedness. However, consider the other extreme. What if you have 30 programmers using 30 different programming languages, 5 different source control systems, 6 different operating systems, 4 different database management systems, 7 different packaging systems, etc. See the problem? No? Ask a system administrator who has to deal with this. TIMTOWTDI is brilliant, but often doesn't scale. If management tends to go to the other extreme, it's often the programmers who are to blame, failing to demonstrate the virtues of flexibility.
Many times when I hear programmers talk about "ideals" (i.e., using the word "should"), their heaven and my reality are often at odds with one another. Sometimes I'm talking with very brilliant people who nonetheless seem to have very little experience working on large-scale code bases in business environments. My jaw drops when rebuttals to things I say are based on ideal worlds where everyone pair programs, test coverage approaches 100%, refactoring is commonplace and documentation is always perfect and up-to-date. Even if this was true for any given system, when it's approaching 600+ classes, it's not reasonable to expect programmers to know the ins-and-outs of every part of the system.
More importantly, it's not reasonable to expect that business needs, which are often a constant juggling of competing requirements and synchronization across multiple teams, should be subordinate to the programmer's desire to get to programming heaven. There must be balance. Throw away your programming Bible and start thinking about the Yin and Yang of business and technical requirements. If you can't balance them, you should be ashamed of yourself.
Next time you hear a programmer using the word "should" in a debate/argument, listen carefully to what they're saying. Are they seeking an unattainable Nirvana? Call them on it. "Should" is a dangerous word.
My favorites are »$module should do that for me« and »I shouldn't have to think about that.«
The latest example I can remember, a coworker stated baldly, "queries like this should run in under 1 second."
I probably should have bit my tongue, but I couldn't help replying with, "sure, and I want a pony, but that's probably not going to happen." I think he still harbors some resentment for that...
Re:A pet peeve of mine too
Ovid on 2009-09-15T19:06:09
Unfortunately, I've been known to make replies like that myself. I get in trouble for it
:)
If you tell weightlifters that they should be able to lift a weight, they are able to lift less weight than they can if you tell them that they can do it.
Hearing the word "should" makes you weaker. Literally!
And then we just do some testing, and we'll be ready for production.
Re:Mine is "just"
Ovid on 2009-09-16T08:32:39
:)
Re:Mine is "just"
Aristotle on 2009-09-16T10:03:06
See also. (The comments are fun too.)
