Live data from Hacker News

Why does it take so long to build software? (2020)

simplethread.com

61–70 of 180 posts

Re: Why does it take so long to build software? (2020)

#61
post #29

Earlier quoted context omitted.

Why is that? It's because we don't learn from the past and keep thinking we're the smartest and have to reinvent everything with every new generation of developers. I've worked at a company where elasticseatch, postgres, message queues, custom microservice platforms, custom cicd platforms were deployed for a load that could fit in ram of one machine. With maybe 10 customers per minute. And you're wrong about accounti…

Its important to distinguish b/w anecdotal experience and industry trends. A lot of great tech was invented to solve very real problems that groups of people faced. Once it gets hyped though, everyone wants it in their stack because they've read about it in blog posts or want to give a conference talk about or . Elasticsearch, postgres, message queues etc. all were invented by people when they faced real problems. As…

A lot of new tools were indeed invented to solve real problems, albeit not necessarily real problems shared by as many people as subsequently adopt those tools.

But there is also a huge amount of reinvention because, as mstipetic was saying, a lot of developers just don't study their subject any more. It's so superficial, rarely learning lessons from history.

In particular, that's how we get the modern world of web development, with new tools and frameworks every few months that do require retraining but don't contribute many new ideas. This is an industry where the dominant programming language for the front end literally had no standard concept of modules until relatively recently. To this day, almost all of the main tools like building, testing and static analysis usually have at least one extra layer of transpilation complexity on top, and usually it has to be configured separately for each tool. The tools themselves are often relatively basic, with routine (in the rest of the programming world) optimisations like tree shaking regarded as some sort of incredible advance. The same goes for the software architecture patterns used by the big front-end libraries and frameworks. And setting all of this up has become so complicated that there are now tools to scaffold the project and set up the other tools that orchestrate the other tools, which I really wish was a joke but is literally true.

Unfortunately, I think the real root cause of the rot is money. There is so much cash now in certain parts of the industry that it is undeniably a successful career strategy for developers to go job-hopping and collecting buzzwords working at those places, even if they are never really learning much of substance or building much of actual, lasting value. It turns out that huge numbers of people are willing to pay, directly or indirectly, for junk. And so writing junk and not caring is an effective business model.

The silver lining is that it's a huge industry and there is still room for quality as well, so those who do make the effort to build better software can at least make a living doing it, even if the rewards are more in satisfaction than greater financial compensation.

Re: Why does it take so long to build software? (2020)

#62

Software takes a long time to build because it's always new. That is, software is trivially copy-able, so there is no reason to spend effort duplicating any software that already exists. (Legal reasons and "not-invented-here" syndrome notwithstanding.) This is a huge different from how the "real" world works, where almost all of the work involved in building, say, a car, is actually just the work of assembling identi…

If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does.

The conclusion is that the tools to build software from a known specification to working code are sub-optimal.

Re: Why does it take so long to build software? (2020)

#63
post #20

One aspect that is not mentioned is that we build software on top of an ever-increasing number of first-to-market, low-quality, building blocks. And by low-quality I mean "worse is better"/MVP/"everyone makes mistakes"/"leaky abstractions"/etc -- pick your favorite. As a result, we spend more and more time dealing with someone else's mistakes rather than making forward progress.

Totally agree. Move fast and break things? Let’s not. Let’s build carefully and methodically. Teach others how to build quality software. Stop regurgitating what you watch on YouTube 4 hour course. I’ve seen horrific, I mean absolutely bottom of the barrel code being taught to others. Especially in JS community - yes, I’m picking at you guys again. When teaching goes to shit, you’re breeding and propagating, institut…

Move fast and break things itself doesn't imply you shouldn't go back to patch it up and make it cleaner. People should be moving fast so they don't end up in endless discussions regarding or spend too much time on creating a foundation for a solution that doesn't work, and to inhibit perfectionism. People should also be transitioning from "make it work" to "make it good" once it works, prior to delivering or finalizing it.

This is largely a problem with people unable to shift practice according to the context, lazy developers and managers thinking "it works" means "ship it and never look back". Unfortunately, there is no cure perfect cure for lack of foresight and willingness to listen to the guy saying PoC code will cause problems at some point down the line.

Re: Why does it take so long to build software? (2020)

#64
post #39

Because we don't dare making bold decisions like: * Throw out all MySQL/MariaDB installations and replaced them with PostgreSQL because it is objectively, provably better. * Stop writing build-systems in untyped languages, because they are less productive when used by a team.

