The Wrong Shoes for the Race

You can run a marathon in leather brogues. You will just finish slower, in more pain, and need to call the medics every other mile. Developers can build on standard corporate laptops. They will just spend half their time waiting, and the organisation pays for every minute.

Corporate IT is not to blame. Their mandate is enterprise protection and scale. Uniform fleets are the safest way to defend against ransomware, phishing, and the daily churn of threats. For most employees, working with spreadsheets, presentations, and calls, that model is exactly right.

Product engineering is different. A developer’s workstation is not office stationery. It is a local build farm, a miniature data centre. When that workstation is too weak, or too tightly controlled, the work spills into integration and test environments. That is where the trouble starts.

The vicious circle

Integration and test environments always begin with good intentions: centralisation, efficiency, standardisation. In practice, they are the worst place to do daily development.

Imagine dozens of teams deploying to the same cluster. Yesterday your feature worked. Today it fails, not because of your code but because someone else restarted a service or rewrote the data. Debugging becomes guesswork: is the failure mine, or is it just background noise?

Developers adapt by rerunning tests, redeploying repeatedly, and wasting hours stabilising an environment never designed for constant experimentation. The weaker the local workstation, the more teams lean on integration and test environments. The more they lean, the less stable those environments become. Instability feeds dependency, and dependency feeds instability.

Two poles, one pattern

The loop is visible from both ends of the technology spectrum.

• Modern JavaScript ecosystems involve thousands or even millions of small files. On Windows, the slowdown is not marginal but staggering. In one benchmark, a routine task took more than two minutes on NTFS, the default setup for most enterprise developers, compared with under six seconds on Linux. Even with WSL2 it was nearly nine seconds, and with antivirus enabled Windows stretched to twenty-five seconds. That is a twentyfold slowdown between the default and the target platform. What Linux finishes in a breath, Windows turns into a coffee break.
• Enterprise Java or .NET services are heavy, stateful, and tied to broad databases. Local workstations strain or are blocked outright. Teams fall back on integration and test environments, where deployments collide and failures blur between defects and environment.

Different ecosystems, same outcome: weak workstations force reliance on shared systems. Shared systems degrade under the weight.

The invisible invoice

An hour a day lost feels manageable. But across two thousand engineers, it is more than half a million hours a year. Even at a cautious twenty-five pounds an hour, that is £12.5 million a year in invisible cost. And that is before you consider the twentyfold slowdown seen on common developer tasks, a multiplier that magnifies waste across every build, reload, and test.

The figure is invisible because it never appears on a procurement invoice. It appears instead in the firefighting that dominates integration and test environments, in delivery dates that slip, and in production systems that inherit fragility from the way they were developed.

It also appears as an opportunity cost. Leading vendors in feature flagging and progressive delivery are already asking whether lower environments are needed at all, replacing them with controlled rollouts and instant feedback. If local development remains weak, organisations miss the chance to evolve toward that future.

A twentyfold slowdown on everyday tasks turns instant feedback into a coffee break. Multiply it across 2,000 engineers, and the cost exceeds £12.5 million a year.

Why local matters

The best way to stabilise integration and test environments is to use them less.

When developers can run services predictably on their own workstations, those environments become calmer. Changes arrive tested. Experiments happen locally, where failure is cheap. Shared clusters return to their intended purpose: integration, not survival.

Isolation is the key. Whether the environment runs on a workstation or in a personal Kubernetes namespace, what matters is that it is not shared. Daily development in a shared cluster is like running a marathon on a collapsing track. Predictable environments, even if lightweight, restore focus and stability.

This is the same divide I explored in Shaping Architecture Through Behaviour. Enterprise Architecture fits when the goal is stability and control. It matches the rhythm of corporate IT, where uniformity is the defence against risk. But product engineering thrives on different behaviours: fast feedback, local experimentation, continuous integration. Apply EA’s slower logic here and you get the same outcome as with integration and test environments: drift, instability, and mounting cost.

There is also a cultural signal. If a system is easy to run on a workstation, it is usually easier to run in production. The same seams that make hot reload fast also make deployments reliable. Complexity that frustrates developers today has a way of resurfacing at three in the morning tomorrow.

Who should own the workstations?

It is not fair to expect Corporate IT to solve this. Their focus is scale and safety, not compiling monorepos or running clusters of services. Their instincts, uniformity and control, are right for the majority.

But in a product operating model, developer workstations need different ownership. Platform Engineering, SREs, and Principal Engineers must take the lead together.

• Platform Engineering sets the standards: workstations treated as production equipment, automation that keeps local and production aligned, guardrails that enable speed without compromising safety.
• SREs, embedded in squads, see the friction first-hand. They notice when reloads slow, when containers thrash, when local setups drift. They carry those signals back into the platform.
• Principal Engineers are building code every day. Their judgement keeps decisions grounded in practice, not abstractions. No ivory tower, just experience guiding direction.

Corporate IT safeguards the enterprise. Platform, SRE, and Principal Engineers ensure workstations are fit for purpose. Together, they break the cycle: security without paralysis, speed without fragility.

The business lens

Uniform fleets reduce risk. Fit-for-purpose workstations reduce waste. The better question is not what does a laptop cost, but what does a feedback loop cost?

Break the vicious circle, and integration and test environments stabilise, production steadies, and delivery accelerates. That is what the business values: resilience, predictability, and speed to market, achieved without compromising security.

And the direction of travel is already visible. Feature flag platforms such as LaunchDarkly argue for dropping lower environments altogether, replacing them with controlled rollouts and instant feedback in production. That model may not work in regulated industries, but it shows where the frontier lies: stronger local development, lighter reliance on integration and test environments, and faster, safer delivery.

And if production runs on Linux, why not our workstations? That is a question for Part 2.