Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No dogs were harmed in the making of this app

shmck.substack.com

Post reply on HN
Print view View original

111–120 of 202 posts

Re: No dogs were harmed in the making of this app

#111

Post by cgriswald »

qup wrote: post #75
lostlogin wrote: post #42

Earlier quoted context omitted.

> I liken it to building castles in the clouds You’re very positive. When you see a developer dealing with a bug, it seems more like they are dealing with a turd palace floating in a sewer.

Turds are shapeable, too. Hard to polish, I've heard. But you control the poopy stack.

> [Turds are] hard to polish, I've heard.

Mythbusters did it:

> Adam and Jamie first visited the zoo to obtain a variety of feces to try to polish. Poop collected, they tried to pick the most polishable candidates, and then baked them to remove the moisture. Adam tried to shine his poop with a buffing wheel, while Jamie's tactic of applying a furniture polish caused a philosophical disagreement between the two. Adam eventually brought in an outside expert to teach them dorodango, a Japanese art form that allows a practitioner to apply a shine to dirt using nothing but water and physical effort. Applying this technique, Adam and Jamie were both able to polish balls of poop without using any foreign materials as judged by a gloss meter, exceeding a standard of 70 gloss units for high gloss.[0]

[0] - https://en.wikipedia.org/wiki/MythBusters_(2008_season)#Epis... (Section: You Can't Polish Poop)

Re: No dogs were harmed in the making of this app

#112

Post by stronglikedan »

s1artibartfast wrote: post #98
wruza wrote: post #92

Earlier quoted context omitted.

Why not hire hardware engineers to write software then?

Because software development isnt an engineering task. Engineers are good at building bridges, and artists are good at making paintings. That doesnt mean it is a good idea to have the engineers paint paintings.

Software engineers for critical systems would like a word.

Re: No dogs were harmed in the making of this app

#113

Post by ganzuul »

cgriswald wrote: post #107
mewpmewp2 wrote: post #70

Earlier quoted context omitted.

It's preferable the fuel state stays as it is. How do you know it's not the amount of fuel otherwise?

Presumably the engine was only idling during their decent if the only thing that slowed their car was 'miraculously' grinding the car against the mountainside. So, using previous records, they should estimate fuel usage during the decent. Then they should walk to the nearest fuel station, purchase fuel, and walk back. During that time, they can calculate the amount of fuel that will evaporate while they have the gas…

OBVIOUSLY, you could have solved the problem with motor braking. The driver is not going to accept fault until there is conclusive evidence of the their wrongdoing, but you can't let the team know you are going to repeat the test again but with a different driver because then they will invent objections to pushing the car up the hill.

Re: No dogs were harmed in the making of this app

#114

Post by dudeofea »

jerf wrote: post #87

I've developed a real distaste for the people whining about how we aren't real engineers and we "just" need to solve that by working more like real engineers and having all these massive up-front design meetings and making tons more plans, etc. etc. It betrays a profound misunderstanding of the situation. The other engineering disciplines don't work like that because they're just soooo much more professional than us.…

you can certainly fix an engineering design in-situ, just look at all the airplanes/jets designed pre-CAD software that were made "just-so" with all the know how embedded in the brains of those that made them/fixed them https://www.youtube.com/watch?v=NPVT2lvMvOk

Re: No dogs were harmed in the making of this app

#115

Post by brandensilva »

mock-possum wrote: post #96
feintruled wrote: post #4

That's quite a tale, a parable almost about how software engineering differs from other jobs (I want to say 'real' jobs but tongue in cheek). I like this one too, it's even snappier. A software engineer, a hardware engineer and a department manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of co…

If you could click ‘relaunch’ and the car would miraculously reappear at the top of the hill and repeat the event, allowing you to freeze time at the instant the brakes failed, then pull apart every piece of the car so you could precisely observe the failure in real-time, in slow mo, and in reverse - to pinpoint exactly what the problem was You’re saying the power to do that makes software engineers ridiculous or imp…

Right with software we have abstractions and flexibility. With hardware they are grounded more to the physical capabilities of the hardware.

Of course software is also limited by hardware capabilities but we can code whatever we want on that hardware as long as it fits within the provided specs.

Re: No dogs were harmed in the making of this app

#116

Post by jerf »

dudeofea wrote: post #114
jerf wrote: post #87

