Hacker News new | ask | show | jobs
by ashdksnndck 18 days ago
Same issue happens in models trained by organizations who aren’t selling tokens. I believe it’s because being parsimonious is simply harder. Achieving the task at hand independently and declaring the job done is easier than building an abstraction and reconciling between every use case.
1 comments

Agreed. I've noticed this happens without fail in any project driven primarily by "tickets" and "sprints". Finishing the immediate task ends up taking precedence over future concerns that cover a wider scope. On the other end of the spectrum it's easy to spend too much time at the beginning humming and hawing about the best, most future proof design, because you just know you're not going to be able to easily fix it later. As is often the case, the right approach is somewhere inbetween, which is partly why it's a hard process to automate. you're constantly making judgement calls.
I have a vaguely-relevant war story.

1998 - Huge business, re-writing some vital piece of the platform in the middle of Y2K. Contract coders are expensive but also the only available people to throw at this.

The architect had mapped out the entire system down to class/method level. They'd produced a huge list of classes and methods that needed to be built. So the company hired a bunch of contract coders to build said classes and methods, including your humble protagonist. We were each given a list of methods to write up - parameters, operation, expected output. We wrote them up, and ticked them off the list. We were not briefed on how they interacted. There were no tests that we could run. There was apparently no-one checking that what we wrote in the method actually matched the spec. This was before git, so version control was extremely rough, and also before JIRA (iirc the list was an Access database).

We all realised very quickly, like the first week, that this entire project was doomed. But we were getting paid a lot of money to do this, so we just did it. It got really boring really quickly. Every day we wrote a bunch of methods, and next day got a list of the next set of methods to write. The lists just kept coming, with no idea how long the master list was, or how the classes interacted with each other, or how the system actually worked, or anything.

I left after a month. The money was good, but the boredom was driving me insane.

I learned later from friends who stayed that the whole project was canned a couple of months later when it became obvious that this was a complete waste of money and would never work.

Whenever I see a project manager staring at JIRA instead of talking to their people or looking at the codebase, I'm reminded of this project. And your comment reminded me of that ;)

Crazy to think that if it was specced out so well, a modern LLM would make short work of the whole thing. The things we used to get paid for!
lolol you're joking right? as a joke it's funny. If you think thats really what it sounds like when a project's design is well-understood... ... ...
Poe's law continues to be a bitch...