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.

Featured Resource

 

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.

People talk about their favorite languages, but that conversation says little about how they program. If you're looking to hire someone, you need to ask about library knowledge. Is the JavaScript programmer from the jQuery or Dojo tribe? The game programmer may use C++, but the real question is whether the coder knows Allegro, Unity, Corona, or any of a number of other options. Knowledge of the library is as important as knowing the ins and outs of the language itself.

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.

Of course, this is a bit of an overstatement. Many of the PaaS options today require a programmer's sophistication to know what to put in each Web form. Microsoft's Azure, for instance, wants you to put in a few JavaScript functions that characterize how the website should respond. Then Azure wraps them up with the right libraries and starts them running on Node.js.

Developer tool No. 6: Browsers

There was once a time when people wrote software for desktops, software for servers, and software for devices, and it would all be different. Each had its own way of communicating with the user. Now everything goes through the browser. When I set up a local file server on my house to hold music, I go to a URL and work with a website. Widgets for Apple's desktop have been written in JavaScript and HTML for years. Many cross-platform mobile apps begin as HTML and JavaScript that's bundled with Apache Cordova.

Sure, there are holdouts. The best games are still custom work that doesn't need a browser, but that's changing, as more and more JavaScript developers figure out how to write the screen canvas object. Angry Birds, for instance, will run in a browser window.

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. 9: Node.js and JavaScript

Before some of you were born, Web servers spit out static HTML. Then someone figured out how to create dynamic servers that could interact with databases. Every team needed one person to program the database in SQL, one person to write the server code in PHP or Java, and one person to design the HTML templates. Once everyone fell in love with AJAX and JavaScript running on the client, the sites needed yet another person to speak that language.

Now it's all done in JavaScript. The browser, of course, still speaks JavaScript, but so do the server layer (Node.js) and the database layer (MongoDB and CouchDB). Even the HTML is often specified with JavaScript code for a framework like Ext JS or jQueryMobile that generates the HTML at the client.

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 days of writing code for real chunks of silicon are largely gone. Much of the code written today runs on virtual machines that translate your instructions into something understood by the chip. The Java Virtual Machine, the C#/.Net Virtual Machine, and now JavaScript engines end up being the main target for code.

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.

This same behavior is appearing in the browser world. Sure, you could create your own browser and language, or you could cross-compile it to be emulated in JavaScript. That's what the folks did when they built cleaned-up tools like CoffeeScript. If this isn't confusing enough, Google produced GWT (Google Web Toolkit) to convert Java to JavaScript.

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.