Old-school programming techniques you probably don't miss
11 skills and tactics that every programmer once needed to master ... and today can blissfully forget
Computerworld - 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.
- 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.
- DevOps meets ALM in the Cloud - Cloud DevOps PaaS To improve software delivery performance and effectiveness, teams need automation, governance, architecture best practices, and increased team collaboration. Find out more.
- Coding with JRebel: Java Forever Changed With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with...
- What Developers Want: The End of Application Redeploys Eliminate application restarts in Java with JRebel! JRebel is a JVM plugin that eliminates application redeploys from the Java development cycle, a process...
- How a German energy company saved 1 day per week of development time with JRebel Check out the following case study to see how Heliocentris, a global energy supply and efficiency company deployed a development solution that was...
- IBM FlashSystem V840: Leveraging Software-Defined Flash to Drive Your Business With end-to-end, tightly integrated functionality and super-fast flash technology, products like IBM FlashSystem V840 Enterprise Performance Solution empower businesses to leverage the efficiency...
- Leveraging Flash Storage to Accelerate Oracle Real Application Clusters Join this webinar to understand the latest solid-state storage trends, the specific applications driving solid-state storage deployments and the benefits of deploying the... All App Development White Papers | Webcasts