There are several ways that coding for apps has changed dramatically from what it was 20 years ago. The 90s saw the first legitimate explosion of personal computing. Today, 30 years down the line, things are barely the same.

Application development has now almost completely shifted towards the mobile space. That’s natural since coding for smartphones is much more lucrative than for laptops and desktops. Also, the desktop space has been reserved for mainly web development. Applications are now more interactive and device specific than they were before. All these changes have come about due to the changes in the way we interact with our devices.

There is also a more focused development on making your devices and software compatible. Cloud computing, synching, etc. are all much more pressing issues today. The internet is also a huge factor in every app’s development. You’d be hard pressed to find an app today that doesn’t require some sort of connectivity to update or function.

Developing applications in the past meant that you had to start from a single platform. Imagine having to choose either Android or iOS today. Seems impractical right? Today, building apps simultaneously for all platforms is commonplace. Before, it required devoting resources to porting code between operating systems.

Today, cross platforming development tools make life much easier for coders. Microsoft’s Xamarin development environment, or Google’s Flutter make it easy to write apps for desktop and mobile platforms.

Continuous Delivery and Deployment
Updates to programs were once much rarer than they are now. New features and functions were all packed into one release which meant that updates would be lengthy and time consuming. This development process left a lot to be desired since the bugs and errors in a program couldn’t be fixed. It would require patches delivered after the fact to do this. This is where coding for apps has changed drastically.

Today, updates and patches for minor fixes are a dime a dozen. Major updates come out several times a year; even for major OS’. This is why continuous delivery and deployment have greatly improved software experiences for users.

The State of DevOps Heading Into 2019

By late 2018, DevOps had completed its journey from industry buzzword to a widely adopted software delivery methodology. Reports from the period cited dramatic performance differences between high-performing DevOps teams and lower-maturity organizations, with elite teams achieving significantly more frequent deployments and substantially faster lead times from code commit to production. Despite these demonstrated benefits, many enterprise teams still reported difficulty knowing where to begin or how to sustain their DevOps transformation, according to research from Puppet’s State of DevOps report series.

Against that backdrop, Eusterman outlined three shifts he expected to define DevOps in 2019.

Prediction 1: The “No-Ops” Concept Would Lose Its Appeal

For a period, the industry entertained the idea that development teams could absorb all operational responsibilities — effectively eliminating the need for a dedicated Ops function. Serverless computing and fully managed cloud platforms fueled this narrative, suggesting that infrastructure concerns could be abstracted away entirely.

Eusterman pushed back on this view heading into 2019:

“In 2019, Ops will reassert its role in the DevOps team with a reinvigorated focus on key values by baking governance, production orchestration, stability and scalability into the cake before it gets put into the oven. We suspect Dev will be delighted to have Ops back.”

Tim Eusterman, Senior Director of Solutions Marketing, BMC Software

This prediction has proven largely accurate. Governance, security, compliance, and reliability engineering have all become more prominent concerns as organizations scale their DevOps practices. Roles such as Site Reliability Engineer (SRE) and Platform Engineer have emerged to formalize the operational expertise that “no-Ops” advocates once hoped to eliminate. The consensus today is that Ops expertise is essential — it simply needs to be deeply integrated with the development workflow rather than siloed from it.

Prediction 2: Coding Automation Would Become the Norm

One of the persistent friction points in DevOps pipelines at the time was the Dev-to-Ops handoff into production. Even teams with solid CI/CD pipelines often relied on manual steps — approvals, configuration changes, environment setup — that created bottlenecks and introduced risk.

“2019 will be the year when adding jobs-as-code to the front end of the software delivery lifecycle will go mainstream. Taking this simple, powerful approach of coding automation instrumentation, along with the business logic and infrastructure-as-code, then running it all through the CI/CD toolchain, will help DevOps teams blow by the manual speed-bump into production.”

Tim Eusterman, Senior Director of Solutions Marketing, BMC Software

The concept Eusterman described — treating pipeline configuration, automation scripts, and orchestration logic as first-class code artifacts alongside application and infrastructure code — has since become standard practice. Tools such as GitHub Actions, GitLab CI, and Tekton have made pipeline-as-code the default starting point for most new projects. Infrastructure-as-Code tools including Terraform and Pulumi have matured significantly, and the “everything-as-code” philosophy now underpins most modern platform engineering efforts.

Prediction 3: The DevOps Vendor Landscape Would Consolidate

In 2018, the DevOps toolchain landscape was fragmented. Dozens of vendors competed in every segment of the software delivery lifecycle — source control, CI/CD, artifact management, monitoring, incident management, and more. Eusterman predicted that this would rationalize quickly:

