Sponsored Content

Why productivity gains will define success for developers this decade

The software development industry has a problem. A revolving door of new frameworks greets every developer taking their first tentative footsteps into the shiny palaces that create software. Every new platform is The Next Shiny Object. Today we have more “intelligent” tools than you can shake a stick at. Code editors are so smart they can write large swathes of your programs for you.

Every new advance in software engineering tech brings with it a library that bolts on predefined functionality. Want speech recognition? There’s a library for that—it does 11 languages although you only want English. Need to wrangle JSON responses from a REST server into a tracklist of yodeling hits from 1950s Appalachia? Sure, pull in a tsunami of easy-to-consume code that displays everything in a carousel of images with a ready-built media player.

Suddenly, however, you have an app that has expanded to just shy of one gigabyte. It runs cross-platform on every operating system known to mankind. It also kills the performance of every single machine it touches—but it looks cool. You have a bloated, quivering monster with library upon library you don’t understand. Its dependencies make it more fragile than a teenager’s first love.

While we were trying to make everything easier, we accidentally made the whole thing harder. More code, especially code we don’t fully own, sinks our productivity. We gave in to the siren’s call of adding in expanded functionality just because we can. We never even wondered if we should. 

It’s a simple sum—less code means easier code. Developer productivity should not be submerged below multiple and competing frameworks that pull in “everything but the kitchen sink” libraries. Crafted code is low code. Easy-to-maintain code is low code. That is, unless you think it’s easier to read 20,000 lines of “optimized” programming than to scan 150. Shorter learning curves mean a faster route to increased and sustainable productivity. 

Thankfully, we are finally realizing that productivity is the target, and picking your tools carefully is the key. Writing more code is not the answer. Work smarter, not harder.

Is the bloat sustainable?

We’ve come a long way in the last 10 years with tools like the artificial intelligence of GitHub’s CoPilot. It embraces the trend for intelligent assistants and can actually write some code for you. It’s still in the early days but things are promising. IDEs, the specialized editing apps used by developers to actually write their code, commonly have built-in pseudo-intelligent functionality. This functionality reminds programmers of the exact set of parameters and usage for a function in a piece of code. The better IDEs spot mistakes and flag them, just like a word processor berating us for spelling or grammar errors.

But this helpful behavior is actually a flag that reveals a guilty secret—writing code is getting harder. It is more complex, and for a number of reasons. At the most basic level, computers are more sophisticated. As users we expect them to do more. It’s perfectly normal for us to demand a shopping app that shows a list of items sorted by price and availability, with a map to the nearest store. The app even tells you things like the aisle in the store where you can find your purchase. It suggests associated items like batteries to accompany it. Of course, it is also tracking and reporting your choices to a marketing team and reporting crashes to a QA dashboard. It is also leaving beacons (for a price) so an advertising behemoth can show you items deemed “relevant” to your demographic.

Think about that for a moment. In the short space of a decade, we have gone from simple spreadsheets and flat web pages to the kind of far-fetched sophistication that even the most reckless science fiction writers from the time of COBOL and William Shatner couldn’t have imagined.

Moore’s Law reversed

Is it any wonder that gloriously powerful hardware that continues to leap forward in CPU power, cores, and parallelism seems slower than our old computers? The great Moore’s Law has held true. Raw computer power has indeed doubled at least every eighteen months. But Moore’s Law has an unspoken corollary—software bloat will double and speed will halve every single year. That is not a truism. You know by now the feeling of yesterday’s great computer creaking and dragging its feet after launching the latest, must-have new app.

Web pages that shuffle down our super-fast broadband internet flex their wobbly midriffs at 6 megabytes or more. Their seams burst with unapologetically sprawling JavaScript libraries and “assets.” The trend toward WebAssembly is intended almost entirely to claw back CPU cycles squandered by insouciant developers. They never got the memo from the early years of computing that, with programs, bigger is not better.

Then, horror of horrors, that chubby web darling—the Electron app—slides onto our computers. Sure, you have a web designer writing apps that “work cross-platform.” But it is a form of “working” cross-platform that takes 20 seconds to launch over a network. After that, it munches down close to a gigabyte of your computer’s precious memory. This should be the poke in the eye where we ask ourselves, “Is this right?” 

