The problem
Most product development teams are having a hard time. Customer expectations are through the roof, even for B2B Applications. And with the barrier to entry to starting global businesses just keeps dropping, which means the list of competitors is ever growing.
So on the surface it sounds like a breath of fresh air that developer productivity has skyrocketed over the past 10-20 years. We already have better programming language, Agile, REST, microservices and component frameworks to name a few, but it is going to accelerate even more with GraphQL, serverless, design systems and tools like Playroom.
And it is not going to make any difference whatsoever.
Because the bottleneck in product development hasn't been developer productivity for a while, and it certainly won't be in the future.
The biggest bottleneck is feedback. Getting it, integrating it and applying it within context. The way to building products customers love is by relentlessly tightening your feedback loops.
Unfortunately it is often assumed that it is just the nature of software development that it is a big black box. That the only two points in time you can give feedback on work in progress are a) when you stand over the shoulder of the developer working on it or b) after the software is deployed to a staging environment and it is too late.
What does it look like?
So how do we know that the bottleneck of product development is getting and integrating feedback? Because once you realise it, you see the symptoms and work-arounds everywhere.
Here are some of the work-arounds or symptoms you see often.
"Perfect" designs
The thinking here is that the better the input to development is, the better the output. This almost never works though. There are just too many details, edge cases and complexity to be able to account for everything.
Fighting over environments
With a finite amount of environments, developers are constantly fighting over where to deploy for someone to look at it. Teams often start out abusing a staging environment for this. Then they often create a dedicated demo environment. And the work just keeps piling up. More demo environments, exposing developer machines online, dedicated VMs per developer. It will never be enough.
Elaborate, extremely brittle, test suites
As a substitute for testing by humans teams have created elaborate End to End testing suites. E2E tests, especially for frontend applications, take an enormous amount of time to write. And they break all the time. Which means they are almost never worth doing for anything but the most crucial flows in your application.
We are also seeing a surge in interest in visual diffing tools like Percy. They are brilliant at augmenting, but can never replace human judgement.
A blocked pipeline
A feature, often a relatively big one, makes it to staging and is about to be released when someone realises it can’t go out for some unforeseen reason. And everything grinds to a complete halt because the rest of the code base now has this feature in it and we have to decide if we fix it, roll it back, or feature flag it.
JavaScript injected A/B testing
Desperate for feedback from our users, it makes sense we turn to A/B testing. But setting up A/B testing infrastructure properly is incredibly hard. And products like Optimizely jumped into that void. They dynamically replace parts of your page based on configuration on their server. This comes at a high cost. It slows down page loads, it leads to jarring user experiences when the page changes and has the potential to break your app entirely.
Inappropriate feature flagging
Feature Flags are an essential tool in today’s modern development arsenal. And they are great when they are used, to well, flag features. But if all you have is a hammer..
Teams often resort to using feature flags to do short lived canary release or demo an unfinished feature to a stakeholder or customer.
While feature flags can greatly reduce risk, they are not without risk themselves. And teams will risk affecting production for all your customers just to show something to one of your colleagues.
Shipping mediocre software
But the most obvious symptom of the lack of feedback opportunities is shipping mediocre software. An endless list of small things that we would like to fix, and that would have been trivial if we had known about them earlier, but are now languishing on a backlog somewhere. Never important enough to actually be picked up. Before you know it you are in a downward spiral. Customers aren't excited, developers are less proud, pressure on product to deliver more features, which still not excites your customers... rinse and repeat in a race to the bottom.
Just to be clear: these are not problems in and of themselves. They are symptoms and workarounds of the real problem—it is way too hard to get and integrate feedback during development.
What do we need to do?
We have treated development as a black box for far too long. In our quest for productivity we have squeezed out the humans.
For large parts of our application that is actually pretty good news. For backends, tests are more reliable and require much less iteration to get right. Removing humans in this case reduces the likelihood of human error.
But removing humans is absolutely disastrous for frontends. Frontends are messy because their quality is not binary.
That means we’ve lost the ability to use our judgement. We’ve dismissed the domain expertise and the knowledge of every non-developer in your organisation. We’ve tried to turn a human problem into a technical one, and are thus using the wrong tools to solve it.
We need to completely rethink the way we approach CI/CD for frontend applications. When it comes to our frontend release automation, we need to make both feedback & people first-class citizens again. Every single person in your organisation should have the feedback they need at their fingertips to help deliver the best possible product to your customers.
We feel very strongly that everyone should be a product developer. Someone who contributes to delivering amazing products, no matter what their job is. You could be a software developer, in QA, a product manager, a sales manager, an accountant, or even a customer.
What does a solution need?
But what would such release automation look like? We think it should have 4 crucial features & attributes.
Every commit against every backend
Some features need polish and potentially multiple round-trips between people, while simple fixes are usually ready to go in minutes.
This means it is impossible to rely on a simple pipeline like we do for backends where we move code from environment to environment. Those features would regularly clog up the entire pipeline.
The purpose of automation is to augment, not replace judgment
We can do a ton of automation, but it should all be in service of augmenting human judgement. Take a tool like Percy.io for example; Visual diffing can't say for sure whether something is good or bad, but it helps isolate what has changed so a human can look at it.
Information has to go where the people are
If we want more people to be product developers and be involved during development, information has to go where they are. We must get links, feedback, screenshots, performance snapshots, etc into a Github Pull Request, a Slack channel or a Trello card for example. Having a dashboard isn’t enough.
Customers play a critical part
Probably the most important source of feedback are your customers. So release frequency is essential, which means making sure they are frictionless and extremely safe. Frequent iteration and extracting feedback from stakeholders is essential to building products customers love.
Our vision for Linc
But perhaps our biggest realisation was that we could build all that as a product. CI/CD products like Buildkite, Travis & CircleCI give you all the tools to build your own pipeline.
But with Linc we can give you the best possible release automation for frontend applications that money can buy.
We want you to be able to turn on any automation or integration you want in your pipeline with the click of a button, instead of spending hours, days or even weeks developing it yourself.
But most importantly we want to help you deliver better products by giving everyone in your organisation the information they need to make the best decisions.
Which is why we call it a Frontend Delivery Platform.
And we will not stop developing it until every single developer in your organisation can collaborate with anyone in the organisation, safely release an experiment into production and get real customer feedback in minutes.