“The reason is simple: DevOps teams like choice, and as the tools mature they will know which ones they like. Winners also get the benefit of the ecosystem rallying behind their cause. And finally, enterprise architects get some well-deserved street cred when they say ‘governance matters.'”

Tim Eusterman, Senior Director of Solutions Marketing, BMC Software

The consolidation prediction has played out, though perhaps more slowly and unevenly than anticipated. Acquisitions — such as Microsoft’s purchase of GitHub and Broadcom’s acquisition of VMware — have reshaped the landscape. Integrated platforms like GitLab and GitHub have absorbed functionality that previously required separate tools. At the same time, the cloud-native ecosystem continues to generate new tooling, so consolidation and fragmentation have effectively been happening in parallel across different segments of the market.

What These Predictions Tell Us About DevOps Maturity

Looking back, these three predictions highlight a recurring theme in DevOps evolution: the movement toward greater formalization. The informal, experiment-driven DevOps culture of the early 2010s has progressively given way to structured practices around governance, automation standards, and platform consolidation. This is not a retreat from DevOps values — it is evidence that those values have become embedded deeply enough in engineering culture to justify investment in the tooling and organizational structures that sustain them at scale.

For teams still working through their own DevOps transformation, the core lessons from these predictions remain relevant: invest in Ops expertise rather than eliminating it, automate every repeatable step in your delivery pipeline, and be deliberate about the tools you standardize on.

Experienced developers are not immune to rookie mistakes. After two-plus decades in the industry, the same tactical errors appear on project after project — sometimes made by junior engineers, sometimes by veterans who should know better. These are not hygiene issues like skipping version control. These are subtle, high-impact mistakes baked into the code itself. Here are 15 of them, why they hurt, and what to do instead.

1. Using Make or Shell Scripts as a Build Tool

If you are not writing C or C++, Make is probably working against you. Make spawns a separate compiler process for each file, which is not how most modern languages are designed to operate. Resolving transitive dependencies in a language like Java using Make is painful at best and brittle at worst.

Shell scripts suffer a related problem: they are fragile across environments and break silently when upstream dependencies change versions. What feels like a quick win — skipping a full build toolchain — almost always becomes a maintenance liability. Use a purpose-built build tool for your language ecosystem: Gradle or Maven for Java/Kotlin, npm scripts or Turborepo for JavaScript, Cargo for Rust, and so on. These tools understand dependency graphs, support incremental builds, and integrate with CI pipelines.

2. Using the IDE as a Build Tool

Every major IDE — IntelliJ, Eclipse, Visual Studio — has a one-click build-and-run feature. It is fine for rapid local prototyping. It is a problem the moment a second developer joins the project or you need to run the build in a CI/CD pipeline.

IDE builds hide configuration in project files that are often gitignored, editor-version-specific, or simply undocumented. The result: “it builds on my machine” becomes the team motto. A repeatable, IDE-independent build script — invokable from the command line and runnable inside a CI runner — is non-negotiable for any production codebase.

3. Confusing “Terminate” with “Stop” in AWS

In AWS EC2 terminology, Terminate means permanent deletion of the instance and its associated ephemeral storage — not a graceful process stop. Most operating systems and tools use “terminate” to mean “end a running process,” so developers new to AWS frequently make this assumption and pay for it.

AWS has added safeguards such as termination protection and the DisableApiTermination attribute, but the safest approach is team-wide awareness and access controls. Use IAM policies to restrict termination permissions to only those who need them, and always enable termination protection on instances that hold stateful data.

4. Running Experiments on Production Resources

Closely related to mistake 3: never test an assumption on infrastructure you care about. Even when an operation looks read-only — querying attributes, listing resources, running a diagnostic — validate it on a throwaway environment first. Cloud environments make it cheap to spin up isolated test instances. Use them.

This applies beyond AWS: database migrations, configuration management scripts, and infrastructure-as-code changes should all be validated in a staging environment that mirrors production before they ever touch production.

5. Chasing Absolute Data Integrity at the Cost of Performance

Strong consistency is valuable. Over-indexing on it is expensive. Resorting to SERIALIZABLE isolation levels or explicit table locks to guarantee absolute data integrity is usually a sign of one of three things: a schema that is not modelling the domain correctly, an incomplete understanding of concurrency requirements, or risk aversion that has not been calibrated against actual business needs.

Most applications tolerate eventual consistency or snapshot isolation for the vast majority of their read paths. Understand the actual consistency requirements for each operation and choose the appropriate isolation level deliberately, rather than defaulting to the most restrictive setting.

6. Mixing Code and Markup

Embedding business logic directly in HTML templates — or generating HTML by concatenating strings inside application code — was common practice in the mid-1990s. It remains surprisingly common today, especially in JavaScript-heavy codebases where components grow organically.

