Hacker News Reader

Comment by davedx | Hacker News Reader

These are definitely not laws but consequences of bad engineering culture.

I’ve worked on well designed systems that stayed well designed. For example one I remember that was very solid: How? The team had enough support and autonomy from management to:

1) allow us to hire the right people (no secret sauce - just a mix of not too fast growth and a healthy mix of seniors and juniors)

2) not rush new features, and spend enough time on design and tech debt.

It probably helped that the system was a core e-commerce platform. If it descended into chaos it could have had a material negative impact on the top line.

When reading articles like this positing “laws” remember many people live in a bubble and may have only worked in dysfunctional orgs. There are tons of counterfactuals out there when the system and complexity was critical to the business. (And also tons of examples where despite that it still descended into chaos- but that isn’t a law)

View on HN

Mostly agree, although I think "good" engineering culture is so incredibly rare that it feels strange to call it "good" and everything else "bad". It's more like "regular" engineering culture vs "exceptional" culture.

In my experience I think the larger any team gets the more likely the team is to hire "regular" engineers and the quality regresses to the mean. So it's only a small set of specialized teams with unusual luck and control over hiring that can become "exceptional".

> bad engineering culture

If 99% of projects end up in a way that's not a consequence of a bad engineering culture.

It could be argued that the entire software industry lacks the "engineering culture" of other fields.

The amount of bush-league mistakes I see because people truly don't know any better is shocking. But we've gone from a world where you had to very intimately understand the machine to do your job, to one where a six-month crash course of very specific web technology is enough to net six figures. What did we expect?

To call any software monkey an engineer is laughable. Engineers are generally responsible for a system catastrophically failing. In IT it's seen as a natural consequence of progression. It'll take another 3-5 generations before we have the proper body of knowledge to even have an engineering culture.

Even then though I'm not sure it'll ever really improve. Even beyond the human element I feel like the incremental building approach cannot and will not lend itself to ordered systems. Unless we go back to the ecosystem of objects that Kay talked about back in the 80s we'll always create frankenmonsters, and even if we do: we just create another kind of frankenmonster.

Sounds like your company was drowning in money and time.

Do you thing that was a coincidence, or do do you believe in effect and cause?

Don’t really believe in cause and effect there. It’s hard to get to PMF while having high quality code unless you have an abundance of money and time. I don’t even think it’s a good idea to do that.

They were well funded, but it’s not highly unusual to encounter culture like this.

It doesn't sound like you disagree with the thesis of this article as much as you think you do. Your argument basically boils down to "complexity can be controlled if you spend enough time and mental effort on doing so."

Which, I mean, is exactly the point of this article - software complexity is like entropy, it will always increase over time unless energy is spent to keep it low.

Most companies have no economic incentive to spend this energy, therefore most software becomes poorly built over time. It's not because the engineers were bad or because they had bad culture, it's simply because we live in a capitalist world.

Yeah, on reflection I disagree with the premise these are "laws", they're more "tendencies".

I also don't agree complexity is necessarily a moat. Sometimes it drives customers away to simpler, less expensive solutions; it depends where the complexity is as to whether it creates real lock-in or just friction and annoyance.

> Most companies have no economic incentive to spend this energy, therefore most software becomes poorly built over time. It's not because the engineers were bad or because they had bad culture, it's simply because we live in a capitalist world.

My frustration is that there is economic incentive, but it's diffuse and difficult to measure. And in today's culture across a broad swath of contexts, benefits that can't be measured are benefits that aren't valued.

This isn't unique to software development, but it is something that seems to be plaguing American thinking as a whole these days. Public education is extremely valuable, but it's a large cost and increasing numbers of people are skeptical of the benefits. Fixing potholes is expensive but it's surely less than the diffuse cost of fixing flat tires and broken axles. Public transit is expensive but the reduction in traffic and QOL benefits are large and widespread. Money spent on at-risk youth typically pays for itself many times over, but years later and in a difficult-to correlate reduction in policing and prison needs.

More and more we narrow our focus on short-term expenses at our of long-term detriment and it's becoming more and more apparent as a long, slow-moving rot growing from within.

Reply on news.ycombinator.com