Despite its complexity, the software development process has gotten better over the years. "Mature" programmers remember how many things required manual intervention and hand-tuning back in the day. Today's software development tools automatically perform complex functions that programmers once had to write explicitly. And most developers are glad of it!
Young whippersnappers may not even be aware that we old fogies had to do these things manually. These functions still exist in the software you write, and some specialized programmers, such as Linux kernel developers, continue to apply these techniques by hand. Yet most people depend on the functionality provided by built-in libraries, the operating system or some other part of a development environment.
Let's take a moment to appreciate how much things have improved. For this article, I asked several longtime developers for their top old-school programming headaches and added many of my own to boot. Join in as we wallow in nostalgia and show off our scars -- then tell us about the development techniques you're happy you left behind in the article comments.
Sorting algorithms and other hand-coded fiddly stuff
Applications you write today need to sort data, but all you do is call a sort routine. But as late as the 1980s, programmers were having flame wars about sorting algorithms: Binary trees versus modified bubble sort at 50 paces!
It's not just that developers had to choose an algorithm; we had to write the code anew, every time. Donald Knuth wrote an entire volume about the subject in his "The Art of Computer Programming" series; you weren't a serious programmer unless you at least wanted to buy that book.
Honorable mention:
- Implementing a linked list or hash table yourself
- Hand-coding XML for SOAP deployment
- Choosing direct file access such as sequential, direct access, indexed access
Creating your own graphical user interfaces
Text-mode interfaces once ruled the earth. Until sometime in the 1980s -- and arguably into the '90s -- any developer who wanted to create a windowing system wrote her own windowing abstractions and tested on CGA, EGA and VGA cards, the way you test on Firefox, IE and Safari nowadays (I hope). Or she bought an expensive add-on windowing library and still fiddled with settings for days on end.
No wonder so many "interfaces" consisted of "Enter 1 to Add Records, 2 to Edit Records, 3 to Delete Records."
Today, to create a GUI, you use user interface widgets built into your favorite IDE (integrated development environment) or use a stand-alone tool for GUI design. You drag and drop components, call a few functions, and declare some logic. It's magic.
Go To and spaghetti code ...
... or really, any programming methodology before structured programming and object-oriented development came along -- except only prissy academics used words like "methodology" back then, and most of us didn't have a college degree.
In many early programming languages, the application flow was controlled by instructions like GOTO 10, whereupon the code would jump to Label 10, which might or might not appear between 9 and 11, and continue execution. It was frighteningly easy to jump over and into code, creating a Gordian knot of executable code that became a maintenance migraine, giving rise to the pejorative term "spaghetti code."
Structured programming, which suggested that code could be categorized into decisions, sequences and loops, "was a godsend in the '70s ... much better than the 'code now, design later' approach it replaced," says Jay Elkes, who was a Cobol programmer back then. (I must note, however, that the seminal 1968 article "Go To Statement Considered Harmful," penned by structured programming proponent Edsger Dijkstra, spawned entirely too many "...Considered Harmful" parodies.)
Newer object-oriented languages, starting with C++ in the early '90s, eliminated the need for structured programming -- which hasn't kept some developers from going full circle to reinvent Go To on their own.