The problems are well-documented: poor testability, difficult maintenance, XSS vulnerabilities from naive string concatenation, and an inability to change the presentation layer without touching business logic. Use a proper templating engine, component model, or at minimum a clear separation between data preparation and rendering.

7. Using a List When a Better Data Structure Exists

Lists are the universal fallback. They are fine for prototyping when the shape of the data is still unknown. They become a performance problem when used reflexively in production code instead of the appropriate data structure.

Common misuses include using a list where membership checks are frequent (use a set or hash map instead), performing manual sorting that could be handled by a sorted tree structure, or repeatedly inserting near the middle of an array-backed list (O(n) per insert). Spend five minutes choosing the right collection type before writing the first line of logic — it pays off disproportionately under load.

8. Over-Engineering Class Hierarchies

Deep inheritance trees are one of the most persistent legacies of early OOP education. Building elaborate class hierarchies before the domain is well-understood produces rigid, brittle structures that are hard to refactor and harder to explain to the next developer.

Favour composition over inheritance. Prefer shallow, interface-driven designs. Inheritance is appropriate when you have a genuine is-a relationship and a stable base. It is not the right first instinct for every modelling problem.

9. Taking Functional Purity Too Far

Functional programming offers real benefits: referential transparency, easier testing, and better reasoning about state. But applying functional principles dogmatically — wrapping every operation in nested function compositions, avoiding all mutable state even where it is appropriate, or restructuring code so that adding a feature requires unwinding a chain of a dozen composed functions — creates its own form of complexity.

The goal is maintainable, correct software. Use functional techniques where they simplify the code. Know when a straightforward imperative or object-oriented approach is clearer for the next person reading it.

10. Defaulting to Global Scope

Global state is the path of least resistance and the source of some of the hardest bugs to diagnose: race conditions, unexpected side effects, and state that accumulates across requests or threads. Global variables cannot be parallelised safely without explicit synchronisation, and they make unit testing nearly impossible because tests cannot be isolated from one another.

Apply the principle of least privilege to scope. Pass dependencies explicitly. Use dependency injection or module-scoped singletons with clear lifecycle management instead of bare globals.

11. The “God Object” Anti-Pattern

A class with hundreds of fields and methods that touches every part of the application is a God Object. It violates the single-responsibility principle, makes testing extremely difficult, and tends to get stored in session or application state because it is the only structure available — consuming excessive memory and causing expensive replication in clustered environments.

When you find yourself adding another field to an already large class because it is convenient, take it as a signal to decompose. Build smaller, focused objects with well-defined responsibilities.

12. Death by a Thousand Micro-Objects

The opposite extreme is equally problematic. When every concept in the domain has its own class and none of those classes are longer than a few lines, the cognitive overhead of navigating the codebase becomes prohibitive. Often this pattern co-occurs with over-engineered inheritance hierarchies.

There is no universal correct class size, but if every file is under 30 lines and you have thousands of them, or if following a single operation requires jumping through dozens of delegation layers, the design has been fragmented beyond its useful limit.

13. Writing Custom Threading Logic Unnecessarily

Most business application logic does not require you to manage threads directly. Thread management is genuinely hard: deadlocks, race conditions, and memory visibility issues are notoriously difficult to debug and reproduce. The good news is that modern frameworks and infrastructure — application servers, message queues, reactive frameworks, distributed compute engines like Apache Spark — handle threading and concurrency for you.

Write single-threaded business logic and let the infrastructure layer handle concurrency. Reach for explicit threading only when you are building infrastructure-level components that genuinely require it.

14. Relying on Row-Level Locking

Row-level locking is the default on most relational database platforms, and under light, sequential load it performs well. Under concurrent load, contention on row locks causes queries to queue up and wait, leading to the classic symptom of an application that works fine in testing and mysteriously hangs under production load.

Snapshot isolation (also called multi-version concurrency control, or MVCC) avoids most lock contention by giving each transaction a consistent point-in-time view of the database. PostgreSQL and Oracle use MVCC by default. SQL Server supports it but requires it to be explicitly enabled (READ_COMMITTED_SNAPSHOT). Understand your database’s concurrency model and configure it appropriately rather than accepting defaults uncritically.

15. Using Database Sequences for All Unique Keys

Database sequences and auto-increment columns are a natural first choice for generating unique primary keys. However, they route every insert through a single serialised counter in the database engine — a bottleneck that becomes painful at scale and complicates distributed database architectures and bulk imports.