Why is MariaDB worse than PG? Maria has temporal tables which I make great use of

Re: Why does it take so long to build software? (2020)

#65

Software takes a long time to build because it's always new. That is, software is trivially copy-able, so there is no reason to spend effort duplicating any software that already exists. (Legal reasons and "not-invented-here" syndrome notwithstanding.) This is a huge different from how the "real" world works, where almost all of the work involved in building, say, a car, is actually just the work of assembling identi…

If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.

That's like saying a Ford F150 is functionally identical to a Ford Model A because they are both cars. The specific implementation under the hood requires a lot of work. And very rarely do people ever make functionally identical clones without massive refactoring to allow for extensibility.

Re: Why does it take so long to build software? (2020)

#66
post #20

One aspect that is not mentioned is that we build software on top of an ever-increasing number of first-to-market, low-quality, building blocks. And by low-quality I mean "worse is better"/MVP/"everyone makes mistakes"/"leaky abstractions"/etc -- pick your favorite. As a result, we spend more and more time dealing with someone else's mistakes rather than making forward progress.

Totally agree. Move fast and break things? Let’s not. Let’s build carefully and methodically. Teach others how to build quality software. Stop regurgitating what you watch on YouTube 4 hour course. I’ve seen horrific, I mean absolutely bottom of the barrel code being taught to others. Especially in JS community - yes, I’m picking at you guys again. When teaching goes to shit, you’re breeding and propagating, institut…

> Study what Unix did when they were building small composable highly quality building blocks. Still used today after 45 years!

Don't worry, systemd has integrated building blocks that can replace all that. Those pesky reusable, composable modules won't hit their 50th birthday.

Re: Why does it take so long to build software? (2020)

#67

Software takes a long time to build because it's always new. That is, software is trivially copy-able, so there is no reason to spend effort duplicating any software that already exists. (Legal reasons and "not-invented-here" syndrome notwithstanding.) This is a huge different from how the "real" world works, where almost all of the work involved in building, say, a car, is actually just the work of assembling identi…

If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.

> The conclusion is that the tools to build software from a known specification to working code are sub-optimal.

That may be true, but I don't know that your example supports it.

Cloning an app doesn't mean you had a specification for the app. The tools to build a known specification from an existing app are sub-optimal, as are the tools to build a known specification from scratch.

I've only rarely in my career had the benefit of a written specification.

Re: Why does it take so long to build software? (2020)

#68

Earlier quoted context omitted.

I agree, feels like we've conditioned to accept software playing dumb and being unreliable. A couple decades ago, random glitches attracted much scrutiny, today we just take it for granted.

Is that really true? I remember routine blue screens and system hard-crashes a couple decades ago. They're not commonplace today. We're primed to remember the past rosily.

It's true that there are rose-tinted spectacles at work here, but I don't think modern software is as great as all that.

Today's version of a blue screen might be something in us-east-1 being down again and taking half the software on the Internet offline with it, but the effect is much the same, and now you can't necessarily do anything about the outage, you just have to wait until whoever is responsible for the failed infrastructure to decide your problem is important enough to fix next.

It's not just cloud, either. I recently had a combination of two popular pieces of software, both widely used by professional programmers, where a plugin was crashing the host application when even basic functionality was triggered. The problem was sufficient that I had to abandon using them and ended up writing that program in a different programming language because it was faster than messing around with broken tools. It turns out that some of these much-touted modern standards for interoperability and portability aren't all that great after all.

And of course, while we don't get a literal blue screen any more, it's not as if Windows 10 and several other popular operating systems don't frequently break users' devices, sometimes catastrophically, when rolling out updates. We've just come to expect (by which I really mean, been forced to accept) this culture of shoving broken stuff out and fixing it later, even in the most essential software like our operating systems.

Meanwhile, the last time I saw significant instability on any desktop OS prior to quite recently, I think I was running Windows 95. So maybe the spectacles aren't that rose-tinted after all.

Re: Why does it take so long to build software? (2020)

#69
My take is that programming languages have an inadequate ratio between abstract and concrete data flows.

You are supposed to build code by stitching together commands for all the data handling functions required to handle each case in the data. Yet development environments make it really hard to actually _see_ what effect the functions are having on the data. You need to enter a special debug mode and place strategic breakpoints, logs and watched expressions, instead of making easy to compare the full program state before and after executing each function.

In that respect, spreadsheets and reactive functional languages make it easier to prototype new software fast, since they have close together both functions and the data on which the functions operate; and in spreadsheets, you also get the intermediate steps for chains of functions.

Post reply on HN