Live data from Hacker News

Why Doesn't Software Show Up in Productivity?

austinvernon.eth.link

201–210 of 212 posts

Re: Why Doesn't Software Show Up in Productivity?

#201

Earlier quoted context omitted.

I disagree completely. I'm insanely more productive as part of a team than I was in 199x. Not even talking about things for software development specifically, but for general-purpose word-processing and spreadsheeting and scheduling, you've got: - Live collaborative cloud editing over mobile. The back-and-forth that previously might take a week can now be done in half an hour while you're in the back of an Uber in a…

Years ago, if you wanted to do a spreadsheet task Microsoft had a help file on the PC that was readable and indexed and told you how to do common tasks. Now there is no on-system help whatsoever and searching Google doesn’t even get you something from Microsoft but rather a page from the Houston Chronicle (??) that probably doesn’t even work for your version of Excel. I think in most respects basic “office suite” sof…

95% of the things you wanted to do were never covered in Microsoft's help file.

The help file covered all the "building blocks", but there's a long tail of use cases requiring combining those building blocks in non-trivial ways.

If the Houston Chronicle happens to be the one covering one of those long-tail use cases then that's amazing. Because no user manual could ever be large enough for them all. And even if it's not for "your version of Excel", adapting it is probably the easy part.

Re: Why Doesn't Software Show Up in Productivity?

#202

I'm not sure that we're measuring productivity correctly these days. Take AI, for example. Going from barely being able to play chess, to winning at Starcraft and Go and basically any game Google thinks is worth cracking is a huge, huge leap in technological capacity. What was the impact of the people that worked on these and related technologies on "productivity"? You can count apples. You can't really quantify Dyna…

