In the world of frontend development, there is a lot of content and tutorials about finding the right framework or naming things right or applying the right techniques. During that discussion, someone will always come along and say: “But the users will not care how it has been built”. That is, in its core, true – but.

Here’s the thing. Martin Heidegger, who has nothing to do with frontend development, once noted that we don’t see the tools for what they are, but what they mean - and that in fact the most tools to us are invisible. We only care about the knife, when the edge is dull – because only then it gets in our way. This is the same with the tools that we use in our daily work.

Let’s dive into an example. A group of developers are working on a fairly big website. They have a solid CI/CD pipeline, and the product is technically sound and reliable. However, it takes a long time to build a new Javascript / CSS bundle, and even longer to deploy it to a test system. Due to its complexity, it is hard to test in local environments. This leads to the people implementing solutions that only meet the minimum viable acceptance criteria, but avoiding anything more, especially experimenting with possible better solutions. The tooling gets in the way of awesome work.

This is starting to become critical when it comes to performance improvements. Performance improvement is to a good extent trying out things and measuring the effect. Especially in rather complex systems, there is no cookie cutter approach possible. But when the better part of your days is spent waiting, then sooner or later everyone is happy if they don’t need to spend time with this process longer than necessary, and even the most ambitious people will eventually stop putting up with it. How will this product finally feel? It might be “technically correct”, and maybe good, but never great.

But at least, in this example there is somehow an agile delivery built in. Working on a legacy codebase does not only mean you don’t get to work with the newest shiny toys – but it is also complicated to test and to deliver. So even though innovation would be possible within the constraints, it is actively held back by the tools not supporting developers but instead standing in their way. One of the best examples is the 25 Million LOC monster of Oracle SQL DB, where it can take up to two months for a bug fix to be part of the product. People are turning away from the product, as there are arbitrary limitations, and little development of new features.

This does not stop with developers. Editors and content managers face the same problems, on two ways. Again, as a simple example, the CMS that they are using might not allow for accessibility features such as localisable Alt Attributes for images. Or, on the other hand, the person preparing and writing the content has no idea that this exists and does not provide it – because no one likes working with the CMS as this is “too technical”. In both cases, the tool has gotten in the way of the work.

So, when choosing a framework / architecture / implementation approach, make the Developer Experience (or Editor Experience) part of the evaluation criteria, and part of the acceptance criteria. Make it easy for the people who create the product, so that they can create not just a good experience but a great one.

After all, “we shape our tools and, thereafter, our tools shape us” (John Culkin).