Hacker News Reader

Comment by YouWhy | Hacker News Reader

The two things we know about the vendor are unforgivable: the fact that they let a core piece of logic depend on indefinitely augmenting a Mongo record, and the fact that a deliberate effort by 3 somewhat above average people could replace them in about 3 months of work.

The fact that the vendor reached the state of doing business with a Fortune 500 client indicates how helpless organizations similar to this client feel facing even modest SW undertakings. Indeed, the project scope in question indicates it could be accomplished by some folks here as a hobby project.

This also explains to me why Retool is so popular with tech leaderships, while not necessarily so with engineers. I wonder what other product approaches could address the same gap.

View on HN

Spreadsheets were the killer app for exactly that kind of problem.

Thanks to spreadsheets any low ranking peon can hack up a barely working, janky prototype of their idea for a tool over a few days, without having to deal with anyone else in the organisation.

Before spreadsheets, you had to convince higher ups to convince the IT department to take on your request. That would take at least three months. Then you'd need to wait another few quarters until they delivered you a barely working, janky implementation that didn't match your requirements written in something like Cobol or C.

And with Google App Scripts, you can augment your Google spreadsheets with JavaScript to write custom functions that can call remote services (and be called back as a service!).

Yes. Though I was talking more about the 1980s, when spreadsheets first became a thing.

That's also why I mentioned Cobol and C, Java hadn't been invented, yet.

I really want a term for the phenomenon whereby billion dollar companies frequently struggle to create the kind of technology three interesting weirdos can write over a weekend.

Misalignment of incentives

red tape. bureaucratic friction. multiple stakeholders coordination.

The problem is not that smart people do not exist in a big org, but that they work in an environment with vastly different constraints which have been established because the scale and goals of the projects are vastly different from those in a small team.

Fred Brooks discussed this in the 70s.

A software system is ~3 times harder than a weekend-garage program, and a software product is ~3 times harder than a software system, so you're at 9 times the work before even starting to go into all the work marketing and selling it and doing the internal overhead work to make sure that the organization is ready to sell and support the new product when it's ready...

Also a billion dollar company has a lot more to loose than a few interesting weirdos working on a weekend project, and so rightly expect more risk management reviews.

I used to work for a regional telecom, at that time I was doing third tier support of applications. A couple devs and a couple support people went out to the users, the devs had been working on a new tool to solve some major problems. The devs had been working on it for 6 months, and this was the first the end users were seeing of it.

Next thing I know we're drive back across state line, dev's tails between their legs. As far as I know, no-one ever spoke of that project again.

It's probably Accenture and if not, something similar. Where they put graduates to do all the work and then charge the hourly for senior devs.

That was the 1995 model.

It's all outsourcing or H1Bs now.

Reply on news.ycombinator.com