I've developed a real distaste for the people whining about how we aren't real engineers and we "just" need to solve that by working more like real engineers and having all these massive up-front design meetings and making tons more plans, etc. etc. It betrays a profound misunderstanding of the situation. The other engineering disciplines don't work like that because they're just soooo much more professional than us.…

you can certainly fix an engineering design in-situ, just look at all the airplanes/jets designed pre-CAD software that were made "just-so" with all the know how embedded in the brains of those that made them/fixed them https://www.youtube.com/watch?v=NPVT2lvMvOk

Of course you can... sometimes.

And you can't always do it in software, either. I keep a mental list of "things you can't really retrofit onto a mature piece of software" that I keep kicking myself to turn into a blog post sometime. I suppose a quick & trivial example is that pretty much by definition switching languages involves a rewrite.

(Though that involves a bit of definitional footwork where I declare using a compiler that goes from language A to B isn't really "switching to B". Anyone who has tried that maneuver in real life can attest it certainly isn't the same thing as a real full rewrite in the target language, even if it does sometimes have its utility.)

Still, there's literally orders of magnitude difference in how likely a given retrofit is to work and how easy it is for us to add it, and proof of that is precisely in the enormous signature this difference leaves on our processes.

Re: No dogs were harmed in the making of this app

#117

Post by gretch »

stronglikedan wrote: post #112
s1artibartfast wrote: post #98

Earlier quoted context omitted.

Because software development isnt an engineering task. Engineers are good at building bridges, and artists are good at making paintings. That doesnt mean it is a good idea to have the engineers paint paintings.

Software engineers for critical systems would like a word.

Yeah it makes no sense. Like, you build an airplane and clearly the airplane needs both it's software and it's hardware in order to fly.

Somehow the people who made the hardware are engineers, but the people who made the software aren't engineers.

Re: No dogs were harmed in the making of this app

#118

Post by Crespyl »

tialaramex wrote: post #48
firefoxd wrote: post #20

I giggled at the end. Just yesterday, we solved an issue that plagued the company for 3 years. For us it was the letter 'A'. Someone had been doing manual fixes inserting and removing data for the past 3 years. It became part of his job. He added a recurring event in his calendar just to do that regular clean up. Millions of customers depended on this one individual making sure they had the correct data plan on their…

So somehow in some parts of the code STATUS_ACTIVE is defined wrong? I guess there is always a risk that some "helpful" contributor will fix the typo in your definition of HttpHeader::REFERRER as "referer" to make it "referrer" instead, thus completely breaking all the software because nope, that typo is enshrined in the HTTP standard, it's Phillip Hallam-Baker's fault while he was at CERN.

> So somehow in some parts of the code STATUS_ACTIVE is defined wrong?

I would guess that some other part of the app doesn't even use the constant at all, and just hardcodes "Active" as a string on its own. Maybe taking the value of a dropdown from the UI and never mapping that back to the actual constant.

Re: No dogs were harmed in the making of this app

#119

Post by monista »

fhd2 wrote: post #59
renewiltord wrote: post #56

Earlier quoted context omitted.

True. We’re scientists. Replication is important! :)

"Empirical science" sounds better than "have you tried turning it off and on again?", doesn't it.

I read is as a reference to https://xkcd.com/242/

Re: No dogs were harmed in the making of this app

#120

Post by kr0bat »

gwbas1c wrote: post #64
ryandrake wrote: post #35

I always like to see upstream corrective action after something like this. If there was adequate logging / error reporting, this wouldn't have taken a week to fix. Whatever library he sent the invalid "image/jpg" MIME type to should have thrown an exception, crashed, or at the very least, logged loudly. I wonder if OP filed a bug against it.

Yeah, at the end of the article I even wondered what kind of environment Shawn (author) works in where it would take so long to diagnose? Was Shawn able to access anything on the server that would confirm/deny that the image upload was coming through? Why did the image upload work in the test environment but not in the released version of the app? What was different about the test environment? In theory, Shawn should…

Yup, that one paragraph left me scratching my head. In my mind the (very thinly described) image upload functionality should have failed regardless of configuration.

Maybe by "the images simply wouldn't upload." the author meant "did not display", and the file was being uploaded to the data store, was visible when viewed in the data store directly, but would not be displayed in app when requested.

I got the feeling that this is one of those 500-mile email[1] stories, where technical details are omitted for easier storytelling

[1] https://news.ycombinator.com/item?id=9338708

Post reply on HN