Hacker News Reader

Comment by hirako2000 | Hacker News Reader

hirako2000

Most proof of concepts I've seen get traction turned into production.

A rewrite?

I recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened.

The article touches on responsability, accountability. There is none for risk taker. By definition. You have a crazy idea, you rush it out, you hope clients bite. You profit. It's not even your problem how to make it work, scale, not cost more to run than we sell it for.

The loop on the right. There are companies, two of them are very popular these days, they took it to an extreme. You ship something fast, and since it only scales linearly you go raise money. Successful companies, countless users, some of them even pay. Who's to blame? The senior developer, or simply someone reasonable who asks, how's that sustainable, what's the way out of this? Those are fired, so whoever's left is a believer.

View on HN

This is why you need sufficiently senior engineering leadership (both IC leadership and management). If you have engineers who meekly do whatever a non-technical stakeholder asks then you have a vacuum of responsibility, and sooner or later things will blow up catastrophically and whoever was least adept at CYA will get blamed.

On the other hand, almost any business problem can be solved in a reasonable way that doesn't send your system through any terrible one-way doors if you zoom out enough and ask enough whys. Of course not every place allows engineering to do that, but the ones that don't aren't able to retain senior folks because they will just go somewhere where their judgment is valued. Sometimes technical debt is the right thing for the business, but sufficiently senior engineers can set things up so there is always a way out. But what you can't do is uphold the purity of the system above the business problem. The systems are paid for by the business, so if you lose sight of that then you've lost the plot and the basis for your influence.

Yea, I think even a lot of decent devs are afraid to just say "no" to things. They don't even bargain to find a balanced solution that can be reasonably done in terms of architecture and time to production.

> recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened.

Old quote: "There is nothing so permanents as a temporary hack."

https://thecodelesscode.com/case/234

This problem definitely predates AI coding agents, though it may be exacerbated by them. The article essentially concludes with the ancient advice of "plan to throw one away". Well sure, I also read Mythical Man Month, but how do I convince the decision-makers?

I think AI makes writing second (or third, or fourth) implementation way easier. So it may actually happen more often with the AI.

At this point Zig implementation of Bun seems like one written to throw away. And it happened only thanks to AI.

I guess it's company culture? I had a job and we initially had quick solutions that went messy. We set a hard policy that every "quick and dirty" feature will have a follow up story that gets pulled into the following 1-2 sprints. Often it turned out that the feature didn't live up to expectations and we just disabled or deleted it, the other times we reviewed it and refactored it properly.

We were highly autonomous team though and hardly had cadence complains. But mostly because the all other departments were lagging. Except marketing, marketing always has "ideas".

After my first proof of concept went into production by surprise, I stopped building proof of concepts and started building MVPs.

That's not to say that my first pass that I show people is ready to go into production, but I build the PoC from the beginning with the idea that it _is_ going into production and make sure I have a plan to get to production with it while I am working on it.

I recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened.

Why would you do that though? If you have a working 'prototype' that's handling the demand, has the required features, and doesn't really need to be rebuilt (except to appease the sensibilities of the developers), why would you spend time and effort on that? That makes no sense. The fact it's a prototype or a 'proof of concept' is essentially irrelevant if you can't enumerate what the actual problem with it is.

I work with a bunch of teams that complain that they're mired in tech debt all the time, and complain that it's a huge risk and it slows them down. Except I can see our incidents log and there aren't many incidents and none that can be attributed to running risky code in prod, I have our risk register that has no 'this code is old and rubbish and has past-EOL dependencies on it', and no team has ever managed to articulate how or even how much the tech debt slows them down. They shouldn't really claim to be surprised that no one wants them to spend time 'fixing' a problem that apparently has no impact.

I've also seen the opposite case where a team spent months refactoring an app that they wrote before it launches. They wrote it, then decided they could make it 'better', and spent loads of time reworking most of it before it launched. All the value was delayed because they decided they didn't like their own work. And obviously the leadership team were pissed off about that, and now there's very little trust left.

There should be a good conversation about delivery of work between teams and stakeholders or no one will be happy, but if that isn't happening the stakeholders will always win.

Because the goal isn't "keep this exact version of the app alive and running". The prototype is never the whole application. If your only metric is incidents, then yeah, don't ever touch the code again.

You can get a few feet closer to the moon by building a treehouse, but you still can't turn it into a spaceship.

The prototype is never the whole application.

In a world where people (stakeholders, Product, and dev teams alike) want the prototype to be the full set of MVP features, this is not true.

Regarding the viability of rewrites of successful PoCs: Does the current environment change the math? How difficult would it be to overcome the inertia/hesitation/perception of slow, painful projects that may no longer be so?

Thats why you gotta write them in a language nobody else on the team has heard of.

A mention of a “rewrite” triggered. Whoever does rewrites is effectively out of ideas on what to do next. This is an opportunity cost and the team/company chooses what is more important and the rewrite is never at the top. So even promising or expecting such a thing is silly.

IMO it is a bit arrogant to assume it is more important to engineer a better version of a thing rather than make money quicker and cut corners. In essence it is better to have a problem which is about how to scale a new product because it got traction rather than solve a problem how to sell more copies of already scalable thing.

They said a Proof of Concept goes to prod. That’s not “rewrite the whole service that’s been built for months”. That’s “I vomitted a neat thing over the weekend” -> now it’s in prod.

Hackathon and overnight oncall fixes ABSOLUTELY should be rewritten or production-hardened, but they very often are not.

I do "rewrites" for my day job all day every day; with as of late the goal being rewriting critical services to get past scaling plateaus.

Rewrites require an existential-level threat to pursue and should never be taken lightly. They must solve a real verifiable need, backed by real world data. Rewrites for rewrites sake or some lofty or nebulous goal of "better" or "more maintainable" code are doomed to fail and a waste resources.

I've seen the worst of it, from your average monoliths with no separation of concerns to 1000s of lines of self-modifying assembly in dead architectures with no code comments containing critical business logic, etc.

The main rule is to not to bite off more than you can chew, which if I'm being honest you really only learn from fucking up or watching others fuck it up.

Reply on news.ycombinator.com