Software Disenchantment (2018) • Hacker News Board

Re: Software Disenchantment (2018)

#271

Post by iamwil » Thu, Jan 02, 2020, 1:30 AM UTC

ibdknox wrote: post #98

iamwil wrote: post #8

I agree it's all slower and sucks. But I don't think it's solely a technical problem. 1/ What didn't seem to get mentioned was the speed to market. It's far worse to build the right thing no one wants, than to build the crappy thing that some people want a lot. As a result, it makes sense for people to leverage electron--but it has consequences for users down the line. 2/ Because we deal with orders of magnitude with…

I might strengthen your argument even more and say it's largely a non-technical problem. We have had the tools necessary to build good software for a long time. As others have pointed out, I think a lot of this comes down to incentives and the fact that no one has demonstrated the tradeoff in a compelling way so far. I find it really interesting that no one in the future of programming/coding community has been able…

I've also been lurking on the FoC community, and hadn't seen much on an articulation on the social and incentive structures that produce software. Do you think they'd be receptive to it?

And by "social and inventive structures", I'm assuming you're talking about change on the order of how open source software or agile development changed how we develop software?

While agile did address how to do software in an environment for changing requirements and limited time, we don't currently have anything that addresses an attention to speed of software, building solid foundations, and incentives to maintain software.

What would a complete system encompass that's currently missing in your mind?

Re: Software Disenchantment (2018)

#272

Post by rogerdb » Thu, Jan 02, 2020, 1:32 AM UTC

buzzkillington wrote: post #217

rogerdb wrote: post #20

> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. If bas…

RTFA: >And build times? Nobody thinks compiler that works minutes or even hours is a problem. What happened to “programmer’s time is more important”? Almost all compilers, pre- and post-processors add significant, sometimes disastrous time tax to your build without providing proportionally substantial benefits.

FWIW, I did RTFA (top to bottom) before commenting. I chose to reply to some parts of the article and not others, especially the parts I felt were particularly hyperbolic.

Anecdotally, in my career I've never had to compile something myself that took longer than a few minutes (but maybe if you work on the Linux kernel or some other big project, you have; or maybe I've just been lucky to mainly use toolchains that avoid the pitfalls here). I would definitely consider it a problem if my compiler runs regularly took O(10mins), and would probably consider looking for optimizations or alternatives at that point. I've also benefited immensely from a lot of the analysis tools that are built into the toolchains that I use, and I have no doubt that most or all of them have saved me more pain than they've caused me.

Re: Software Disenchantment (2018)

#273

Post by golergka » Thu, Jan 02, 2020, 1:33 AM UTC

anilakar wrote: post #127

An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobile phone are both 2015 models and I feel they're completely adequate for running all the software I've written.

I was so proud in 2014 that our development team managed to pull a 60 FPS on iPhone 4. Built our own UI framework (before Unity rebuilt theirs), pulled images from network, assembled and updated sprite atlases at runtime and even created our own text rendering - all of it, in order to get 60 frames per second on 4 year old phone. And most likely, it still does, in 2020.

Since then, I've never worked in a team that would be so dedicated to perfomance. May be because that was a team that worked on a product with over 100 million installs that had all major features already developed - everybody else is too busy trying to figure out a market fit.

Re: Software Disenchantment (2018)

#274

Post by smadurange » Thu, Jan 02, 2020, 1:35 AM UTC

My concern about this state of affairs in software engineering is that it may be producing generations of engineers who couldn't actually build/conceive things better (eg. Building a rendering engine or a mobile OS) if they wanted to concentrating that power in a few corporations. That's a bit terrifying.

Re: Software Disenchantment (2018)

#275

Post by shiftless » Thu, Jan 02, 2020, 1:35 AM UTC

ChrisMarshallNY wrote: post #253

Lots of moving parts. I am a dependency skeptic. I think that you need them to do big stuff, but should probably avoid them for small stuff. High-quality dependencies can have a drastic impact on the quality of your software, but so can low-quality dependencies. I think we are at the tail-end of a "wild west" of dependencies. When the dust settles, there will be a few really good, usable and stable dependencies, and…

I agree, and I'm actively collecting specific examples you or others may have, of common dependencies in the *NIX ecosystem which you feel are better than the alternatives, and why. (i.e. smaller, simpler, faster, more features, cleaner code, etc.) Which is better for example, libxml2 or expat?

Re: Software Disenchantment (2018)

#276

Post by d23 » Thu, Jan 02, 2020, 1:38 AM UTC

Performance is one thing, but I'm really just struck by how often I run into things that are completely broken or barely working for extended periods of time.

As I write this, I've been trying to get my Amazon seller account reactivated for more than a year, because their reactivation process is just... broken. Clicking any of the buttons, including the ones to contact customer support just take you back to the same page. Attempts to even try to tell someone usually put you in touch with a customer service agent halfway across the world who has no clue what you're talking about and doesn't care; even if they did care, they'd have no way to actually forward your message along to the team that might be able to spend the 20 minutes it might take to fix the issue.