Unless you genuinely need sequentially ordered keys (which is uncommon for primary keys), use a UUID (version 4, backed by a cryptographically secure random generator). The collision probability of a properly generated UUID is negligible for any realistic data volume. UUIDs can be generated independently on any application node without database coordination, which is a significant scalability advantage.

Final Thoughts

These mistakes are not a mark of incompetence — they are patterns that emerge naturally under deadline pressure, from habits carried over from previous projects, or simply from not yet having encountered the failure mode they produce. The distinguishing mark of a senior engineer is not that they never make these mistakes, but that they recognise them quickly, understand why they are problems, and refactor decisively. Review this list periodically. It is easy to spot these patterns in someone else’s code; the harder skill is spotting them in your own.

The Rise of Low-Code Development

Organizations across healthcare, manufacturing, financial services, and virtually every other sector are accelerating digital transformation. One visible consequence is a highly competitive market for skilled software developers — particularly mobile app developers — at precisely the moment when many enterprises are being asked to deliver more with flat or reduced budgets. This tension is fueling rapid adoption of low-code development platforms, which allow business users and analysts to build and prototype applications without writing extensive hand-crafted code.

What Is Low Code?

The term “low code” describes a development approach that minimizes the amount of traditional programming required to create a working software application. According to analyst firm 451 Research, a low-code environment is defined as “any IT system or tool (e.g., platform, middleware, service) that uses visual models, prepackaged templates and graphical design techniques with drag-and-drop tooling to build software or integrate software and IT infrastructure.”

In practical terms, low-code platforms typically provide:

• Visual drag-and-drop designers for building UI screens and workflows
• Prebuilt templates for common use cases such as forms, dashboards, and approval flows
• Point-and-click integration connectors for linking to databases, APIs, and enterprise systems
• Configurable business rules that can be updated without redeployment

This model enables a degree of self-service application development that takes pressure off central IT teams while still keeping governance and integration in the hands of technical professionals.

How Low Code Helps Enterprises Move Faster

Speed is one of the most compelling reasons enterprises are adopting low-code tooling. Carl Lehmann, an analyst at 451 Research, has stated that low code “can potentially shave 50–90 percent off development time vs. a coding language.” While actual results will vary depending on application complexity and platform choice, the productivity gains are most apparent for common, form-driven mobile applications such as:

• Order fulfillment and inventory forms
• Field service work orders
• Employee onboarding and registration forms
• Customer surveys and feedback collection

For process-oriented applications, the combination of low-code capability with Business Process Management (BPM) platforms allows teams to quickly build workflow apps that can be reconfigured as business needs evolve — without waiting for a full development cycle.

Empowering Citizen Developers Without Bypassing IT

One significant shift enabled by low-code platforms is the emergence of the citizen developer — a business analyst, operations manager, or domain expert who can build functional applications without formal software engineering training.

Analyst firm IDC has observed that decisions about which mobile apps and infrastructure initiatives enterprises prioritize are increasingly shifting from IT decision-makers toward line-of-business (LOB) leaders and executives. Low code directly supports this shift by giving business stakeholders the tools to:

• Prototype and iterate on application ideas without opening IT tickets
• Model and adjust business workflows in BPM tools as requirements change
• Participate meaningfully in the digital product lifecycle

This does not mean IT loses control. Rather, low code formalizes a collaborative model where business teams handle self-serviceable app types, and IT retains ownership of integration architecture, security policy, deployment pipelines, and governance.

What Low Code Means for Professional Developers

A common concern among IT professionals is that low-code adoption signals a devaluation of coding expertise. In practice, this concern is largely unfounded for several reasons:

• Quality and capability vary significantly across low-code platforms. Complex integrations, custom business logic, performance optimization, and security hardening still require skilled engineers.
• Citizen developers are not integration specialists. Connecting enterprise systems, managing data contracts, and ensuring security compliance remain firmly in the domain of experienced IT teams.
• Low code accelerates professional developers too. High-skill development teams can use low-code tools for rapid prototyping, reducing the time from concept to stakeholder review.
• Governance still matters. IT departments remain central to policy management, deployment strategy, and ensuring that citizen-built apps meet enterprise standards before reaching production.

The most effective organizations are those that clearly define which application categories are appropriate for citizen development and which require full-stack engineering involvement — finding the right balance rather than treating low code as an all-or-nothing proposition.

Key Takeaways for IT Leaders

• Low code is not a replacement for professional development — it is a productivity multiplier for the right class of applications.
• Developer talent shortages are real, and low code is one practical strategy for extending capacity without proportionally increasing headcount.
• Governance frameworks matter. Establish clear policies for which teams can use low-code tools, what data they can access, and how apps are reviewed and deployed.
• BPM integration is a natural fit. Low-code platforms paired with BPM tooling deliver some of the highest ROI for workflow-heavy enterprise use cases.
• Platform selection requires scrutiny. Evaluate platforms for integration depth, security controls, scalability, and vendor lock-in risk before committing.

