Everything I Need to Know About Software I Learned In Data Structures
Over the years, I've observed a number of shifts in the technology landscape. DOS gave way to Windows, client/server moved aside for N-tier distributed applications, and other sea changes have made the software industry dynamic and exciting, but each shift has come at a cost. One of those costs has been the professionals skilled in that specific technology, and unable to make the shift to the Next Big Thing.
While that proposition sounds dubious, I call your attention to the thousands of certified Novell Netware engineers of the late 1980s who were skilled at getting IPX/SPX networks to operate, but were lost when TCP/IP became the dominant set of networking protocols. When I was in academia, I had my own lost cause – a student highly skilled in Borland Turbo C++ and DOS applications. While he was no doubt the master of this domain, he was completely unprepared to attack any other language, platform, or even IDE. He was out of computing entirely within five years, not even certain of why he had no staying power.
Others seem to pick up new languages and architectures quickly and easily. I'd like to think that I am one of them. While I dabble in direct software development, most of my professional activities today involve everything but actually putting code into a file and compiling it. And my formal education in software development is approaching the two decade mark, and today's most popular languages didn't exist when that education concluded. Even during my time as a college professor, in the early to mid-1990s, I looked long and hard at C++, the mainstream language of the day, and gave it a pass, convinced that it was simply too difficult for what you got out of it.
So what enables me to pick up first Visual Basic, then Java, then C# as the need arose? I would argue that my foundation in computer software was laid in my first data structures course, now twenty years in the past. It was in Pascal, a language of simplicity and elegance that is almost nonexistent today. But in this course I learned how to build structures that are pretty much the same today as they were with the dawn of structured languages, perhaps even as far back as Algol.
You might argue that objects are different than the field-based data structures found in Pascal or C. And I also had a background in objects, as a computer science graduate student, working with Smalltalk and Lisp. But there is a fundamental similarity between the two. For example, inheritance and polymorphism are implicit in objects, but can be implemented in fields.
If I am correct, there are some implications that are broadly useful to enterprise IT and to individual software developers. Over the last two or three years, there has been a significant effort in many large enterprise IT groups to retrain veteran Cobol developers in Java. I seem to remember seeing a Gartner study from a couple of years ago that (correct me if I'm wrong) claimed that such retraining took an average of a year, and roughly sixty percent of experienced Cobol developers failed at making the transition.
I wonder if the length of time, and the high failure rate, is because Cobol is neither structured nor object-oriented, and the retraining fails to effectively teach these concepts so that they become inherent in the developer's mindset. If that's the case, one approach might be to spend little time initially on Java syntax, and leverage that limited syntax knowledge into a more comprehensive study of data structures.
As for individuals, even if you're not a language expert, you can be an effective developer if you comprehend how to manipulate data. In an era of smart editors and debuggers, knowing the details of the language may be less important than understanding what to do with it.
Posted by Peter Varhol on 02/21/2005