Are we about to experience a big change in the developer role?

Thomas Linck 11th December 2017
code generation developer role

Developers are creative people that want to be mentally stimulated. With developments in Cloud Computing, the job role is changing a lot and we’re expecting code generation to have a big impact on how developers work. How will they feel about this?

Developers have been creating software since the beginning of the computer age, and have had to adapt to the ever-evolving infrastructure. Developers go through a lot of concepts when evolving on the seniority scale like DevOps, database integration, caching, templating, layering, interfacing, concurrency, hashing and all of this while maintaining an algorithmic complexity as optimised as possible. Recent software are efficient, they answer to specific business cases as well as perform well. Infrastructure is no longer only supporting source code, it also gives more and more features to the developer and the further it goes, the less the code is important.


The advent of Cloud Computing


With the advent of Cloud Computing, people stopped asking themselves how they are going to run their code, but where it is going to run. Today’s PaaS/CaaS/SaaS market stabbed yesterday’s IaaS market in the back, and IaaS mainly survives because of legacy (and some regulations/lobby or adherence issue). Moving forward, new applications will leverage on existing platforms and infrastructure.

Today, you can run a fully functional, highly available and scalable API in literally 3 minutes with chalice and AWS API Gateway. So why would you provision a server, maintain it, deploy middleware, maintain it, deploy application, maint…you get it. Are there people still doing it today? Yes , a surprising number actually! I predict this will go on for  MAXIMUM five to ten years, let’s see why…


Reacting to technological advances


When a technology evolves, the software usually evolves with it and even if most of the IT is retrocompatible, you sometimes need to evolve/rewrite an application. When it happens, you usually try to guess how profitable a full rewrite is, by a clever arithmetic only experienced IT experts can understand. The real question is defining when it will happen, not if. Once we are sure an application will be rewritten, it’s worth questioning the development environment. Will the language last? Will the platform last? Will this CI tool last? Lots of questions are asked and speculation comes from tech crunchers like TechRadar – which can help you weigh up the risks and strategise.

When you make decision, you also want to consider the future. Your application and its whole ecosystem need to enroll in the future which is of course very difficult to predict. You may, or may not, have worked with “old” platforms like AS400/DB2. What is the main difference between this and a newer platform like AWS Lambda function? What is the difference between a web server running Apache and a Kubernetes cluster managing an application? Not that much, from a business functional perspective. People have learnt over time to annihilate all platform evolutions! The more RAM you have, the more you will use and the same applies for CPU, Storage, Network, etc. This principle, called “Mechanical Sympathy”, is very well described by Henry Peteroski in the following quote:

“The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry.”

If we consider the development evolution in conjunction with the evolution of platforms, you might wonder why there is so few difference in development today compared to 10/20 years ago? But what drives evolution? Needing something is probably the best reason to make it happen. If nothing happened, it’s maybe because there is no need of it.


The impact of code generation


So why would code generation be a thing that creates a big change in the future of development? Because it allows a developer to ignore the platform and by doing so, avoid any platform-related mistakes. It’s also very important to understand how code generation can help with business functional needs. If an application has a data model with simple CRUD operations, you probably don’t need to create the wheel again. If an application has a very complex Extract, Transform and Load pattern, you probably need to use an existing ETL tool. I am not saying you should never develop something new again. I am just saying if you do want to develop something new, it’s worth extra consideration.

Code generation can help with things such as API definition or infrastructure describing. API can be defined using templates, the OpenAPI Specification (OAS), for example, characterizes a standard programming dialect agnostic interface depiction for REST APIs. It enables people and PCs to find and comprehend the abilities of an API without expecting access to source code or extra documentation. To illustrate the ability of OAS, you can find a sample Uber API on Github.

It’s the same concept for infrastructure development, Cloudreach recently open-sourced Sceptre which is a tool to describe an AWS infrastructure through Python templates and YAML configuration (Cloudformation wrapper). But as we move forward using this tool with tens of customers recently, we tend to write less templates and more config. The more generic the template is, the more we are able to reuse them (familiar concept, right?), but as we move forward, we tend to write YAML and no Python.

Would it make sense to have a fully generic template and write only YAML? Would that still be as interesting for developers as writing Python templates? Probably not.

Small events in the IT world sometimes lead to global changes, so next question is: what would be the knock-on effect of such a change in the developer role?


To be continued…