Summary

As competition for skilled developers intensifies, low-code platforms offer enterprises a pragmatic way to accelerate application delivery, close talent gaps, and bring line-of-business stakeholders into the development process. For IT teams, the technology is not a threat — it is an opportunity to focus professional engineering effort where it creates the most value, while enabling the broader organization to be more self-sufficient for simpler, well-defined use cases. The enterprises that get this balance right will be better positioned to deliver digital products faster and at lower cost.

Containers Were Just Getting Started

In early 2017, containers had already moved from curiosity to conversation topic in most engineering organizations. Docker had existed for only a few years, yet it felt like an established technology — a sign of how quickly the ecosystem was evolving. New tools were appearing daily, and just as many were disappearing. The container space was, and remains, fast-moving.

But by 2017, the interesting question was no longer what are containers? Most teams had completed a proof of concept. The real question had become: what comes next?

The Rise of Container Orchestration

The most significant predicted shift for 2017 was the move from simply running containers to scheduling and orchestrating them at cluster scale. Using containers to standardize development and testing environments was valuable, but the larger gains come when containers are deployed across distributed clusters with proper scheduling.

Three platforms were expected to become mainstream:

• Docker Swarm — Docker’s native clustering and scheduling tool, favored for its simplicity and tight Docker integration.
• Kubernetes — Originally developed at Google, Kubernetes provides sophisticated scheduling, self-healing, service discovery, and rolling updates.
• Apache Mesos — A general-purpose cluster resource manager capable of running containers alongside other workloads.

The prediction was that 2017 would be the year companies left the PoC phase and committed to container orchestration at scale. In retrospect, this proved accurate: Kubernetes in particular saw explosive adoption through 2017 and 2018, and eventually emerged as the dominant container orchestrator. The “battle for the uber orchestrator” the article anticipated did play out, with Kubernetes ultimately prevailing.

Alongside scheduling, the industry expected to see the rise of self-healing systems — clusters that automatically detect and recover from node or container failures without human intervention. Kubernetes readiness and liveness probes, along with its ReplicaSet controller, are the primary implementation of this idea today.

Continuous Deployment Becomes Practical

Continuous deployment (CD) had been a theoretical goal for years, discussed at conferences but rarely practiced end-to-end in enterprise environments. The prediction for 2017 was that container adoption would act as a forcing function: as companies built container-based infrastructure, they would also revisit and finally implement CD pipelines.

Importantly, the outlook emphasized that tooling alone would not solve the problem. Enterprises would need to recognize that CD requires architectural change — particularly a move toward microservices and independently deployable components. Monolithic applications are difficult to continuously deploy regardless of how sophisticated the pipeline tooling is. Companies would need to refactor services to align with cloud-native, cluster-based deployment models.

This insight aged well. The GitOps movement, the growth of tools like Argo CD and Flux, and the widespread adoption of feature flags and progressive delivery all reflect the same realization: deployment automation is a cultural and architectural challenge as much as a technical one.

Unikernels: Stepping Out of the Shadows

One of the more speculative predictions was the emergence of unikernels. A unikernel is a single-purpose operating system image that packages only the kernel components an application actually needs, compiled together with the application itself. The result is an extremely small, fast-booting, and potentially more secure deployable unit.

Unikernels were expected to unify some of the properties of virtual machines (strong isolation) and containers (small footprint, fast startup). The prediction was measured: unikernels would not take the world by storm in 2017, but would gain visibility and lay groundwork for broader adoption.

In practice, unikernel adoption has remained limited as of this writing, constrained by tooling maturity and the difficulty of debugging compared to conventional operating systems. However, the concept continues to influence work in WebAssembly runtimes and specialized edge computing environments.

Machine Learning Enters the Mainstream

In early 2017, machine learning was still concentrated in a small number of large technology companies and research institutions. The prediction was that 2017 would see ML capabilities extend to a much broader range of organizations, with companies beginning to invest in dedicated ML teams and infrastructure.

This trajectory proved correct. The availability of cloud-based ML services (from AWS, Google Cloud, and Azure), the maturation of frameworks such as TensorFlow and PyTorch, and the growth of MLOps as a discipline all reflect the broader democratization that was anticipated.

What Would Fade: Operating Systems, Configuration Management, and Provisioning

Just as interesting as what would rise is what was predicted to decline in relevance:

