Hacker News Reader

In my experience, software architectural failure is endemic across multiple organizations and not an epidemic. The subtle difference is that many companies lack the discipline or the desire to vet new technologies or to review existing technologies to ensure that they still fulfill the needs of the organization.

A hospital, for example, isn’t going to just up and all their preop procedures just because a doctor went to a conference and learned about some new technique.

The software world suffers many organizational failures in this regard, which is why I say it’s an endemic problem. I’ve been in both kinds of shops, the kind where tech was scored according to its ability to fit an organizational need, and the kind where developers recode the whole front end in the “js flavor of the year” because it seemed cool.

There are for sure engineers just as much as there are developers. Engineers are the stewards that don’t implement a product because “web scale”. They implement because they understand the problems of the organization they’re in. We have to learn better to spot this shit and shit it down. I follow one rule right now that stops most of it in its tracks.

If a developer tells you they want X technology because it can process 1.2 jiggahertz requests per second, they have no idea what problem it solves, unless your organization is facing performance issues.

A good developer on the verge of becoming engineer grade will tell you that they want X technology because trying to perform Y process is painful and unmaintable in the current system, and that if we implement with X, it’ll reduce labor spent on this problem and deliver Z value to the company.

Architecture isn’t failing, the folks with the hammers aren’t following the blueprints correctly.

A good developer will show how that implementing it in X will lead to the gains described, absolutely. The problem is much of the time "implement with X" doesn't actually lead to those gains, but there's some cargo culting or other parrot-a-blog-post justification for it.

I think sometimes developers just have trouble conceptualizing ‘performance tiers’ at the low to mid end.

One example is thinking that horizontal scalability of the persistence layer is necessary before you get to even perhaps Series C/D scale. For instance, I had a serious epiphany when I read that Braintree managed to vertically scale a two node (“HA”) Postgres setup to transaction volume in the millions and a massive valuation. Stack Overflow has had a similarly lean footprint for much of its history.

Most developers usually need to focus a lot more on the 20x more relevant task of product engineering. Unfortunately, a product focus usually means pretty boring or repetitive coding work that doesn’t widen your skillset as an engineer. These competing incentives are how complexity gets introduced, how more code than necessary gets written, and how poor/premature technology choices are made.

The right attitude to have in a small to medium size tech company (and particularly one that doesn’t have product-market fit) is that every LoC introduces marginal risk, every additional package is another dependency that needs to be grokked (so it better be delivering serious ROI), agility is paramount, and innovation should only be happening where it’s necessary to deliver on the company’s unique selling point.

But the most important thing is agility; and moving fast (contrary to what the industry generally believes imo) is less a function of rockstar talent than of simply making the right choices, having the right processes, and persistently reexamining and refining things to go even faster. It’s just a completely different mindset from the norm at a large tech company. At a really early stage, you might even be better off hiring a prodigious hackathon talent than your average Google engineer.

Some are engineers. But when you don't flit like a magpie to the new shiny you become a codger or geezer. Managers can't tell the difference, gotta just buzzword pad your resume to get a job.

I dig my heels in when new tech drops these days. Been burned too many times. Want to use it? Prove it works. Qualify it properly.

Conservative engineering builds better quality products and benefits the user the most.

There’s something to be said for balancing conservatism, because there is far to much risk of just becoming an obstacle in the way of making any progress.

I’ve had to deal with a situation recently where they’ve become so conservative that they’re afraid to even consider embr@cing tests, build tools (I.e, use ant/maven/gradle instead of Eclipse as the sanctioned build tool), dependency management (I.e, not just commit jars to source and never document anything), etc.

They guy in charge had been burned too many times, but part of that was his own fault for not providing sufficient oversight and advice to junior devs and frankly I’d say a degree of short sightedness with the general approach.

Wow, that sounds so bad there are multiple compounding problems in that environment.

Nothing like the lead engineer fiddling with the tooling and the tech stack every day and not mentioning it to anyone, to sap productivity. I started to anticipate spending the first couple of hours every day tweaking to my development environment and dependencies to resolve today's mystical crash.

And I felt too junior to say anything. I figured that if the grown-ups want the new shiny, it must be worth something. In actual fact, our real-time, React-Native, ES7-experimental-flag would have been as easily built in php.

I’ve worked in that sort of environment before. Watch out for senior staff obsessively following certain people promoting bandwagons built on lies, conferences and marketing. Next thing you know you hit a wall that’s metres thick and high.

Knee jerk conservatism is as bad as fashion driven development.

If you lack the skills to objectively assess new technology, perhaps technology isn't the field for you.

It's not knee-jerk conservatism. Literally in his comment:

> Prove it works. Qualify it properly.

I'm the same way. I refuse to use whatever's hot tomorrow unless it's been qualified and tested. That's not knee-jerk conservatism, that's just smart product development.

Exactly that.

I have had many bad experiences where unreliable software has fucked production even if it is the current fad and has an arena of consultants and conferences behind it. If you don’t independently test and understand the software and just chuck it in and see what happens, which is how some people think it should be done, then you’re burning your business badly.

Consultants and conferences are a warning sign ..

Technology doesn't magically become qualified and tested by itself, it's something you have to do.

No shit. That's why it's done, and then used in production. That's the whole point.

> "The author is also right about the cause: it's developers always chasing the newest toys."

That's certainly true. But undefined and wishy-washy business needs don't help either. It's easy to look at something finished and think "that's not right, that's not what I would have done."

Sure there's negligence or just poor decisions. But often there are good reasons for wonky architecture, and often those reason have little to do with technology and the people who implemented it.

When throughput is a few GB (< 10) of data per day, most of it coming in a large batch that doesn't have any real time requirements for processing and someone starts blathering about Kafka and Event Sourcing that is not a wishy-washy business need, that's unvarnished resume driven development.

True. I think what I'm implying is there is a co-dependency going on. That is, in light of the lack of a clear (biz needs based) path a given team / individual is going to do what they feel is "right." That decision is going to have a natural bias. If for no other reason, people learn that ultimately the only person looking out for them is them (especially when the business isn't even looking out for itself).