Live data from Hacker News

The Software Crisis

wryl.tech

141–150 of 201 posts

Re: The Software Crisis

#141
post #109

The author mentioned handmade as a step in the right direction but the handmade creator more or less gave up on the project after a couple years and didn't accomplish his goal of delivering a final product.

The later videos are like cautionary tales… 5 years in, no game in sight, and you’re 30 videos deep into writing a sophisticated global illumination system…

Game design and programming are largely orthogonal skills, and procrastinating working on the former in service of the latter is perhaps the most common game development mistake of all time.

Re: The Software Crisis

#142
post #126

Earlier quoted context omitted.

It's important to remember "Clarke's three laws"[0]: The laws are: 1. When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong. 2. The only way of discovering the limits of the possible is to venture a little way past them into the impossible. 3. Any sufficiently advanced technology is indistingui…

A tangent, but Clarke was slightly wrong. Magic is not just indistinguishable, but it actually IS advanced technology. In fantasy worlds, wizards spend years studying arcane phenomena, refining them into somewhat easily and reliably usable spells and artifacts, which can be used by general public. (Don't believe depictions of magic in video games, they simplify all the annoying little details.) The above paragraph is…

Whoooosh

Re: The Software Crisis

#143

Earlier quoted context omitted.

> We should have more respect for users Agreed. In my case, I write software for a lot of really non-technical users, and have found great utility in reinforcing inaccurate, but useful, user narratives. So "respect" doesn't just mean assuming users are smart. It's also making house calls. Meet them where they live, and do a really, really good job of it, even if I think it's silly.

Just curious, could you give a specific example where you've found it's better to reinforce an inaccurate mental model of the software? And how do you go about it?

I did it a ton, in my day job (image processing/camera control). I won’t directly link to that (personal policy), but we were in a constant war with the hardware people, who wanted, basically, skeuomorphic representation. We found that users often found these to be overcomplex, and that software often allowed us to abstract a lot of the complexity.

Many camera controls are where they are, because, at one time, we needed to have a physical connection between the actuator and the device. Nowadays, the buttons no longer need to be there, but remain so, because that is where users expect them to be.

Almost every car control is like that. Touch interfaces are falling flat, these days. Many manufacturers are going back to analog.

I am currently developing an app to allow folks to find on-line gatherings. It’s not an area that I have much experience in, personally, so I’m doing a lot of “run it up the flagpole, and see who salutes” kind of stuff. I just had to do a “start over from scratch” rewrite, a week ago, because the UX I presented was too complex for users.

The app I just released in January, had several pivots, due to the UX being incompatible to our users. We worked on that for about three years, and had to abandon several blind alleys. Not all the delay was for that, but one thing I did, was have a delicious feast of corvid, and bring in a professional designer, who informed me that all the TLC I had put into “my baby” was for naught.

The app is doing well, but we’re finding some things that users aren’t discovering, because our affordances aren’t working. You can tell, because they ask us to add features that are already there.

Often, I will be asked to add a specific feature. I usually have to ask the user what their goal is, and then work towards that goal, maybe in a different manner than what they suggested, but sometimes, their request opens my eyes to a mental model that I hadn't considered, and that gives me a good place to start.

I’m really, really hesitant to post examples here, as the very last thing that we need, are thousands of curious geeks, piling onto our apps.

Re: The Software Crisis

#144

If you look at the resumes of engineering or automotive company leadership, you'll see people going through stages of ever expanding responsibilities of part, component and product design, or management of production facilities of increasing size and importance. The CEO will still emphasize their technical knowledge, non-technical staff will at least try and fake it. In agile software development on the other hand, t…

I could buy this argument. Had I been a junior during the agile era, I'm not sure I would have developed as fast or as far as I have. The most agile pilled company I worked for just treated juniors & seniors as interchangeable cogs, except seniors should be able to clear more points per sprint. Active discouragement from thinking outside the scope of your ticket, keep your head down and mouth shut.

This doesn’t mirror my experience at all. Where I worked agile meant removing unnecessary processes as well as trusting people over tools. As a junior I was given a lot of flexibility and probably too little oversight. I was mostly given a high level task, no deadline, and had to together with others find ways to make the tasks smaller.

Re: The Software Crisis

#145
post #25

Earlier quoted context omitted.

The perceived misery you describe I feel is self-inflicted. Many devs "below" me have become entirely disconnected from customer needs, instead only focusing on "interesting" dev problems. Why do developers only work on ticket-sized portions of the actual requirements? To put it succinctly: because they are simply too dumb. They cannot wrap their heads around it. They cannot grasp it. Do I sound frustrated? I am. It…

> Why do developers only work on ticket-sized portions of the actual requirements? To put it succinctly: because they are simply too dumb. They cannot wrap their heads around it. They cannot grasp it. I think the reason is entirely different: ticket-sized portions of requirements are the only thing that one can hope to estimate in any useful fashion. Business side needs estimates, so they create pressure to split wor…

I very much dispute the claim that devs are not allowed to think big. It’s just that they take the easy way out. After all, others are taking care of the visual design, requirements engineering, reporting, controlling and whatnot, right?

It’s fine, really. But then please don’t try to overstep the role you assumed.

In my opinion, it is critical you do both: Know the big picture, the vision, build a technological vision based on that. And then you must work on this, in bite-sized pieces. From my experience, in all but the smallest projects, not working iteratively (“experiment”, as you call it) is pretty much a guarantee to build the wrong thing from a user/customer requirement standpoint. Not having the technological vision is also guaranteed to result in a steaming pile of tech debt.

I don’t see a problem with providing reasonably accurate long-time estimates either. Build your technological vision and you’ll know. Everybody knows and will understand that substantial requirement changes or newly discovered requirements will change the timeline.

Re: The Software Crisis

#146
post #16

Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort. * I do not argue against abstractions, but against the unrestricted application of them. * I do not advocate for a reversion to more constrained platforms as a solution. * I do not advocate for users becoming "more technical" in a "suck it up" fashio…

abstraction is the crabification of software,it gets do powerful and so good,it kills the carprace wearer. Allowing fresh new script kid generations to re experience the buisness story and reinvent the wheel.

Re: The Software Crisis

#147
post #16

Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort. * I do not argue against abstractions, but against the unrestricted application of them. * I do not advocate for a reversion to more constrained platforms as a solution. * I do not advocate for users becoming "more technical" in a "suck it up" fashio…

I don't think there is a software crisis. There is a more of a software glut.

There is so much software on so many platforms, such a fragmented landscape, that we cannot say anything general.

Some projects may be struggling and falling apart, others are doing well.

There is software that is hostile to users. But it is by design. There is cynicism and and greed behind that. It's not caused by programmers not knowing what they are doing, but doing what they are told.

The users themselves drive this. You can write great software for them, and they are disinterested. Users demand something other than great software. Every user who wants great software is the victim of fifty others who don't.

Mass market software is pop culture now.

Re: The Software Crisis

#148
post #139

Earlier quoted context omitted.

Windows 3.1 and Word easily fit on a 40MB hard drive with plenty leftover. Word operated on systems with as little as 2MB RAM on a single core 16MHz 80386. Modern microcontrollers put this to shame! Word then didn’t lack for much compared to today’s version. Windows and Office require now, 50-100GB disk just to function? 1000X for what gain? This is sheer insanity, but we overlook it — our modern systems have 5000-10…

You mean the Word where i had to save the document every 20 seconds just to be sure i didn't loose my school assignment from crashes at the most inconvenient moment. It left scars in my spline, to the point that I still have to actively hold myself back from the reflex of hitting Ctrl+S halfway through this comment.

Is that all you got?

Re: The Software Crisis

#149

Earlier quoted context omitted.

The thing that is unique about software is the lack of physical constraints which serve as a natural forcing function or filter on quality. With a bridge, for example, at some level it must meet a minimum bar of structural integrity, quality of materials, etc. or it will fall over from its own weight. As a cook, there is a bare minimum I have to hit with the quality of my ingredients and skill of preparation in order…

> The thing that is unique about software is the lack of physical constraints which serve as a natural forcing function or filter on quality. Completely agree with this. The number of good+reasonable solutions is almost infinite, and the number of bad solutions is also almost infinite. What makes it even worse is that we really don't have a good method of communicating the design+structure of our models to others (te…

"It would be amazing if we could create tools that allow us to describe the essence of the model and make it directly available to our brains so we could all collectively reason about it and manipulate it collaboratively."

Fuck that, I need a job.

Re: The Software Crisis

#150
post #126

Earlier quoted context omitted.

It's important to remember "Clarke's three laws"[0]: The laws are: 1. When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong. 2. The only way of discovering the limits of the possible is to venture a little way past them into the impossible. 3. Any sufficiently advanced technology is indistingui…

A tangent, but Clarke was slightly wrong. Magic is not just indistinguishable, but it actually IS advanced technology. In fantasy worlds, wizards spend years studying arcane phenomena, refining them into somewhat easily and reliably usable spells and artifacts, which can be used by general public. (Don't believe depictions of magic in video games, they simplify all the annoying little details.) The above paragraph is…

Gandalf wasn’t a technologist.

(Edit) and his magic wasn’t remotely Vancean

Post reply on HN