• Traditional operating systems — As immutable container images and potentially unikernels take hold, the choice of underlying OS becomes less important to application developers. Lightweight Linux distributions suitable for container hosts (such as Alpine-based images or minimal OS variants) were expected to gain ground over full distributions.
• Configuration management tools — Tools designed to configure and maintain persistent servers (such as Chef, Puppet, and Ansible in server-management roles) were expected to lose relevance as immutable infrastructure and container scheduling replaced the model of long-lived, hand-configured servers.
• Manual server provisioning — With schedulers handling workload placement, the concept of provisioning and configuring individual servers would become a concern of platform teams, not application developers.

The core idea is that developers’ lowest-level operational concern would shift upward to the scheduler API — specifying resource requirements (CPU, memory) and letting the platform handle placement and lifecycle. Infrastructure below that level becomes a commodity.

This prediction is directionally correct and is visible in the growth of managed Kubernetes services and serverless platforms, where developers interact almost entirely at the application and workload level.

Go as the Language of Distributed Systems

The Go programming language was predicted to move from open source projects into enterprise engineering organizations in 2017, driven by the growth of microservice architectures and distributed systems. Go’s properties make it well-suited for this context:

• Statically compiled binaries with no runtime dependency
• Low memory footprint compared to JVM-based languages
• Built-in concurrency primitives (goroutines and channels)
• Fast compile times
• Strong standard library for networking and HTTP

The prediction has largely held. Go is now widely used for infrastructure tooling (Docker, Kubernetes, Terraform, and Prometheus are all written in Go) and for backend microservices, particularly where performance and small container image size matter.

Decentralized Tooling and the Open Source Advantage

The final trend anticipated was a shift in how organizations make technology decisions. As polyglot architectures and microservices allow different teams to choose different stacks, centralized mandates for a single language, framework, or vendor become harder to enforce — and arguably less beneficial.

The prediction was that tooling decisions would become more decentralized, favouring open source solutions over proprietary enterprise software. This shift was expected to make it harder for software vendors to sell monolithic platform solutions.

This trend is visible in the CNCF (Cloud Native Computing Foundation) ecosystem, where a large number of open source projects compete and interoperate, and organizations assemble their own stacks rather than purchasing an integrated suite from a single vendor.

Summary: Which Predictions Held Up?

Looking back, this set of predictions captured many of the directions the industry actually moved. The container orchestration consolidation around Kubernetes, the rise of Go, and the practical maturation of continuous deployment pipelines all unfolded broadly as anticipated. Unikernels remain the notable exception — an area where the technical promise has not yet translated into widespread adoption.

The Scale of Automation-Driven Job Loss

A study titled Myth and the Reality of Manufacturing in America, conducted by the Center for Business and Economic Research at Ball State University, concluded that nearly 88% of manufacturing job losses in recent years can be attributed to productivity growth—not competition from foreign workers. Translate “productivity growth” into “automation” and the implication becomes clear: it is machines, not people from other places, that are displacing workers.

This is not a new phenomenon. Mechanisation has been displacing human labour since before the Industrial Revolution. What is new is the rate of displacement. Technology now compresses into a few years what once took generations.

Sectors Already Feeling the Pressure

Projections from the U.S. Bureau of Labor Statistics (figures cited in the original 2017 source, looking ahead to 2024) pointed to significant workforce reductions across several categories:

• Electronics installation and repair in vehicles: ~50% fewer workers needed as diagnostics and components become more reliable and self-correcting.
• Telephone operators: ~42% reduction as natural-language call-routing technology improves.
• Postal clerks: ~26% fewer, as self-service kiosks handle routine transactions.
• Parking enforcement officers: ~20% reduction as smart meters and digital monitoring take over ticketing.

These are not edge cases. They represent entire occupational categories that are shrinking faster than new roles appear to absorb displaced workers.

Self-Driving Vehicles and the Ripple Effect

Consider long-haul trucking. As autonomous vehicle technology matures, self-driving trucks on highways shift from experimental to economically inevitable. The number of professional truck drivers potentially displaced in that transition alone would represent one of the largest single-sector workforce disruptions in modern history.

The ride-share scenario compounds this further. If a company like Uber or Lyft replaces its human drivers with fully autonomous fleets, the economics change dramatically for consumers. A flat-fee, unlimited-mileage monthly subscription could easily undercut the combined cost of vehicle lease payments, insurance, fuel, and maintenance for private car ownership. When that threshold is crossed at scale, privately owned vehicles parked on streets become an anachronism—and the downstream effect is fewer cars manufactured, which means fewer workers in automotive factories and supply chains.

Automation Inside Software Itself

Automation is not only displacing blue-collar roles. Consider how logging infrastructure has evolved within software engineering:

