Programming shortcuts - debate?

[Carrie Cobol]

In another thread, we got off topic a bit and started talking about some programming shortcuts.  Goddard said he thought it would be an interesting discussion.  So copying the last part of the discussion here:

Storing ascii data in a numeric field.  I mean, come on.  Sure you COULD.  You could also jab a fork in your eye. 

There was more, of course.  As I went through and replaced all the MOVL instructions with MOVC (move character), I discovered that in one place they were also using R0 (register) as the pointer to a very important data structure.  The MOVC family of instructions clobber R0 with their return value (success/failure), so I had to fix that too.  That's probably why they used MOVL to begin with.  As you said, being clever.

Kind of like the coworker I had in my first programming job who used a variable to compute line numbers that the program was going to jump to.  This was with Vax Basic, where line numbers were mostly optional and labels were perfectly fine.  Because GOSUB <label> was too freaking easy, he had to GOSUB <varname>, in a loop and compute the target at each iteration.  The program was so dense that I had to have him explain it to me.  I was like "oh....  okay, that's clever...."  and immediately rewrote it for maintainability.

I guess my first comment about it is that I am really skeptical about shortcuts.  In that I doubt they really *are* shortcuts.  As in my Vax Basic example above, I think he was just showing off how clever he was by being obtuse.  In the Macro example of using a MOVL to move 4 character bytes, that's a shortcut for the developer but a headache for all maintenance programmers who come later.  What do you guys think?  Do you have any interesting examples of shortcuts that caused headaches later on?

[The Gorn]

I don't have a ready list of toxic shortcuts like those, but I can comment on the general practice.

Same thing with the Y2K issue. Some programmers, teams and companies up through the 1980s completely ignored the issue of the year field rolling over from 99 to 0.

And I have gotten into some heated discussions with a team member who has looked on some of the design compromises or coding practices that I committed on the project so far as being sloppy, unworkmanlike, or beneath him. He takes a very long term perspective on the work, like you want to write code that can be hung on a wall or explained in front of a committee, and generally, I am trying to get some proof of concept working in order to convince my client that the project is worth doing in the first place. Or otherwise I feel under pressure due to short term time constraints as a contractor.

It's easy to take pot shots at other people's "crappy" practices. I've done so many, many times myself.

I think what motivates shortcut taking is the idea that a priority such as simplicity, easier code to develop and test, and/or perhaps even pressure from a technical lead on a project, leads to a shortcut being taken.

Someone decided (somehow) that completeness or coverage of more situations matters much less than completion time of the work.

Also, I have sometimes taken shortcuts based on a philosophic notion that even expanding the range of contingencies handled greatly still does not make the code "perfect", it just reduces the probability of an out of band result somewhat.

If I see the asymptote of a curve that describes that declining probability of a problem fall off quite steeply where I make my shortcut, I will tend to be comfortable with taking the shortcut.

Now, I am describing an educated approach to shortcuts.

What you really have to watch out for are shortcuts committed by someone who doesn't know and doesn't care, either.

An example of this in real time programming is someone who doesn't protect data structures with a mutex. Or, someone who disregards the likelihood of race conditions.

Before I criticize a shortcut too heavily, I want to know what the developer was thinking. Maybe he really had his reasons.

Or, maybe he just sucked and had poor knowledge that he is defending.

I've seen equal measures of both ends of the spectrum.

[Carrie Cobol]

It seems to me that young programmers take shortcuts out of ignorance, and older programmers take shortcuts because of project deadline pressure.  Massive generalization, there, I admit.  I know that it was one of the biggest business/professional lessons I had to learn that was never taught in school - that business deadlines always take priority over code quality.  It still bugs me occasionally.

I find that the shortcuts I most often take are omitting error handling for things that rarely happen.  When I'm writing code, and am tempted to make the error message "this should never happen", those are the ones I am always tempted to skip.  However, those exact errors are frequently posted in screenshots of end-user's computers (kiosks, pos terminals, whatever) on TheDailyWTF, so I do know better, even if I still do it.

[The Gorn]

It seems to me that young programmers take shortcuts out of ignorance, and older programmers take shortcuts because of project deadline pressure.  Massive generalization, there, I admit.  I know that it was one of the biggest business/professional lessons I had to learn that was never taught in school - that business deadlines always take priority over code quality.  It still bugs me occasionally.

That's exactly what I am describing. I judge the shortcut biased heavily by my understanding of how expert the developers is. I sort of look on a shortcut as a statement of probability by the programmer - when he is experienced.

However, I have seen older developers (me!) get sloppy and do things like not check return values for API calls and the like.