Throughout computing history, one change has been consistent: programmers achieve more each year with less code. In the earliest days there were punchcards and assembly code. For almost all programmers, work is much easier today. Still, the industry continues to improve, making a developer's work more efficient, predictable, and enjoyable. Professional programmers continue to write many lines of code, and that will likely always be the case. There is still an undeniable trend at removing the repetitive pieces.
It's more than laziness that makes programmers look to reduce the amount of code they write. As Jeff Atwood puts it, the best code is no code at all. Any code written must be maintained, which is even more costly than writing it in the first place. New code is cheaper than old code, but new code also grows up to be old code. Less now is less later.
That's great, but how can I write less code without giving my application less functionality?
Open Source Means Less Code for Everyone
One of the mechanisms programmers have found to write less code are libraries. Even before the open source movement, libraries have been part of programming languages and best practices. Historically, libraries encourage reuse of common functions, for the individual programmer and the programmer's larger team. Now, libraries are often open source and maintained by many contributors.
Related to libraries are frameworks, which bundle together common functionality and application architectures. Frameworks automate boilerplate and help programmers focus on their original code. While libraries are typically more focused on specific results, frameworks often take a more opinionated stance on how code should be written.
Modern programmers will typically look to libraries, and to a lesser extent frameworks, before writing their own solutions, but not blindly. There are some downsides of open source and libraries, as we've seen this year. A popular Node library with minimal functionality brought down the Internet. And a recent Medium post outlined the bloat that can come from many dependencies. Despite these issues, the benefits definitely outweigh the problems for most circumstances.
Any Data and Functionality is an HTTP Request Away
Over the last 10 years, how programmers architect their applications has changed drastically. The biggest catalyst was the growth of web APIs, which act as a way to extend an application's data or functionality into another. Most popular SaaS apps have APIs, and many more companies that only provide APIs have sprung up, as well. Once programmers started using external APIs, it made sense to architect their applications to use them, too. Plus, creating applications for multiple devices basically require it.
APIs essentially act as super-powered, connected libraries. Like traditional libraries, APIs can be private to a coder, shared across a company, or even made public. Now developers can make calls in one line of code that saves them the thousands of lines that may drive the API they called. In some cases, an API may contain data or functionality that isn't even possible for most developers to build on their own.
Chances are this API trend is one you've followed. You maybe have even been someone who a few years ago looked skeptically at offloading any aspect of your code to another service. Today, APIs, like open source, are a major player in almost every application.
Questions About Control and Trust
Despite the trends, professional programmers won't blindly integrate any libraries or services without first going through an often unconscious series of deliberations. The decision process is similar when considering a new library, API, or even a service that makes it easy to build apps faster.
Control used to be the primary driver for developers to build functionality themselves that they could otherwise achieve through another source. It was not that long ago that most websites of significance were served from their own hardware. As servers moved to the cloud, it's become much more normal to let go of that control. Similarly, programmers have relinquished control in many aspects of their code to libraries and APIs. They're writing more code by giving up control where they don't need it.
Put another way, programmers have become more trusting, within reason. They'll try new services in a side project, then maybe bring it to work in non-production environments. Finally, when they're satisfied, the service could earn a spot in their "real work."
As the need for control decreases and the default to trust increases, programmers will write less code. Will the last line of code ever be written? Probably not, but the trends are moving in that direction.
See how BrightWork can help you write less code and build apps faster. Sign up today for free and get your own API key.