Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

simplethread.com

Post reply on HN
Print view View original

41–50 of 180 posts

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

#41

Post by cccc4all »

It takes long time to build anything of value, software is no different.

There are many variables in building software, which roughly break down to budget, resources and time. All these variables must be managed carefully to deliver software of quality and value. There are several strategies that mitigate the process of building software and manage tradeoffs between budget, resources and time.

There's no one size fits all solution that can reduce time without accounting for budget and resources.

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

#42

Post by fxtentacle »

marklit wrote: post #32

Aren't most developers in the world paid a salary or day rate and thus are paid for their time? What incentive is there for them to "hurry up" rather than sandbag?

Plus they usually get no financial compensation for the extra work of making things work well.

There's a minimum quality level required to not get fired, and I wouldn't be surprised if that's exactly what most employees deliver.

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

#43

Post by forgotmypw17 »

fxtentacle wrote: post #31
boris wrote: 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.

Fully agree. At first I was inclined to comment "it doesn't" because I can easily build small but useful tools in a matter of days. But your comment made me realize that maybe the reason is just that I keep using the same old C++ libraries to avoid surprises. In my last Ruby project, critical APIs changed multiple times during development. But Boost / openssl / curl / TBB / MKL are surprisingly API stable, given how…

I'm a high-level guy, and I avoid using anything under 20 years in existence.

All the easy problems are already solved and well-documented, and less likely to break my code with a new release.

I then try to write code in such a way that it would have worked 15 years ago and today both, working around platform changes.

My current stack is Perl, HTML, CSS, SSI, PHP, SQLite, PGP, txt, and JavaScript.

And yes, my sites do work in Netscape 2.0+, IE 3.0+, Lynx, Links, w3m, and with a few settings tweaks, also Mosaic.

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

#44

Post by fxtentacle »

ohadron wrote: post #36
marklit wrote: post #32

Aren't most developers in the world paid a salary or day rate and thus are paid for their time? What incentive is there for them to "hurry up" rather than sandbag?

I want to say stock options, but I don’t really think it achieves this goal.

I concur.

Stocks are too far away from the actual software. The CEOs stupid pet project might well ruin the company's financials, even though all of the engineers on the core team did a fantastic and highly profitable job.

So stocks are more bets on the CEOs performance than on the engineers'.

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

#45

Post by MangoCoffee »

fn1 wrote: 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.

>Throw out all MySQL/MariaDB

that's reaching. there are many successful software build on top of mysql/mariadb.

>replaced them with PostgreSQL because it is objectively, provably better

"provably better"? that's not reasonable enough.

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

#46

Post by laurent92 »

joubert wrote: post #13
jbverschoor wrote: post #12

Fun fact.. it doesn’t! Some of the most widely used software has been created in a few weeks or days.

Have they released subsequent versions?

Git: 2 weeks by Linus Torvarlds,

Javascript: 10 days (Brendan Eich?? not sure)

Both have had iterations. Git, because the original command line was awful. JS had to be reimplemented with its weirdities, because websites were already relying on them (and this is why we get the WAT demo: https://www.destroyallsoftware.com/talks/wat )

I’d day, in 10 days, what you build is an excellent architecture for a project used across the world for half a century. But just the architecture. The features come later. Perhaps it’s limited to 10 days because that is the span of medium-term memory and it matches the maximum number of concepts in the human mind?

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

#47

Post by errantmind »

godot wrote: post #34

On a somewhat separate topic and line of thinking than the post (Great article btw, I agree with it completely) -- I've often thought that, as a software engineer, whenever giving estimates, any number of management folks must be thinking "why does it take so long?". And I think part of the reasons is this. If you simply _ignore_ most of the accidental complexity, you often can build 80% of the functionality of a req…

It sounds like the kid in your example built an MVP product for the executive to demonstrate/test business value. Expectations matter. If the executive thought that was a finished product and is holding everyone to that standard, they were mistaken. I don't see any reason to write extensive unit tests, a component-based frontend, responsive layout, and scalable architecture for the first draft of a product. In my opinion, the first draft of a product in a business environment should test business value of the idea as rapidly as possible, as many of the ideas are half-baked

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

#48

Post by forgotmypw17 »

Silhouette wrote: post #40

We are asking more and more of our software. Are we, though? This assumption merits deeper scrutiny. It's obviously true sometimes, but does it really generalise? In terms of functional requirements, we use lots of online software today that is far simpler than its traditional desktop equivalents in feature set. Many successful SaaS businesses are providing tools to help businesses organise that are often barely more…

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.

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

#49

Post by ncallaway »

badsectoracula wrote: post #33
RandallBrown wrote: post #27

Earlier quoted context omitted.

Did Ami Pro let dozens of users around the world edit the same document at the same time? Some of them being on cell phones? Did it automatically store your document somewhere that can be accessed from any computer with internet access? Seems to me like we really do have more features.

I think a problem here might be that those aren't exactly "Ami Pro" (or word processor in general) features, they're just tacked on the word processor even though it has nothing to do with word processing (even the multiple editors at the same time is essentially about having multiple views - not too different than opening two MDI windows in Office 97 or whatever with the same document but different positions - that…

Sounds like a No True Scotsman argument for what counts as word processing features.

I know plenty of scenarios where collaborative document editing is a killer feature as part of writing a document.

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

#50

Post by Silhouette »

fxtentacle wrote: post #35

"the last 20 years has been the drastic reduction in the ratio of essential to accidental complexity" I know this is nitpicking, but the author is using mathematics as an example and then uses ratio the wrong way... The point he/she is trying to make is that tools got better. That would mean the accidental complexity goes down. That means the ratio of essential to accidental complexity goes up.

I wondered about that as well, because much of the content in the middle of the article, where the author lists changes in the industry such as automated infrastructure and frequent deployments, would suggest to me that accidental complexity really has increased and the author's statement is actually correct as written even if that wasn't the intent.
Post reply on HN