15 technologies changing how developers work
A long time ago, developers wrote assembly code that ran fast and light. On good days, they had enough money in their budget to hire someone to toggle all those switches on the front of the machine to input their code. On bad days, they flipped the switches themselves. Life was simple: The software loaded data from memory, did some arithmetic, and sent it back. That was all.
Today, developers must work with teams spread across multiple continents where people speak different languages with different character sets and -- this is the bad part -- use different versions of the compiler. Some of the code is new, and some may be from decade-old libraries that may or may not come with source code. Building team spirit and slogging through the mess is only the beginning of what it means to be a programmer today.
The work involved in telling computers what to do is markedly different than it was even five years ago, and it's quite possible that any Rip Van Winkle-like developer who slept through the past 10 years would be unable to function in the today's computing world. Everything seems to be changing faster than ever.
Here are 15 technologies transforming the very nature of programming. They're changing how we work with fellow developers, how we interact with our customers, and how we code. Don't get caught asleep at the console.
Developer tool No. 1: Continuous integration
When you checked in code to a repository, there used to be enough time to catch your breath, have a cup of coffee, and maybe even go out to lunch. No more -- code repositories are now tightly linked to continuous build systems that recompile your code, scrutinize your architecture, initiate hundreds of tests, and start flagging every potential error in your work. You won't get five feet from your desk before your phone starts pinging you with new emails or text messages from the continuous build mechanism telling you what needs to be fixed. Back to work, slave, the continuous build machine has new tasks for you.
Developer tool No. 2: Frameworks
Standing on the shoulders of giants by reusing the work of others may not be a new idea, but it seems like it's never been as dominant as it is today. Very little programming begins from scratch these days. The favored -- and some might argue, best -- approach is to grab the right framework, research the API, and start writing glue code to link together the parts of the API that make the most sense for the job. Web pages aren't built out of HTML or CSS anymore; the coding begins with Ext JS, ExpressJS, or some other collection of code that serves as a foundation.
Sure, you could be pioneering and build everything from scratch, but that would be suicide. There's no way to catch up with all the work done by others. You're not a craftsman -- you're a framework-tweaker. If you're thinking of writing code yourself, stop and look for a framework that does it already.
Developer tool No. 3: Libraries
A close cousin to the framework is the library, a collection of routines so ubiquitous that coders can no longer live without it. Is it possible to write code for the browser without using jQuery? Does anyone even remember there's a built-in function called GetElementByID? Nah, libraries like jQuery now rule every level of the stack.
Developer tool No. 4: APIs
In the old days, programmers worried about data structures. They would pack all their information into blocks of bytes, count the bytes one by one, then make sure the values were placed the right distance from the pointer. Now, thank goodness, the compiler does most of that for us.
These days we work through a much more rigorous interface with a fancier name: an API. This is often on a completely different machine and may be run by a completely different company that is charging us for every call. Do you want a street address and a ZIP code turned into latitude and longitude? There's an API for that, and it costs a few slivers of a penny to find each answer.
In most cases, the data doesn't need to be so tightly packed. The old game of counting bytes has been replaced by parse-able data structures such as JSON or XML. You need to make sure you have the right punctuation in the right spot, but luckily there's a library to handle that for you.
Developer tool No. 5: Platform as a service
Who builds their own website anymore? Instead, create an account on someone else's website and customize it. All it takes is a few fields in a Web form, and voilà, your new website does everything you wanted. It's like uploading a cat video to YouTube or bidding on a Pez dispenser on eBay.
Developer tool No. 6: Browsers
Developer tool No. 7: Application containers
Building a server used to be hard work. The programmers would get their code running, then send a memo to the team of server curators who'd install the right software. Sometimes they got the right libraries and sometimes they didn't, but eventually we converged on something that worked.
Now application containers like Docker allow us to push a button and ship off a container with all the right libraries. If it runs on our test machine, it will almost certainly run on the server. Everything is bundled together, and most of the incompatibilities between our desktops and the server are gone.
Developer tool No. 8: Infrastructure as a service
Did I mention the teams of server curators? Those guys were fun to hang out with at lunch or after work, but now they've been abstracted away into the cloud layer, working as they do in a data center across the globe for another company that fancies itself a leader in the world of cloud this or cloud that. Few programmers need to ask the infrastructure team to build them a new server for a new project. They simply log into a website, push a button, and get a machine running for them. It's so much easier, but these IaaS administration Web pages won't buy you a drink after work. Of course, that saves you from ever having to get the next round.
Developer tool No. 10: Secondary marketplaces
If you're building a game, you could hire your own artists to create a stunning set of models. You might even hire a few programmers to add visual effects to make the game look cool. Or you could go shopping at secondary marketplaces like the Unity Asset Store and buy up all the pieces you need. As I write this, there's a 33 percent markdown on the Tile A Dungeon Sewer Kit, "designed as a modular kit to build from small to large sewer game scenes." The sale will probably be over by you time you read this and the price will be back up to $45. Who needs developers or artists with prices so low?
There are more and more effective marketplaces for plug-ins, extensions, libraries, and other add-ons. As with libraries and frameworks, here one doesn't program so much as go shopping for the right pieces.
Developer tool No. 11: Virtual machines
The popularity of the VM is growing to absorb everything in the stack. In the past, if you wanted to create a new language, you would need to build the entire stack from pre-processor to register allocator. These days, new languages sit on top of the old virtual machines. Clojure, Scala, Jython, JRuby -- they're all piggybacking off Sun's (now part of Oracle) great work in building the VM.
Developer tool No. 12: Social media portals
In the early days of the Internet, you would build your own website, cross your fingers, and hope people would find it. When they did, they simply had to remember your cool URL.
Alas, more and more of the Web is being absorbed into big silos like Facebook and Salesforce. If you build your own website, you might turn it on and hear the sound of crickets because all of humanity is clicking away in Facebook or Salesforce.
The solution, of course, is to build a Facebook or Salesforce app. They'll let you in and let you integrate with their platform to a point. But in the end, your app is an extra that could be limited or tossed aside with a wave of a hand. What choice do you have? You're either a lackey to the big portals or you're listening to crickets.
Developer tool No. 13: Devops tools
Once upon a time, we installed software on a server -- singular. Now we rent servers en masse, requiring dozens, hundreds, or even thousands of machines, many of which need to be provisioned on demand, full of fresh software -- a job that can no longer be done effectively by hand.
Enter the "devops" trend and underlying tools such as Chef and Puppet designed to maintain these servers for you. Push new software to the cloud and these tools handle the job of keeping all the computers running the same code. They automate what we used to do by hand for one machine.
Some services such as Google App Engine already handle this internally. All you need to do is give it your app, and the provisioning is automatic. You don't even know what's going on in the background; you merely get a bill for the amount of CPU cycles consumed.
Developer tool No. 14: GitHub, SourceForge, and social code sharing
Code-sharing sites may be the greatest contribution to the open source world. Before services like SourceForge came along, software was something you built on your own and shared on your own. If someone wanted a copy of the code, they came to you and you sent them a tar-ball if you felt like it.
Now code sharing is a social network. Sites like SourceForge and GitHub post all the code for everyone to see and update. They merge the process of maintaining, sharing, and commenting on the code in one easy-to-access place. You can read the code and suggest changes, all through one interface. Is it any wonder that many projects see tens or even hundreds of thousands of downloads each week? That would never be possible with the old model.
This model is now so dominant that most proprietary projects follow it. Sites like GitHub and BitBucket support themselves by selling nonpublic repositories that offer all the power of sharing, but within a limited permission group.
Developer tool No. 15: Performance monitoring
In the beginning, tracking the power of your code was simple. You printed out the time when the code began, then printed out the time when it ended. If you wanted to be fancy, you added a few extra calculations to do the subtraction for you.
That can't cut it any longer. Many of the problems don't occur on one machine. Adding a profiler to your code won't reveal the real bottleneck, which could be caused by some weird interconnection or a sluggish database. Modern tools track the network calls for the network of software as well as the performance of individual modules. This is the only way to understand what is going right and going wrong.
This is just one important way of how the model of programming is morphing from a single machine to a network of connected tools that may or may not play well together.