Managing excess complexity in modern development
Throughout my career, I've seen the pendulum of software engineering swing from "throw-it-over-the-wall" pre-DevOps to today's reality where developers have more responsibility than ever. From single-language specialists to full-stack generalists, the industry expects developers to know and do everything. The current state is unsustainable: in addition to building features and fixing bugs, developers are responsible for an intricate web of security, infrastructure, and compliance.
Many developers are overworked and stretched well beyond their expectations, and this is impacting businesses and their customers. Consider the size, scale, and impact of recent outages, data breaches, and security incidents – chaos is an emergent property of an overstressed system. Developers are craving help, and we need to give it to them. There has to be a better way.
Modern organizations should move towards streamlined, automated processes that allow developers to focus on what they do best – building software – while enabling the heavy lifting of infrastructure, security, and compliance to give rise to specialists.
Exploring the problem
Suppose I'm a software developer at a small company. I've been assigned to write an internal application and API for tracking how users interact with our products. I've got everything working on my local machine, and now I'm ready to deploy... Suddenly, I'm hit with a wave of realizations:
- What cloud do we use? Where do I get credentials?
- How do I create a VM? How much RAM do I need? How much CPU do I require? What operating system do I use?
- How do I create a database? In what region(s) should the data be stored? What database engine do I use? Should I be snapshotting?
- How do I make the VM and the database talk to each other? What is a VPC? What is IAM?
- How do I restrict my application to internal users at my company? How do I make new people get access automatically? How do I make sure former employees lose access automatically?
Additionally, this data is all customer PII, so proper networking and security are paramount for ensuring this data does not end up in the wrong hands. At best, my company might have some standard templates and documentation, but usually I'm in the Wild Wild West searching for blog posts and community templates for help.
Specialists: Mechanics versus Drivers
Maybe there's something we can learn from a different industry. Let's take a moment to look at automobile interface design. There is a bell curve of sophistication when it comes to interacting with a vehicle.
- Passengers (left of the curve) will interface with a very limited subset of the vehicle such as opening the door, tuning the radio, or reclining the seat.
- Drivers (middle of the curve) interface with a larger set of functionality such as starting the vehicle, shifting gears, turning the steering wheel, using turn signals, or activating the headlights. Even though this is a limited set of the overall functionality of the vehicle, the driver is still empowered to travel from Pittsburgh to Philadelphia; they can take any route as long as they know how to use these interfaces.
- Mechanics (right of the curve) interface with the intricacies of a vehicle's internals, across many different makes and models. They may change the brakes on a 2004 Ford Focus, swap out the wiring harness on a 2011 Toyota Tacoma, and finish the day doing a tire rotation on a 2024 Porsche Taycan. These are all dramatically different procedures that require vast expertise and domain knowledge across many different platforms.
We cannot require developers to be the auto mechanics of software, yet that's the situation most developers find themselves in today. They're hand-crafting infrastructure, oftentimes with incomplete documentation and knowledge. Even if they get it right, it comes at the expense of their time and sanity. Instead of developers building their own cars, or asking platform teams to build a unique car every time, we need to abstract away this complexity and enable specialists to scale.
Simplifying developer UX with infrastructure
Central teams (security, privacy, reliability, compliance) can look to the auto industry as a model for how they should be interacting with developers. Right now, many developers operate in silos, driving shadow IT, missing security or compliance issues, and failing to reach economies of scale. Just like a car's steering wheel and turn signal maximize the driver's experience, a simplified developer experience maximizes developer productivity. In this model, central teams are the auto manufacturers and the auto mechanics – they build and maintain the platform abstractions that enable developers to be successful. Some of these features include:
- Clear APIs and tooling
- Secure-by-default
- Reduction of choice
- Golden, recommended deployment patterns
Note: The ability to deviate from patterns, but only after acknowledging the impact, is an important consideration when building developer tooling. Here’s a great example of that behavior.
Outcome: security, reliability, velocity in harmony
This approach unlocks developer potential through uniform, simplified tooling. Instead of spending their time wrestling with infrastructure and seeking constant help from central teams, developers will be free to focus on innovation and building great products. This shift not only benefits developers but also central teams, who can finally escape the support treadmill and focus on driving strategic initiatives.
By rethinking how we manage complexity in modern development, we can create a more sustainable and effective environment for everyone involved, leading to better business outcomes and a happier, more productive workforce. The goal is to optimize the triad of velocity, security, and reliability.
Today most teams are at the "pick 2" stage, hugging closely to an edge of the triad. The goal should be to achieve equilibrium in this triad, moving to the center and achieving all three in harmony. This is only possible with proper UX and support from central teams – we cannot leave developers to fend for themselves.
Note: The triad is an average over time, and it can swing depending on business needs. Consider Apple WWDC or AWS re:Invent. Surely these teams are biasing towards velocity while approaching these events, but ultimately the goal should be equilibrium in the long run.
Driving towards a better future
One thing is super clear: companies are asking way too much of their developers while providing them limited support. While this post discussed how to support developers, achieving the balance between security, reliability, and velocity at scale requires intentional investment and partnership from central teams and specialists (e.g. platform, security, operations).
Instead of continuing the status quo of bespoke tactical engagements between specialists and developers, companies must transform to focus on enabling specialists to scale by embedding their expertise in platforms. Organizational leaders need to adjust the expectations (and reward structures) of specialists to focus on "automating away manual toil" instead of "number of JIRA tickets closed".
Without this mandate to scale, your specialist teams will never escape the support treadmill, and your developers will decay in the gradual decline of engineering productivity.