The "barely working" thing is even more common. I feel like we've gotten used to everything just being so barely functional that it isn't even a disadvantage for companies anymore. We usually don't have much of an alternative place to take our business.

Re: Software Disenchantment (2018)

#277

Post by Wowfunhappy » Thu, Jan 02, 2020, 1:39 AM UTC

rogerdb wrote: post #111

buboard wrote: post #95

Earlier quoted context omitted.

Windows does it. And despite that, versions like win 7 were pretty fast

I'd argue that of any software project on the planet, Windows is the closest to having unlimited resources; especially when you consider the number of Windows customers for whom backwards compatibility is the #1 feature on the box. And speed isn't the only metric that matters; having both the 32-bit and 64-bit versions of DLLs uses a non-trivial (to some people) amount of disk space, bandwidth, complexity, etc.

Surely, Apple and Google have just about as many resources as Microsoft does.

If Android, Mac OS, etc were super slimmed down systems in comparison to Windows, I would understand the argument much better. Instead, it feels like we're in the worst of both worlds.

Re: Software Disenchantment (2018)

#278

Post by shantly » Thu, Jan 02, 2020, 1:44 AM UTC

d23 wrote: post #276

Performance is one thing, but I'm really just struck by how often I run into things that are completely broken or barely working for extended periods of time. As I write this, I've been trying to get my Amazon seller account reactivated for more than a year, because their reactivation process is just... broken. Clicking any of the buttons, including the ones to contact customer support just take you back to the same…

Khan Academy has some lessons aimed at fairly young kids—counting, spotting gaps in counting, talking that simple. I tried to sit with my son on the Khan Academy iPad app a few weeks ago to do some with him, thinking it'd be great. Unfortunately it is (or seemed to be to such a degree that I'm about 99% sure it is) janky webtech, so glitches and weirdness made it too hard for my son to progress in without my constantly stepping in to fix the interface. Things like, no feedback that a button's been pressed? Guess what a kid (or hell, adult) is gonna do? Hammer the button! Which... then keeps it greyed out once it does register the press, but doesn't ever progress, so you're stuck on the screen and have to go back and start the lesson over. Missed presses galore, leading to confusion and frustration that nothing was working the way he though it was (and it, in fact, supposed) to work.

I don't mean to shit on Khan Academy exactly because it's not like I'm paying for it, but those lessons may as well not exist for a 4 year old with an interface that poor. It was bad enough that more than half my time intervening wasn't to help him with the content, nor to teach him how to use the interface, but to save him from the interface.

This is utterly typical, too. We just get so used to working around bullshit like this, and we're so good at it and usually intuit why it's happening, that we don't notice that it's constant, especially on the web.

Re: Software Disenchantment (2018)

#279

Post by qqii » Thu, Jan 02, 2020, 1:44 AM UTC

mtm7 wrote: post #176

anilakar wrote: post #127

An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobile phone are both 2015 models and I feel they're completely adequate for running all the software I've written.

I remember a story about an electronic musician who preferred to mix his songs with earbuds/headphones instead of with a high-end megabucks studio sound system. His reasoning was basically, “that’s how my fans will listen to my music, so I need to make sure it sounds good to them.” I can’t remember who it was, but the idea always stuck with me. Anyway, I agree that we should test our applications with the same hardwa…

Unfortunately this isn't the perfect solution as there is no universal device or average user. Especially with music, mixing songs for earbud/headphones will produce a worse quality song for another pair. In the same way we've seen software written by users primarily using x86 work less effectively when compiled to arm. Plenty of open source projects are developed on by people with less than adequate hardware yet they're still bloated and slow.

I think it's very sensible (if a little unrealistic) to test applications on as many pieces of intended hardware as possible, and this somewhat reminds me about this story of snow clearance[0], where the solution was not only the intrudction of a new perspective but also empirical measurements.

[0]: http://info.gritit.com/blog/what-is-gender-balanced-snow-cle...

Re: Software Disenchantment (2018)

#280

Post by ken » Thu, Jan 02, 2020, 1:47 AM UTC

> I want to take pride in my work. I want to deliver working, stable things. To do that, we need to understand what we are building, in and out, and that’s impossible to do in bloated, over-engineered systems.

Somebody needs to write this software. Efficient, maintainable, and debugged are not the low-energy state.

That means it either needs to come from business, or from open-source hobbyists. Business doesn't see a competitive advantage in it -- even Apple, which has traditionally cared more about UX than anybody, just has to be better than their #2 competitor (and price of entry to "desktop OS" or "smartphone OS" is high so that list is short, and not changing on any relevant timescale). And the open-source world has never delivered well on the end-user experience side of things.

The sad truth is that users would rather have new software for $0 (paid by ads, or media subscriptions, or whatever) than pay what it truly costs to develop software.

My main hopes today are that the end of Moore's Law will force companies' hands, or that government will step in to regulate minimal quality, or that workers will organize so they can stand for quality behind a CBA. These all seem rather unlikely at this junction. The number of programmers in it for the paycheck far outweighs the number of people who care about simplicity.

Software is going to get much worse before it gets better.