21 technologies transforming software development

The very nature of programming is evolving faster than you might think, thanks to these powerful tools

21 technologies transforming software development

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 20 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.

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.

Smarter languages

The earliest computer languages were designed to make it easy to do anything with a computer. The latest want to make it hard or even impossible to do anything other than just the right thing. Over the years, the programming community has learned how people make mistakes and programs go bad. They’ve created a long list of bad practices and now some of the language designers are putting up guardrails and handing out straightjackets to keep us from following the last generation down the path to sins like null pointer dereferences or race conditions.

Rust, for instance, has one class of variables that don’t change. Yes, a variable that isn’t variable seems odd, but it’s one way to stop race conditions and make the code faster. There are hundreds of innovations like these and they’re allowing programmers to build grander piles of code for changing the world.

These constraints aren’t perfect, of course, and they can be annoying to talented programmers who instinctively avoid the bad techniques. But the newer languages are finding teams that enjoy the discipline and added structure.

Better databases

The first databases were miracles that saved the world’s programmers years of effort by offering a standard way of sticking information in big tables. Today’s databases shoulder those loads and many others like maintaining social networks, tracking locations, storing images, or more. They’ll do all of this while spreading the load over clusters of machines that may even live on different continents.  

As interest explodes, the programmers have created dozens of databases that satisfy different niches. Do you want super-fast answers but you don’t care if tiny inconsistencies creep into the data? Then you want an in-memory database that doesn’t use transactions. Or is the data so valuable that it can’t be lost? Another class of database will automatically replicate the information across data centers in different time zones or even hemispheres. There are dozens of different options and sometimes you can find that one product satisfies different needs by flipping a few bits in some configuration file.


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.


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. 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.

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 Couchbase). Even the HTML is often specified with JavaScript code for a framework like Angular or React that generates the HTML at the client. 


Programmers are human too. If one wants to use language A, you can bet that the other one will want to use only B, or maybe C or D but never A. Deciding which one to use will take more time than doing the work. The beauty of many modern programming languages is that they can often be automatically rewritten in another programming language. The “transpilers” or “cross-compilers” suck out the basic structure of a program written in one language and turn it into something that runs on another. They’re not always perfect. They don’t always pick up every clever trick or every idiom, but sometimes they’re actually better than the original because they recognize an opportunity for optimization.

One of the biggest targets is JavaScript, the lingua franca for all browsers. Almost every language, from C++ to Python, can be fed into a converter that turns it into something that runs alongside the images and text in any webpage. With CoffeeScript and TypeScript, even JavaScript programmers have a way to turn improved JavaScript into regular JavaScript.

Code reviews and style rules

In the old days, a large program produced by a team of N programmers usually had at least N visibly distinct styles in the code and often a few more thanks to schizophrenic programmers. Those differences are fading as teams develop mechanisms for enforcing uniform styles so that the code is easier to understand because the idioms and design patterns are consistent.

Not every programmer is happy with the push for conformity. The most talented or expressive often feel like they’re forced to throttle their artistic powers. Sometimes the code reviews become vehicles for passive and occasionally openly aggressive confrontations that leave emotional scars and fractured teams. At their worst, they produce the committee-grade work one expects when too many cooks are stirring the pot.

Despite all of these problems, the managers continue to embrace the ideas because, well, it’s the only way to stop the bad programmers and weed out the faulty code. If it ends up thwarting the creativity of a few geniuses, well, that’s something we’ll just have to live with.

Preprocessors and linting   

We old timers used to feel lucky if a compiler could spot an unused variable. Today, there’s an explosion of tools for preprocessing code to look for errors in logic or style. Did you fail to declare a variable? Or worse, did you use the wrong combination of spaces and tabs? The folks at Airbnb have become Internet famous by promulgating a style guide for JavaScript code. The set of rules even specify that a good programmer will put a space on both sides of a plus sign; anything else is bad. Is this harsh conformity good? The people who are writing the rules may be chuckling with glee like power-mad scientists. But at least they’re also giving us tools that will catch our dumb mistakes before we show them to the world.

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.


Not so many years ago, 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.

New user interfaces

The words “user interface” used to mean a decision between a command line and a GUI filled with pictures and icons for clicking. Now the televisions are “smart” enough to pull up websites, and all of the phones have a personal assistant like Siri or Cortana. Soon every kitchen and living room will have its own microphones waiting for someone to say “Alexa.” Can telepathy be far behind?

All of this is a challenge to programmers who must learn new libraries and tools that use different structures and metaphors. The area is new and that means that there are few established practices for programmers to borrow or build upon. They must create everything from scratch. The new paths can simplify things for the programmers. If the user wants to know the temperature, there’s no reason to create a full app or a pretty user interface. The voice can just speak the digits out loud and be done with it. The simplicity can be surprising to anyone who has spent an afternoon downloading the many gigabytes of Apple’s Xcode just to write a small app.


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 make magic in a browser window.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform