Links - 10^th August 2025

Dependency problems are frequently boiled down to discussions about estimation and commitment, when the real conversation should be about priorities and actual outcomes. In the current economic climate, teams are too gun-shy to escalate issues, so you’ll hear a lot of talk about the evils of dependencies but very few concrete examples.

This pure/impure distinction has been obscured by the fact that there used to be much more scope for pure engineering at large tech companies. In the 2010s, times were different. Companies were driven almost entirely by hype, and they were hiring more engineers than they knew what to do with. Funding pure engineering projects solved both of those problems: it produced impressive open-source artifacts that made the company look good to prospective engineering hires, and it provided a bottomless pit of useful-looking work for those engineers to do.

Even impure engineering got colonized by pure engineering. Companies burned hundreds of thousands of engineer-hours migrating from monoliths to microservices, or from HTTP service calls to event-sourced architecture, or from event-sourced architecture to full CQRS, and so on. A lot of very skilled engineers found their niche in navigating these hard, technical projects.

But like I said, those times are gone. Tech companies now have to make money. Hiring has slowed down dramatically, and companies are tightening their belts. A lot of pure engineers have had a rough time navigating this transition. From their perspective, work has all of a sudden become much more political. But what’s really happened is that their previous role — which was effectively a covert developer marketing position — isn’t being funded in the current market.

Remember how browser implementations of protocols always tend to prefer to show the user something and guess the intention rather than showing an error because if they would be stringent and strict they risk that users would switch to another browsers that is not.

This impacts how the rest of the world gets to deal with HTTP, as users then come to expect that what works with the browsers should surely also work with non-browsers and their HTTP implementations.

This makes interpreting and understanding the spec secondary compared to just following what the major browsers have decided to do in particular circumstances. They may even change their stances over time and they may at times contradict explicit guidance in the specs.

The whole spec was subsequently rearranged and reorganized again to better cater for the new HTTP versions, and the latest update was published in June 2022. The HTTP/1.1 parts had then been compacted into three documents RFC 9110 to RFC9112, with a total of 95,740 words.

For the argument sake, let’s say we can read two hundred words per minute when plowing this. It is probably a little slower than average reading speed, but I imagine we read standard specs a little slower than we read novels for example. Let’s say that 10% of the words are cruft we don’t need to read.

If we read only the three latest HTTP/1.1 related RFC documents non-stop, it would still take more than seven hours.

We already have a phrase for code that nobody understands: legacy code.

Legacy code is universally despised, and for good reason. But why? You have the code, right? Can’t you figure it out from there?

Wrong. Code that nobody understands is tech debt. It takes a lot of time to understand unfamiliar code enough to debug it, let alone introduce new features without also introducing bugs.