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

31–40 of 180 posts

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

#31

Post by fxtentacle »

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 much is changed under the hood.

Maybe conservative languages attract conservative programmers who conserve time by conserving APIs.

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

#33

Post by badsectoracula »

RandallBrown wrote: post #27
js8 wrote: post #8

Earlier quoted context omitted.

But do we actually have more features? I don't think Google Docs has more features than Ami Pro. I think the problem is the modern focus on adding features, without consideration whether and how these compose. Not all features are equal - some can be used as a foundation on which more can be easily built, while some are a detriment to that. Just adding features without architectural consideration leads to - surprisin…

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 happen to have input/output from across the network).

Some of that can be done in an agnostic way by pairing Ami Pro with something like Dropbox. But ultimately for better use (and having applications focus on the stuff they're supposed to be about) the underlying system should allow for such uses - after all one of the original ideas behind Windows was to avoid having every application reinvent its own UI. But we just seem to be stuck around that point in most OSes (Cocoa probably being the exception of an OS framework that provides more than the basics)... if anything we're regressing with every application (on the desktop at least) ignoring the OS GUI and doing its own anyway.

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

#34

Post by godot »

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 requested product/feature in 20% of the time or less. What's more, for any upper management who's worked in the industry long enough, over the past two decades, they've most likely worked with some whiz kid who had done it (I was one myself in my early 20s a decade+ ago) -- so they know it can be done and have witnessed it.

Let's say the requested product is some CRUD web app. At one point in their career, this executive worked in a growing tech startup and on the team was a talented fresh grad. That engineer built a product very similar to that entirely, front and back ends, in two days. 15 years later you're working in a different company as an executive and you're talking about building some CRUD web app just like that. Why is the estimates being given by the dev team 4 weeks with 4 developers?

What wasn't seen and remembered was that the one built in two days by the smart kid had no unit tests (or any kind of tests), didn't cover many edge cases (at least in its first version), a UI with barebones CSS, no responsive layout, no component-based frontend (e.g. React), no scalability concerns, etc. But all the requested functionality is there, it's demo-able, and usable even. A similar product is being requested now, but it needs to be built to withstand today's quality standards, robustness, maintainability, etc. So unit tests are part of the requirements, a component-based frontend is needed for maintainability, you have to handle mobile, etc.

It's pretty much all the same points the author is pointing out about accidental complexity; just kind of showing why someone would ask that question.

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

#35

Post by fxtentacle »

"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.

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

#38

Post by jbverschoor »

tcbasche wrote: post #17
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.

Created, yes. But maintained, built upon, iterated over and improved?

The same can be said about homes, buildings, road. They can take hundreds of years to maintain, build upon, iterate over and improve.

The problem is almost never technical, or "software". Any decent programmer is able to create 90% of the demand.

Domain knowledge, requirements, product management, roadmaps, business tradeoffs is where all the time goes

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

#39

Post by fn1 »

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.

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

#40

Post by Silhouette »

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 complicated in terms of features than the freeware/shareware applications that used to be everywhere, often written by a single person or a small team, running natively on your desktop! It turned out that a lot of the extra complexity in the huge programs we used to run on desktops and corporate servers wasn't offering a good return on investment and the trend has been to simplify over time. That might be an improvement for both developers and users, but it certainly doesn't mean we're asking more of that software.

In terms of non-functional requirements, connectivity is obviously a big change compared to 20 years ago. Today, a simple CRUD app might be running online and the data can be reached from anywhere by anyone, or by multiple anyones at the same time. That could be much more convenient even if the data itself is little different or even simpler than it used to be. And there are very significant overheads in implementing real-time, distributed, concurrently accessible systems compared to old school desktop and database applications, so in this area we certainly are asking a lot more of much modern software.

But beyond that, what else are we asking more of in terms of non-functional requirements? We're setting the bar low on performance for most of the software that gets written today, relying on ever faster and larger hardware to make up for running less efficient code. As anyone who actually wrote serious software on the systems of 20 or 30 years ago can testify, that makes life far easier for programmers and requires much less knowledge and skill. Today, the skill set that resulted in heavily optimised code a few decades ago is mostly found among developers working in fields like embedded systems where resource constraints are still often tight, but otherwise it's another area where we're asking far less of our software than we used to.

I think the article was more on target with its highlighting of essential and accidental complexity. The extra processes and tools and infrastructure add a great deal of extra complexity today, and I am far from convinced that much of that complexity is really justified, particularly when it's attached to such a transient, throwaway culture where little is built to last and developers jump ship every five minutes. It might be very un-PC and/or career-limiting to suggest building software any other way today, though.

Post reply on HN