Oh we are measuring productivity correctly. How much more productive is an software engineer that uses Rust compared to one that uses, say, C/C++? That is to say, do I need fewer software engineers to deliver the same product if they use Rust rather than another language? If the answer is "not really", then Rust does not increase productivity (I don't know the answer, btw). In general, I don't think that software as…

> How much more productive is an software engineer that uses Rust compared to one that uses, say, C/C++? That is to say, do I need fewer software engineers to deliver the same product if they use Rust rather than another language?

Anyone who's used both in production for any length of time can tell you that you will not deliver the same product in C++ unless you're willing to put in JPL levels of investment. So yes, it's far more productive for "the same product." The question is what you mean by "the same product." Do you consider a project implementing a feature set with loads of memory errors to be functionally the same thing as one without? If you do, then Rust probably won't be that much more productive than C++ (IME still more productive, but within the realm of subjectivity). If you do not, then it's not even close. This is the calculation companies like Microsoft and Google have been doing when they invested in Rust for new OS development.

Re: Why Doesn't Software Show Up in Productivity?

#203

Earlier quoted context omitted.

I disagree completely. I'm insanely more productive as part of a team than I was in 199x. Not even talking about things for software development specifically, but for general-purpose word-processing and spreadsheeting and scheduling, you've got: - Live collaborative cloud editing over mobile. The back-and-forth that previously might take a week can now be done in half an hour while you're in the back of an Uber in a…

> Not even talking about things for software development specifically In 199x we had straightforward visual RAD IDEs like Delphi and C++ builder. IMHO this was the pinnacle of apps development productivity, what have now (Electron + a soup of web front-end frameworks) is nightmare, postapocalyptic chaos following the golden age.

But building anything requiring access to a shared database with a massive number of users was an expensive gigantic undertaking.

Now you can spin something up in a day for a few bucks a month.

I'd call what we're in right now the golden age.

Re: Why Doesn't Software Show Up in Productivity?

#204
post #32

Earlier quoted context omitted.

A few nits to pick as a woodworker: 1) You never save money building it yourself (at least not in comparison to a standard consumer option, like a chair or table from your local furniture store. This may hold up if you compare what you build to high-end hardwood furniture. But with the cost of tools, you're probably still losing money if this is just a hobby) 2) 90% of my enjoyment of woodworking is just being in my…

I built my dream workbench. The commercial ones were too light. I wanted one that was 8 feet long, and 4 deep, that I could bolt a big vise to, and whale away at whatever was in the vise without the bench scittering across the floor. It is build entirely from 4x4s for the legs, 2x4s for the rest of the frame, and 1x8 planks for the top and shelf. It's all held together with carriage bolts so it can be disassembled, a…

Wow, I built almost the identical thing a few years ago. Wanted a bench to put a small lathe onto while still having a copious amount of non-machine workspace. On the top I used 2x12's though. And (as a complete novice at the time just putting "lego blocks" together sourced from Home Depot), I just used regular screws to hold it together. That thing has moved with us for the past few moves. Super heavy. Also (not literally) bulletproof. Thanks for the description on your build.

Re: Why Doesn't Software Show Up in Productivity?

#205

Earlier quoted context omitted.

Oh we are measuring productivity correctly. How much more productive is an software engineer that uses Rust compared to one that uses, say, C/C++? That is to say, do I need fewer software engineers to deliver the same product if they use Rust rather than another language? If the answer is "not really", then Rust does not increase productivity (I don't know the answer, btw). In general, I don't think that software as…

> How much more productive is an software engineer that uses Rust compared to one that uses, say, C/C++? That is to say, do I need fewer software engineers to deliver the same product if they use Rust rather than another language? Anyone who's used both in production for any length of time can tell you that you will not deliver the same product in C++ unless you're willing to put in JPL levels of investment. So yes,…

The same product means seemingly the same thing in the hands of the customer. Users does not care or know whether MS Word is written in C++, Rust, or what not, they just see what the product can do and how well.

Maybe that's a good way to compare productivity: Let's say you have to develop and maintain MS Word. What's the size of the team if you do in C++ vs Java vs Rust vs whatever? The smallest team has the highest productivity by definition, all else being equal.

Re: Why Doesn't Software Show Up in Productivity?

#206

Earlier quoted context omitted.

Not any better? The allocation of finite resources is best done with money.

Money is a means to an end - profit should not be justification in itself, like it is today. Also, there are other good ways of allocating finite resources - allocation by money tends to create long-term winners and losers, as it is usually allowed to propagate across generations, reaching absurd levels such as people living off good land purchasing decisions made by their ancestors centuries ago. Sure, allocation by…

> There are people who actually create the useful items or services, and people who profit off it - and we have all mostly accepted that it's good and proper that these are different people.

No we haven't. People can be sole traders, and that's fine. What you're missing is some things need more capital to pay those people than is guaranteed return on investment, and thus that taking a risk is a valuable thing to do in and of itself.

Re: Why Doesn't Software Show Up in Productivity?

#207
post #32

Earlier quoted context omitted.

A few nits to pick as a woodworker: 1) You never save money building it yourself (at least not in comparison to a standard consumer option, like a chair or table from your local furniture store. This may hold up if you compare what you build to high-end hardwood furniture. But with the cost of tools, you're probably still losing money if this is just a hobby) 2) 90% of my enjoyment of woodworking is just being in my…

I built my dream workbench. The commercial ones were too light. I wanted one that was 8 feet long, and 4 deep, that I could bolt a big vise to, and whale away at whatever was in the vise without the bench scittering across the floor. It is build entirely from 4x4s for the legs, 2x4s for the rest of the frame, and 1x8 planks for the top and shelf. It's all held together with carriage bolts so it can be disassembled, a…

[deleted]

Re: Why Doesn't Software Show Up in Productivity?

#208

Earlier quoted context omitted.

> How much more productive is an software engineer that uses Rust compared to one that uses, say, C/C++? That is to say, do I need fewer software engineers to deliver the same product if they use Rust rather than another language? Anyone who's used both in production for any length of time can tell you that you will not deliver the same product in C++ unless you're willing to put in JPL levels of investment. So yes,…

The same product means seemingly the same thing in the hands of the customer. Users does not care or know whether MS Word is written in C++, Rust, or what not, they just see what the product can do and how well. Maybe that's a good way to compare productivity: Let's say you have to develop and maintain MS Word. What's the size of the team if you do in C++ vs Java vs Rust vs whatever? The smallest team has the highest…

I didn't say anything about consumers caring whether a program was written in C++ or Rust, and I don't think consumers care about that. I talked about whether the product is full of memory unsafety or not. Where that is a relevant aspect of your product, Rust is far, far more productive--it's more or less impossible to produce a large C++ program without exploitable memory unsafety bugs, while it's fairly tractable in Rust. Where it is not, I expect productivity gains to be modest at best.

My point here is that there is pretty much no sized team that will deliver a C++ program with equivalent functionality to Rust, when considering security as part of the feature set. We know that about 70% of CVEs in memory unsafe programs come directly from exploitation of UB, that there is no commensurate increase in CVEs in safe languages, and that only about 1% of LOC is unsafe--so weighing the percentage security bug reduction is pretty easy. But not all customers prioritize security very much, so Rust's benefits over C++ in this context will have to be downgraded according to how highly they value a 70% reduction in CVEs. That is why I said it depends on the product--you can't come up with a flat "productivity" metric, like you seem to want, that applies the same to every situation.

Re: Why Doesn't Software Show Up in Productivity?

#209

Earlier quoted context omitted.

The same product means seemingly the same thing in the hands of the customer. Users does not care or know whether MS Word is written in C++, Rust, or what not, they just see what the product can do and how well. Maybe that's a good way to compare productivity: Let's say you have to develop and maintain MS Word. What's the size of the team if you do in C++ vs Java vs Rust vs whatever? The smallest team has the highest…

I didn't say anything about consumers caring whether a program was written in C++ or Rust, and I don't think consumers care about that. I talked about whether the product is full of memory unsafety or not. Where that is a relevant aspect of your product, Rust is far, far more productive--it's more or less impossible to produce a large C++ program without exploitable memory unsafety bugs, while it's fairly tractable i…

There is indeed a flat productivity metric. But of course, a programming language being a tool, its impact on productivity varies from product to product.

I think my previous comment stands: Do you need fewer people to develop and maintain the product? That applies to every situation.

Re: Why Doesn't Software Show Up in Productivity?

#210

My family watched Miracle on 34th Street a couple years ago. Aside from being generally impressed with how well it's aged, I was particularly impressed with the office technology on display (pneumatic tubes etc). In Victorian London, mail could be posted up to 12 times per day.[1] That's about as often as e-mail can be turned around. Bronze Age merchants exchanged clay tablets with remarkable throughput.[2] On the co…

A lot of those jobs ultimately became redundant for people. Milk delivery makes no sense when you can choose your bottle down at the grocery store next time you're there. Bedside care became impractical as medical technology advanced, and electric trolleys are pretty cumbersome (especially alongside city streets). Eventually, we realized that we could cut out the milkman: we laid off a lot of people in the process, b…

FYI trolleys were phased out due to auto oil and gas conglomerates buying and phasing out trolley companies and lobbying local governments to drop support.
Post reply on HN