We’ve all heard of the proverb that a butterfly flapping its wings in China can cause a tsunami in North America. This butterfly effect can also be “felt” in programming. Small details such as language choices and its API implementations, and even the type of hardware your program runs on eventually adds up. As demonstrated in the second chapter of Spolsky’s Joel on Software, nonchalant implementation such as specifying hard-coded array sizes can eventually lead to bugs and unfortunately into exploits. Now my question is, if this is an all too important fundamental question that everyone building a software system should know, then why isn’t this explicitly taught in programming classes?
Now, I know you might be saying, “Well, we go to university so we can learn how to learn.” It’s true that we can’t learn everything in the scope of four years – albeit the fact that after going through the first half of your degree, most of the things you’ve learned so far are already obsolete – but that doesn’t completely answer our question. Let me backtrack a week before. I was attending a Programming XML with Java course at the IBM lab when the professor asked the question of using StringBuffers instead of just concatenating Strings? Someone answered, “because it’s immutable.” It’s definitely correct, but not quite. So I have to add, “because concatenating Strings creates a new object every concatenation and creating objects in Java is an expensive operation.” We might probably guess that the students were just too shy or just wasn’t too eager in participating (it was 2 in the afternoon). Now granted, I’ve only known this when I started at IBM while “slacking off”. But why is that? We’ve been taught that indeed, Strings are immutable when we were in school. But are we suppose to find out that connection ourselves and jump from knowing that Strings are immutable to use StringBuffers instead of simply concatenating Strings?
The problem with this is that if we only start to really learn after graduating, then it might be too late for us to change our ways. Most of the time, specifically in learning a new programming language, we are always taught the semantics of the language but omit the low-level aspects of it. How is garbage-collection in Java different from using malloc in C? Is there even a distinct advantage in using one or the other? How does strcat in C scale when appending huge number of strings? How would you implement in XML the SQL statement, SELECT author FROM books as fast as a RDBS? These are the questions that should be easily answered by any programmer, and yet comes as a surprise for most of newly graduate students (and sometimes even seasoned developers as well). If this is a must-know for all of us, then shouldn’t this be then taught in the core curriculum? I’m guessing it boils down again to the answer that we should be learning this stuff on our own. But what if we don’t? We could say that that person doesn’t really belong in the software field and hopefully eliminated by economic competition. True, but I’m guessing most of the damage has been done before that has happened. You could say that this might be spoon-feeding but in fact we should really be forcing it down our throats while we’re young.
As Joel have concisely put,
I think that some of the biggest mistakes people make – even at the highest architectural levels – come from having a weak or broken understanding of a few simple things at the very lowest levels. You’ve built a marvelous palace, but the foundation is a mess. [...] So the palace looks nice, but occasionally the bathtub slides across the bathroom floor and you have no idea what’s going on.
I’m not saying that it’s the universities’ and colleges’ fault but the bottom line is we should be generally more aware of the implications of not knowing the intricacies of a language and how it contributes to a better quality of code.
Filed under: Computer Science, agile and iterative, algorithms