A simple Electron database app pulls in tens of thousands of files. Is this productivity? Is this a wise direction to follow? The same app produced using a tool that creates native binary apps takes only 2.5 seconds. It has a massively simple and focused codebase. Assuming it’s built with a modern optimizing compiler, it only includes exactly the code needed to make the app work, and nothing more.

The new era of productivity

The bloated code monster that “does everything” doesn’t have to be the way we are headed. Engineering code using the right tool makes us succinct and pulls in tight precompiled component functionality. The right tool has a low-code wizard for a head-start at producing apps without wrestling with huge dependencies. 

Embarcadero’s RAD Studio is a development tool capable of enabling productivity without compromising quality. It ticks all the boxes of sane modern software engineering. It offers intelligent code editing, which flattens out that learning (and memory) curve. There is a low-code wizard that creates nicely laid-out, easy-to-understand, cross-platform apps that work on just about anything. You can meet your users wherever they choose to consume your great ideas. It doesn’t matter if that is on Windows, Linux, macOS, iOS, or Android.

What does productivity mean in software development?

Software development productivity is the sum of developer productivity, business functionality, application flexibility, and product performance. Compare that with the costs of software development. The sum of the cost of developers—their wages, hardware, and all those expensive inducements like outlandish chairs. Once you have calculated that, throw in the cost of the tools you bought to build the software.

You get what you pay for

A toolchain that is “free” but time consuming is not free at all, is it? There’s a pain point here. That pain point is future maintenance and longevity. There is a myth that accompanies open-source toolchains: if the original maintainers fall under a metaphorical bus, you can easily maintain the library yourself because you have access to the source code. This has been repeatedly shown to be entirely specious. You chose the library to make it easier to achieve a particular functionality with a few lines of code. Now you have thousands of lines of code you didn’t write and you need to fix something now, today.

Say your library has an agenda set by a huge public company that decides to head in its own direction. You can retool if your goals align with the maintainer. You still, however, have to solve that problem even though you have already finished and shipped your app. That assumes, overall, the change in the toolchain isn’t malicious. It assumes you didn’t accidentally pull in great globs of code with layers of dependencies that all break because someone decided to withdraw a tiny but critical piece of functionality. It would never happen, you say?  But it has happened. It will happen again.  

The more code you have in your app, the more chance there is that your app is brittle and less likely to scale reliably. Choosing a toolchain tuned for in-use performance is just smart. 

Picking an integrated software development toolchain like Embarcadero’s RAD Studio can supercharge your developer’s productivity. It reduces code complexity and provides application and end-target flexibility. It generates “bare metal” native applications that operate at maximum product performance. You don’t need a forest of interdependent, unoptimized libraries and a general-purpose “works anywhere” framework.

Does writing less code create better software?

Successful developers know that less code is more productive. It’s not rocket science. It’s fewer taps on the keyboard and fewer lines to search through to track down a bug. Even when you allow for those pen-chewing moments of deep focus, it still takes less time. Cliché or not, time really is money.

Successful developers know that less code is easier to understand both intellectually and conceptually. They know that less code reduces costs by being easier to test and maintain. In fact, I tell other developers that I’m lazy, but I’m known for being extremely productive. My secret is to pick my development tools very carefully and not chase unicorns. 

Evolve to embrace simplicity and eschew complexity with easy-to-read, -write, and -learn languages; low-code technologies; and robust toolchains to ramp up productivity. There are toolchains out there like Embarcadero’s RAD Studio (a combination of Delphi and C++ Builder) that are a productivity sweet spot. It’s my superpower. The combined efficiency gains of low-code technologies and multiplatform deployment supercharges developer productivity. Sometimes doing less achieves more.

Are you ready to embrace a new era of productivity?

Software development is becoming harder—the multitude of tools with assistive technologies to help us write code makes that clear. But writing more code, especially more complex code, massively impacts our productivity. Trying to engineer an escape from complexity by embracing technologies like Electron has left us dissatisfied and with bloated applications. 

Bigger is not better. Cross-platform should not mean a poor compromise. Native code that embraces sensible modern helper tools like low-code wizards and intelligent IDEs with “code completion” templates help us race to the front of the pack without having to work ourselves to death. Work smarter, not harder. Be productive by being picky about your choice of development tools. Reject the tsunami of all-encompassing, do-everything, memory-gobbling libraries in favor of native apps that do what they should without consuming every last bit of your user’s processing power.