The section about programmers creating complicated (sorry “elegant”) code just to keep them interested in a project reminds me of one of the best lessons I learned in Software U.
It was in the Advanced Fortran class one evening, and our teacher, George, enters the room. His 35 students await the wisdom he has for us. Without saying anything, George turns on the overhead projector and slaps a transparency on it with a code fragment. He asked simply “what does this do?”, then waited. Our young minds couldn’t quite penetrate this problem, something to do with matrices is about all we could figure out. Finally, George shattered the silence and stated that that routine merely zeroed out a matrix. Nothing more. He then walked us through the code. It was elegant, and beautiful and fast! I glanced around, and noticed everyone else doing the same, smiling and nodding, all thinking “wow, that’s really clever!” all hoping they could be as clever as the code’s author. After a short pause, George said “I bet you think this was clever code, don’t you”. The young skulls full of mush nodded in unison and smiled. “You’re right, it is clever….it is also bad coding.” He went on to explain that while it was clever and fast and efficient, it was also bad code because we couldn’t understand it! It would have taken only a few extra lines of code to do a more traditional and slightly slower approach, but it would have been much easier to support. Rare is the routine that really needs to be optimized, he said. “Choose clarity over speed, if speed is not absolutely needed.”
via Programming Sucks! Or At Least, It Ought To – The Daily WTF.
