How much coding is actually code?

When I learned programming at school, I’d open the IDE, write a program, click ‘play’ somewhere in the IDE and that’s pretty much it. It was 100% efficient 💪 !

Twenty years later, I rarely see developers spending more than 70% of their time actually writing code. I’m not talking about time spent on meetings or Twitter, I’m at peace with that, what I’m pointing out is that 30% of the time I’m supposed to code is gone on making tools talk to each other in order to ship my code as my good old IDE did with that magic ‘play button’.

So where is that 30% of time spent anyway?

Let’s assume you and I have a nice modern setup in AWS and we have magically offloaded our problems to Kubernetes. Moreover, we have a monorepo in GitHub that makes our life simple, plus a lovely Jenkins that is the cornerstone of continuous delivery. This is heaven.

Still… there are some details we have to regularly take care about:

• CI/CD scripting: well… yes, it’s true, a new project sometimes requires adjustments to the CI. It’s also true that nobody wants to touch that thing that’s impossible to test and could easily break for everyone at once, so this will be something that I won’t enjoy doing, but I’ll have to do it anyway.
• Infrastructure as Code: as conquerors need land to conquer, our code needs not only VMs but VPCs, balancers, IAM users/roles/policies, ECR registries, and most likely many more institutions of the cloudocracy. So we’ll plan to spend some time with Terraform’s HCL 🙂.
• Kubernetes: now it’s time to spend some time mastering our YAML skills (at best) or our JIRA ticketing skills (at worst).
• APM: a decent production application will require us to know how we are doing so here we go again... let’s invest some time in talking to one of the many APM tools out there.
• Logs: the good old IDE had a nice console, but our K8S cluster needs something better that takes care of safely delivering logs somewhere and keeping them available for some retention time. So save some time to find a tool and let it know how we want the logs served for dinner.
• Secret Delivery

At this point of the story, I’m already exhausted and we haven’t even covered areas such as governance, networking, security, etc. The list could easily duplicate.

DevOps to the rescue?

So it’s clear that we don’t want this burden as we didn’t want to manage a database or the network in the data center. I have come up with the perfect solution: make it somebody else’s problem!

DevOps can be a great ally for engineering teams, they are specialized in these tools and do a fine job operating them, but what they struggle is with becoming transparent to developers and actually empowering them to code their product as if these problems did not exist in the first place.

As companies become larger, this setup can create undesirable side effects such as a “ticketcracy” where people in the organization talk through tickets, to the detriment of a culture of ownership. Moreover, the most successful DevOps cultures have KPIs based around efficiently gluing the tools rather than on the developer experience.

Did we solve the problem? No, and the risk of procrastinating the problem is that our organization might enter the non-efficient zones of this yield curve between output (code, features, money, quality) and the input (time, investment, resources) becoming negative at some point in complexity (growth).

Empowering developers

The development cultures I enjoy and respect the most are based on teams that are empowered to take decisions and are biased toward action. That is teams that own the problems they work with and have the freedom to innovate at any time with little coordination with other teams.

To achieve this kind of culture and for people to thrive in it, you’ll need to remove the burden of recurring problems that add zero value to the business (eg: finding out how to declare an IAM policy to access a DynamoDB table in Terraform) while establishing lean standard processes that allow every developer to move freely around the company without requiring an induction about the infrastructure of every API or frontend.

The Developer Platform

Most major companies I know about have been suffering from these issues and have put a lot of resources into building an internal developer platform that empowers developers to spend time coding for the business rather than tooling. While I can’t vouch for all of the solutions out there, properly crafted ones have some clear advantages:

It’s a single, proven way. Once you define a development process, it is instantly adopted across the board because the platform enforces a way of doing things. This is when the company decides that releases need to have a tag in GitHub, the system adopts that practice across the board at once, not requiring/depending on engineers to implement the policy in each project.

To code the product, not the cloud. After building their internal development platform, the biggest food delivery company in LATAM witnessed a 3X increase in “avg. deployments per developer per day” KPI while the time was doubling in size! Focusing more on coding the product has great advantages ranging from a higher alignment between the development team and business success to dramatic improvement in time to market.

Welcoming devs from all backgrounds. As I once left school knowing little more than coding in my IDE, there are a lot of devs making their first steps who can contribute to your product if you simplify things for them and leave the burden of tooling aside. The simplest setups I’ve seen required a new developer +4 weeks of onboarding time while the best ones required a few hours for someone to kick off meaningful work.

To govern the cloud reducing inefficiencies. We as developers are very good at scaling something that is resource hungry, but do we do the same when we have a slack in computing power? No, we don’t 🙂. One of the top #5 marketplaces in the world saved nearly 50% of their cloud costs by automatically rightsizing instances and replacing on-demand with spot instances, all without developer interventions (this has yielded high double-digit savings in million USD).

Fostering a healthier culture. People’s collaboration should be about creating synergies rather than for the sake of watching how tickets bounce from one place to another.

Build or Buy?

The biggest companies have built these platforms, but they are (a) very expensive (b) time-consuming (c) and hard to get right without prior experience. Companies such as the one I have mentioned, spend a few million a year on teams developing such systems (which repays for them as efficiencies at their scale pay off). So, except you’re a Fortune 500 company, it is very likely that you’re better off with a proven solution (plus avoiding coding something that’s not your core product).

You’re invited to join nullplatform.io

We’ve built nullplatform -a free developer platform that operates your cloud account- to empower developers and help them to get back that 30% of their time that’s wasted on coding what they shouldn’t be caring about.

• Create and deploy apps in any technology in 1 minute, spending zero time on tooling 🙂
• Own the cloud. We operate a (sub)account owned by you, in the cloud of your choosing (AWS / GCP / Azure),
• Own the code. We operate on your GitHub account and have no frameworks, libraries, or presence of any kind in your code,
• Smart deployments: a progressive blue-green deployment with zero request loss.
• APM, Log, Parameter, Secret Management, and Metrics are instantly available, spend zero time tooling around.

Start today at https://www.nullplatform.com/!

You can also reach us by e-mail or @nullplatform Twitter account.