• Stage 1: A person manually rotated log files on disk when they grew too large.
• Stage 2: A script automated file rotation based on size thresholds—one manual task eliminated.
• Stage 3: Cloud-based log aggregation services (e.g., centralised logging platforms) absorbed the need to manage archive hardware entirely. No more server room visits, no capacity planning scripts, no manual intervention.

Each stage removed human effort that had commercial value. Multiply this pattern across CI/CD pipelines, infrastructure provisioning, monitoring and alerting, and security scanning, and it becomes apparent that automation is consuming significant portions of what used to be skilled engineering work—not eliminating it entirely, but reducing the headcount required to operate the same infrastructure.

“Just Retrain Workers” Is Not Enough

The most common policy reflex when automation displaces workers is to call for retraining programmes. For knowledge workers in technology, this argument has an obvious flaw: continuous learning is already a baseline survival requirement, not a one-time intervention. The skills needed to write an infrastructure-as-code deployment against a cloud provider are non-trivial, and they are often obsolete by the time a worker finishes learning them. Retraining assumes a stable target skill set. In fast-moving technology domains, no such target exists.

For workers in manual or semi-skilled roles, the challenge is even steeper. The cognitive and educational prerequisites for replacing an eliminated role with a technology role are significant—and expecting a workforce of millions to make that transition quickly is not a realistic plan.

Economic Responses: Universal Basic Income

One structural response to near-total automation is Universal Basic Income (UBI)—a programme in which citizens receive a baseline income regardless of employment status. The concept is not new; economists including Milton Friedman advocated versions of it in the 1960s under the label of a “negative income tax.” Finland launched a limited pilot programme exploring UBI principles, and other countries have conducted experiments in this space.

The logic is straightforward: if the economy structurally cannot provide enough employment for the population, tying individual survival to employment becomes unsustainable. UBI attempts to decouple basic economic security from labour market participation.

Human Dignity in a Post-Labour Economy

Perhaps the least-discussed dimension of this transition is psychological. Philippe Kahn, founder of Borland, Starfish Software, LightSurf Technologies, and Fullpower Technologies, framed the paradox clearly when asked about automation’s social impact:

“I remember being in India and watching a construction site: lots of people, elephants, activity. I asked, ‘Why don’t you all use bulldozers and tractors and prefabricated concrete parts?’ The answer was enlightening: ‘How would this community make a living with dignity?’ That’s the whole paradox that we are dealing with: productivity versus dignity for communities that could be unemployed for generations.”

— Philippe Kahn

The distinction between work and labour matters here. Labour is what people do to survive economically. Work, in the broader sense, is activity that gives life meaning—creative output, caregiving, community contribution, artistic expression, scientific inquiry. In an economy where machines handle most labour, humans do not automatically lose the need for meaningful work. They lose the income that labour provided.

Where Human Activity Can Still Excel

A highly automated economy will, by definition, generate significant productivity and wealth. The critical question is how that wealth is distributed. Activities that carry high human value but low commercial value—rare-disease research, basic science, space exploration, arts and culture, education, social care—are precisely the domains where human contribution is most defensible and most needed. These are also the domains that market mechanisms consistently underfund.

Funding these activities at scale, through whatever mechanism society chooses, would allow humans to engage in meaningful work that machines cannot easily replicate or commercially justify. This is not a utopian proposal—it is a recognition that the old relationship between productivity, employment, and income will require deliberate restructuring rather than passive market adaptation.

What DevOps and Engineering Teams Should Take Away

For those of us building the automation infrastructure that is driving these changes, the engineering challenge is inseparable from the social one. Pipelines that eliminate manual deployment steps, monitoring systems that replace human operators, AI-assisted code review that reduces the need for junior reviewers—these are not neutral technical achievements. They have labour market consequences that accumulate.

This does not mean engineers should slow down innovation. It means the profession should engage honestly with the downstream effects of what it builds, advocate for policies that distribute automation’s benefits broadly, and resist the comfortable assumption that retraining alone is a sufficient social response to structural displacement.

The question—what will we do when everything is automated?—is no longer speculative. It is an engineering and policy problem that is already in progress.

The Provocative Claim: “Coding Is Dead”

In February 2017, Nitin Rakesh, then newly appointed CEO of IT services firm Mphasis, made a statement that ricocheted around the industry: “Coding is dead. I don’t need to do any native development anymore.” Speaking to BusinessLine, Rakesh argued that large public cloud platforms — Amazon Web Services (AWS), Salesforce, Microsoft Azure, and IBM Watson — had fundamentally changed how software is built and delivered.

The claim was deliberately provocative, but the underlying point deserves careful examination rather than a knee-jerk reaction. What Rakesh and other executives were describing was not the end of programming as a discipline, but a structural shift in how software is assembled and delivered at enterprise scale.

