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

141–150 of 180 posts

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

#141

Post by TeMPOraL »

Leherenn wrote: post #136
TeMPOraL wrote: post #99

Earlier quoted context omitted.

I think focusing on this comparison to the real world assemblies and constructions doesn't yield much insight. The equivalent of a car being assembled is a compiler building an executable from source. You can consider factories to be just very, very long compiles, and forget about it. The question of why software takes a long time to build pertains to the coding phase, to which real life's analogue is drafting/design…

> for physical products, drafting/design is nearly free (capex & opex of the assembly phase dominates) It really depends on the industry. It's particularly bad in heavily regulated industries (pharma, aerospace, ...). On the other hand, creating a blog is probably the equivalent of designing a new t-shirt.

Fair enough. I haven't considered regulatory impact. On top of that, I wasn't thinking about pharma, or a lot of formulated products.

That said, setting aside the regulatory burden, from the little insight into the internals of chemical processing I had, there may be larger costs in designing and tuning the "build pipeline" (all the coolers, valves, reactors, etc.) than in designing the formula itself. That's just a consequence of scaling up being expensive where your production involves manipulating matter.

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

#142

Post by dgb23 »

lisper wrote: post #28
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.

I dunno, there's a lot of really high quality stable software out there. It's not all crap. But as someone who has had the luxury of taking time to do things the Right Way let me tell you from firsthand experience: doing things the Right Way is incredibly hard in no small measure because figuring out what you actually want to do is incredibly hard. There have been many times when I thought I was building something fo…

> The process of meeting human needs is messy because both human needs and the tools we have at our disposal are a constantly moving target.

Software development is inherently explorative. Finding the right solutions is exactly that: finding, discovery, learning and play. IMO This is best enabled by fast feedback loops and highly dynamic, interactive systems and visualization.

Sometimes it is possible/feasible to parametrize a tool beyond what it is supposed to be doing to enable this kind of play and discovery, but also to make the process of building data, plumbing and so on just a bit more efficient and fun.

Game programmers get that: At some point while developing a game, they create the tools that produce the data, or the parameters, typically controlled with a visual interface, a configuration language or a scripting language. Level editors, state machines, behavior trees, story boards, flow scripting etc.

Another field that does this well is scientific computing, they use Jupiter Notebooks etc. with integrated REPLs and graph visualization.

The whole "no-code" and "low-code" trend[0] also shows that people are willing to program with constrained, visual languages. It empowers them and connects their mental model more directly to a product (instead of having to go all the way through a team of implementers for every change that could be exposed as data).

[0] I personnally don't like the terms "no-code" and "low-code" at all, because they describe what it is not, instead of what it is: visual programming. It's like "no-sql": Could be anything from a configuration file, to a document db, to a key-value store or a ACID graph db.

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

#143

Post by fuzzfactor »

jillesvangurp wrote: post #73

A lot of accidental complexity arises from adding more people to the mix. There is the communication overhead to deal with. Even when things go well this consumes time. When it doesn't: more time. Then there's of course the constant arguing and bickering over what is best; more people means more opinions on this. And of course the more people you have the more complexity gets introduced. Conway's law is a thing. The…

When you throw as many coders on to a project as anybody has ever done, in order to rush to the goal with maximum urgency, those man-months really add up fast and it does end up taking longer in the end because of it but look how many people got to the goal and it wouldn't have been possible without all those executive-months struggling to move the goalposts toward the team as much as possible before everything craters.

If you were committed to efficient progress to reach your original goal you're going to need a different approach.

And start all over again.

Carefully read every word of their comments from the programmer having two decades of single-handed operation, and the 42-year corporate retiree now making single handed progress himself, these are long comments but here's an excerpt:

>This all being said, one of the major causes of complexity in software development, which has always been an impediment to quality productivity is the ridiculous demand for unsuited deadlines in development efforts. This is a result of weak and incompetent management that runs up and out of the technical departments right up to division heads and the like. Deadlines, cause their own deference to the development of complexities, which often include defects. Deadlines cause stress and other factors, which often disallow most developers from thinking out their designs and problems clearly with time to tinker with the best solutions.

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

#144

Post by yen223 »

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.

Did Ami Pro even have fonts?

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

#145

Post by joekrill »

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.

It's not mentioned specifically, but I think this very much falls into the "Accidental complexity" bucket. In the same way he describes someone choosing to use Mathematica for solving a problem - a developer choosing an obscure technology or writing poor code is just more accidental complexity.

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

#146

Post by noisy_boy »

I think it is relative. Compared to developing a car, a wordpress website can be completed in a relatively short time; an ERP system on the other hand will take substantially longer. It depends on what is being asked to be delivered when at what cost.

