If You Have to Ask What the Big(O) Is You've Never ... Calculated It

I recently made a passing remark about the value of being able to write the code for a linked list. The night before Don and I had been arguing with our oldest son about whether he should be using a stack or a linked list to implement a Java version of Freecell, hence data structures had been on my mind.

Because he, like many college students (and graduates) today, hasn't had the proper instruction in the basics of these data structures he's somewhat at a loss to understand why a linked list is, in fact, a better solution to his problem.

Compiler theory is no longer taught at most colleges, and operating systems is a class of the past (good thing, too, I still have nightmares). Colleges are no longer turning out computer scientists, they're turning out - for the most part - enterprise application developers. Like Big(O) calculations and the red dragon book, a thorough foundation in computer science has been left to those who plan a career in writing compilers (someone has to do it, after all) and enhancing operating systems.

Part of the reason most college graduates no longer have a firm foundation in such concepts is because in the majority of organizations it's not necessary. These kids are, for the most part, going to be application developers, not compiler specialists, and they certainly aren't going to be writing code in assembly or tweaking TCP/IP stacks.

Developers have "moved up the stack" out of necessity and demand. There are far more organizations that need good application developers than there are that require someone who can implement Djikstra's algorithm in their sleep. Their focus is on writing applications that are usable and meet the needs of the business owners for whom these applications become paramount for success, not twiddling bits.

Translating business speak into functional specifications is not always easy. It can be as frustrating as trying to marry network and application concepts in order to deliver applications when you know a lot about one, but nothing about the other. And trying to talk to "those other people" - you know, the ones in that other IT silo - can be as frustrating as traveling to a new country in which the only language spoken is one you don't understand.

Hence the rise of "analysts" in IT and "application delivery networks" in the age of the Internet. Both solutions work because they essentially sit on the fence, between two worlds, and translate between them. Because of them we end up with applications that fit into the organization's architecture and solve the problems of the business, and a way to deliver them in the most efficient manner possible.

Application delivery is about applications and networks, and how they can collaborate to deliver secure, fast applications. The folks who build application delivery products do understand the nitty-gritty underside of operating systems, network stacks, transport protocols, and application protocol optimization. These guys understand how to tweak delivery of applications and squeeze every last drop of performance out of the network and implement products to do just that. Deploying an application delivery solution is like getting the advantages of an entire team of bare metal, bit tweaking, compiler writing coders in a box but without sacrificing the headcount necessary to fulfill the application development needs of the business.

Application developers today aren't likely able to calculate the Big(O) of that loop they just wrote or read HEX as naturally as they do English, but they are able to translate requirements into technical specifications and build applications that solve the problems of their particular business. That's okay, that's their job.

Let them focus on their job and let application delivery do its job by ensuring those applications are secure, fast, and available.

Imbibing: Coffee