What “Cloud First, Mobile First” Actually Means for Engineers

Rakesh’s argument centered on a straightforward observation: banks and enterprises that once wrote custom code in native Java on Unix machines are increasingly running workloads on managed cloud platforms. On those platforms, much of the heavy lifting — infrastructure provisioning, runtime management, security patching — is handled by the provider.

The practical consequence for engineers is a shift in the value chain:

• Less time writing low-level boilerplate. Billions of lines of open-source code are freely available and can be composed — much like assembling Lego bricks — rather than written from scratch.
• More time on configuration and integration. As Rakesh noted, frameworks such as Node.js allow engineers to orchestrate existing routines rather than write native implementations from scratch.
• Faster time to market. Reusing battle-tested components reduces development cycles and shifts competitive advantage toward teams that can integrate quickly and iterate rapidly.

The KPMG Counterpoint: Programming Knowledge Still Matters

Not everyone accepted the “coding is dead” framing without qualification. Akhilesh Tuteja, Partner and National Head for Technology and BPM at KPMG, offered a more nuanced view:

“It is true the way we program today may not exist in the near future, as there’ll be more of reusable code that’ll be in play. However, you will require some level of programming knowledge to understand how to put these blocks together and make sense of them.”

Akhilesh Tuteja, Partner and National Head (Technology and BPM), KPMG

This is the more defensible position for working engineers. Composing cloud-native services, configuring infrastructure-as-code pipelines, writing Terraform modules, or building serverless functions all require genuine programming literacy. The abstraction layer has moved up, but it has not disappeared.

Automation Accelerates the Shift

Platforms such as AWS, Azure, and IBM Watson do not just provide managed infrastructure — they also provide tooling that automates testing, deployment, and monitoring. What once required days of manual testing can be triggered with a single pipeline step. This is the DevOps proposition in practical terms:

• CI/CD pipelines automate build, test, and release cycles.
• Infrastructure as Code (IaC) tools like Terraform and AWS CloudFormation reduce manual provisioning to configuration files.
• Managed services (databases, queues, identity, ML inference) replace large categories of custom code with API calls.
• Low-code and no-code platforms extend development capabilities to non-specialists for well-defined problem domains.

The cumulative effect is that a small, skilled team using modern cloud tooling can deliver what previously required large groups of native developers — not because coding is irrelevant, but because automation has dramatically raised the productivity ceiling per engineer.

Industry-Wide Re-Skilling: What IT Services Firms Were Doing

By 2017, major Indian IT services firms — TCS, Infosys, Wipro, and Capgemini — were already investing heavily in re-skilling large portions of their workforces. The focus areas reported at the time included:

• Agile and Scrum methodologies
• Design thinking and rapid prototyping
• Cloud platform certification (AWS, Azure, GCP)
• Reusable-code and component-driven development

Patrick Nicolet, Group Executive Board member at Capgemini, was quoted summarizing the urgency: “If you look at delivery in digital, it is about design thinking, agile, rapid prototyping and everything that is fast and furious. The way we have designed our delivery so far is not fast and furious.”

What This Means for DevOps Engineers Today

The 2017 conversation anticipated trends that have only accelerated. For DevOps and platform engineers, the practical takeaways are:

1. Understand platforms deeply, not just syntax. AWS, Azure, and GCP are now primary engineering environments. Knowing how to wire services together securely and efficiently is a core skill.
2. Programming literacy remains non-negotiable. Writing Bash, Python, Go, or HCL (Terraform) is still essential — the abstraction layer has moved, not vanished.
3. Automation is the multiplier. Engineers who can build and maintain robust CI/CD pipelines, automated testing suites, and infrastructure pipelines consistently outperform those who cannot.
4. Reusability is an architectural discipline. Internal developer platforms, shared Terraform modules, and standardized container images are the modern equivalent of Rakesh’s Lego-block analogy.
5. Speed is the competitive variable. “Fast and furious” delivery — iterating quickly based on real user feedback — is increasingly what separates effective engineering organizations from slow ones.

The Verdict: Transformation, Not Death

“Coding is dead” was always a headline engineered for attention. The reality is more nuanced: the nature of software engineering is transforming. Low-level native development has a shrinking role at the application layer, while platform engineering, infrastructure automation, and systems thinking have a growing one.

Developers who adapt — learning cloud platforms, embracing automation, and mastering reusable-component architectures — are not facing obsolescence. They are becoming significantly more productive. Those who treat any single language or framework as a permanent career foundation, without adapting to platform-centric delivery, face a harder road.

The most durable skill, as it turns out, is the ability to learn — which is precisely what these executives were arguing in 2017.