Putting that aside, there is a time creep factor because people don't place limits on the demands - ask and the developer can do it. So it is developed and now you need to ensure that the custom piece works reliably and doesn't break and so on. Compared to that, a house needs to be carefully designed upfront and there are limits to what modifications you can reasonably ask for down the line - you don't ask the builders to drag and drop the kitchen to the other side because you don't like how it looks on mobile.

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

#147

Post by ozim »

jstimpfle wrote: post #133
tom_walters wrote: post #93

I fundamentally disagree with the conclusions of this article. It doesn't take long to "build software" - git was built in a weekend, Facebook a similar timeline. When the environment is right there's no upper bound on the pace of delivery, it's just that modern day dev is, in many places, less about quality of the output (in terms of product/market fit and user value, not code quality) and more about the satisfactio…

That's an overstatement. You can build impressive MVP and tech demos in a short amount of time, yes. But that requires that the author has already been thinking about the types of problems that come up in this domain for a long long time. Rest assured that Git certainly hasn't been created in a weekend. Also, you can't create a product in this short amount of time. (There are some websites that do almost nothing at a…

I agree, saying Git was created in a weekend is like saying olympic gold medalist in 100m dash won competition in 10 seconds. Linus was working with DVCS software already and was annoyed with it so he had an idea on how to do it, he did not came up with it on Saturday like it never existed and coded it on Sunday.

Other part about Facebook - well if you take first version that was just well photos + some description and disregard all stuff that was refined next years where it started to be real product instead of novelty page for Harvard students.

In a company I work for we built first version of application in 1-2 years to catch up with what other companies already had and what customers expected. We could do really simplistic version in a weekend but no one would pay for it.

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

#148

Post by HeyLaughingBoy »

TeMPOraL wrote: post #99
caseyross wrote: post #58

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…

I think focusing on this comparison to the real world assemblies and constructions doesn't yield much insight. The equivalent of a car being assembled is a compiler building an executable from source. You can consider factories to be just very, very long compiles, and forget about it. The question of why software takes a long time to build pertains to the coding phase, to which real life's analogue is drafting/design…

I agree. Software is "always new" but it often shouldn't be.

I work for an engineering services firm that does mostly embedded systems. I push hard for reuse, basing our work on standard platforms, etc. Unfortunately, client needs vary so much -- one client might need a wearable, another wants a large system that is mounted on a skid, another needs something to sit on a desktop, all with hugely different feature sets -- that it's difficult to find a small set of devices that we can reuse. So one of our big problems is that we're very often bidding on a project that uses a device, or a technology we've never seen before and that's where the uncertainty comes in.

Patterns certainly help, higher-level languages would definitely help (I'm the only one in the organization programming small processors in C++, everyone else is only comfortable with C), but that's a slow, risky change.

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

#149

Post by pm90 »

mstipetic wrote: post #54
pm90 wrote: post #29

Earlier quoted context omitted.

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…

You're just proving my point. As a profession we base our decisions on blog posts and potential fun. I'm all for these technologies, I'm against the fact that regularly as a profession we order multi million dollar digging equipment to dig a small hole. I've literally seen a bored group of devops start building their own cicd solution and give up after a few months of (highly paid) work Not to mention that all these…

It’s becoming pretty clear that you’ve never seen the power of these tools in action.

I don’t think I proved your point at all. I very explicitly showed the opposite.

I’ve worked at companies that ingest petabytes of data, processing it would just not be possible without hadoop and sister tech (chiefly hdfs). Hundreds of developers working on a common codebase that would not have been possible without modern ci/cd solutions. Data pipelines whose reliability would be 0 without a modern rpc system like thrift to ensure system interfaces are well defined and consistent.

There are very real and practical use cases for these technologies. Just because you haven’t experienced them doesn’t mean that they’re overkill. Just because enterprise engineers like to overengineer using these tools does not mean that everyone does. There are very real scenarios where these tools have helped smaller companies and startups to punch beyond their weight.

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

#150

Post by TheCoelacanth »

ardit33 wrote: post #18
mstipetic wrote: post #16

It's because most software developers add negative value. Most not them aren't investing in learning at all and are just playing around and understanding things on the surface level. I'm fairly certain it takes much more learning and effort to keep up to date as an accountant than a software engineer. I've been getting into elixir and was very sad to realise that a lot of the best practices have been enshrined into t…

"it takes much more learning and effort to keep up to date as an accountant than a software engineer" you are wrong in many levels.... accounting is a field that moves slowly and it is highly regulated Software is still in the wild wild west phase, and it catches and loses trends all the time. We are currently using languages and platforms that didn't exist at all 10-12 years ago, yet, in 10 years whatever you are do…

Accounting is highly regulated, but the regulations change basically every year and the penalties for not following them can be very severe.
Post reply on HN