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

151–160 of 180 posts

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

#151

Post by mewpmewp2 »

systemvoltage wrote: post #53
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.

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…

It really depends on the situation. Some stuff you won't need one month into future, other stuff you'll need for decades. Manage your efforts wisely. Time after all is limited.

Many companies wouldn't have existed if they didn't move fast and tried to perfect everything instead of prioritising getting to market.

Don't put the same level of care into the weekend side web app you are creating for fun as to the rocket ship you are building.

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

#152

Post by HPsquared »

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…

Git was "born" in a weekend, but the overall gestation would have taken much longer.

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

#153

Post by Justsignedup »

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…

To note. All engineering has this problem.

Yes, building cars in a factory yields repetitive results, but what about all the different engineering projects. The truth is that this is not a new problem, we just lack discipline of fields that have been refined over thousands of years.

Because of the quick idea to prototype rate, product research and refinement takes a back seat. All engineering projects have massive research before the first stone is placed. Nobody mid way through building a sky scraper decides "oh, do we need to redo the foundation?"

I would also like to note, nobody is gonna give a self-taught architect who's 19 the ability to build that skyscraper foundation. Each building technique is developed, tested, and then once determined good, is actually used by others, and supervised by an industry veteran with underlings who learn and eventually themselves supervise such projects. Meanwhile in software it is the opposite.

Not to say that there isn't a reason software grows so fast. Things change daily. If software worked like architecture we'd be licensing even the right to use ruby on rails-style modeling. But software works differently, thus faster iteration, thus more loosey-goosey, thus harder to estimate.

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

#154

Post by berkes »

kaba0 wrote: post #72
ardit33 wrote: post #18

Earlier quoted context omitted.

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

But experience with one language tranfers quite well to a new one. I also see a deep problem from the business side, that a programmer is easily replaceable ot that just by throwing more (mediocre) people at the problem will help solve it faster, or even the existence of rock-star developers. Building software is slow, because essential complexity. We are writing programs that no one person can hold in their heads. A…

Experience with languages transfers well, because programming is 80% "architecture" and 20% language (or framework or stack). (numbers made up).

The latter is a fast moving field. The first requires deep knowledge, and experience.

When you build an application with the latest javascript framework, vue-native, or ncurses, there is far more than learning ECMA2020, MVC or that ncurses-rust-binding-lib.

It requires you to study and understand the domain. Translate that into a domain model. Finetune that. Search for patterns and frameworks that fit this model. Develop the software in a way that it can be maintained, react to market demands and so on. These are skills that transcend languages or frameworks. That you can apply to both the latest kubernetes-docker-cluster and to the server in the closet. That you can apply to ncurses or vue-native.

You'll need to learn when, but mostly why, Rails becomes a PIAS for certain jobs, but also when or why ASP.net or Spring is not magically going to solve the problems you have with Rails. ASP.net or Spring probably don't translate well to, say Rails, wrt syntax or features. But the deeper knowledge, about how to model your OOP translates just fine. Or when all of those tools are going to be a PIAS because the domain is ill-fitted for OOP or MVC and needs something else.

And knowing React and Redux is neat (untill react is replaced by vue?) the knowledge it teaches you about functional state patterns will help you in your next elixir or even Rust project. Or vice-versa: a dev who only ever worked on your typical MVC CRUD-app, will probably have a hard time grokking Redux, whereas someone withour any JS experience but knowledge and experience in events, CQRS, or functional programming can pick it up in days: all they'll need to learn is the quircks of javascript (undefined-is-not-a-function).

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

#155

Post by mewpmewp2 »

forgotmypw17 wrote: post #109
giantDinosaur wrote: post #106

Earlier quoted context omitted.

I refuse to write anything that supports any IE version < 11 on principle. And I will relish the day I can kill support for IE11, which is hopefully rapidly approaching. I admit I do enjoy a stack which includes text files, though.

It seems to me like that stance does nothing helpful, only lets the developer off the hook of attempting something difficult and annoying. At the same time, it leaves human users who can't change their browser high and dry.

It is a business decision. Deliver a feature faster to 99.9 percent people as opposed to later for 100 percent. Neither is right in all scenarios which makes the whole argument pointless without specific scenario. There's a slider you can move with support percentage and time efforts required to make it happen. It is about balancing trade offs. Taking one fixed stance will just make you inflexible.

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

#156

Post by beckingz »

mewpmewp2 wrote: post #151
systemvoltage wrote: post #53

Earlier quoted context omitted.

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…

It really depends on the situation. Some stuff you won't need one month into future, other stuff you'll need for decades. Manage your efforts wisely. Time after all is limited. Many companies wouldn't have existed if they didn't move fast and tried to perfect everything instead of prioritising getting to market. Don't put the same level of care into the weekend side web app you are creating for fun as to the rocket s…

The trouble is knowing how long your code will work.

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

#157

Post by HPsquared »

pm90 wrote: post #14
loteck wrote: post #10

Earlier quoted context omitted.

I guess the main thing is that there is basically infinite demand for more things in software. Law is very similar to software in this way. They both also take a long time to write & are never actually "finished."

This is an interesting analogy. However, I would argue that Law is less constrained by the laws of nature. If a program is broken, even the best programmer in the world may not be able to fix it if they can't diagnose the underlying problem. Whereas in law; there is no such problem. If a law is found to be bad, you change it. Most reasonably competent lawyers could come up with a solution. Not to say that creativity…

Law is constrained by human nature.

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

#158

Post by beckingz »

p0nce wrote: post #128

Writing software is basically going in debt, so you should write the 20% of software that will deliver 80% of the value. The problem begins when not considering costs and then being "surprised".

Manager: "All those 'nice to have' things are too expensive. Let's cut them"

Manager, 3 months later: "Why are there no nice things in the software!"

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

#159

Post by peterohler »

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 think you are using the wrong building blocks. Build your own blocks or use ones that are solid with good test coverage and many of those issues go away.

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

#160

Post by peterohler »

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…

While using git as an example is a bit over simplifying I agree with the comment. Over time, if you plan ahead, your build up a set of building blocks and at some point you can put together an application very quickly. I suppose it is all relative though. While a month might seem fast to me someone else might expect a solid, fully featured application in a day or a weekend.
Post reply on HN