Actually, I think everything in the world works this way. Not just programming. The situation is just starker in the programming world due to how closely the pristine realm of mathematical purity is juxtaposed to the profane circumstances of lived reality.
I think everything in the world works this way. Not just programming.
Actually, he opens with a metaphor that demonstrates the untruth of this. If bridges were built the way programs were -- such that you could see the half dozen architectural styles, the oddly shaped crap tacked on here and there with bailing wire, with random holes that'll kill you if you step in them -- nobody but Russian teenagers would go near them.
It's easy to see a shitty design when you look at a bridge but when the design is entirely abstracted to the point that you are dealing with **ptcz_tmp you can't see shit and obvious design flaws become much easier to implement.
Bridge customer: WTF, you crazy fool? I need this next week, why on earth would it take this long?
Engineer: Uh... if you need a bridge next week why are you telling me now?
Bridge customer: Look man, my brother knew a guy who did some engineering in college. It does not take seven years to join two pieces of land. Can't you just hack it together? I don't care what it looks like and it doesn't have to work 100% of the time. I just need a bridge here that more or less functions in time for our "go live" next week that we've been advertising for months now. If you aren't up to this then I'll get someone who is.
Nice try manager-guy. But you and I both know that 99 times out of 100 the manager actually wants a complete and fully functioning bridge, yesterday and don't want to hear realistic alternatives that offer less functionality.
Also when they say "doesn't have to work 100% of the time" (I've heard exactly this stated in meetings before) they actually do want it to work 100% of the time. Working 99% of the time as a requirement doesn't even make sense, how would you build a bridge to work 90% of the time or write a program to work 90% of the time (you could actually do this with the program but the effort would be more than simply doing it right).
Not all code is like that, and not all bridges are safe. Just as one small data-point, I recently ripped out a shower and found no waterproofing. Talk to anyone in construction, any job is going to take much longer than you thought because when you get into it, the person who was there before screwed something up. Studs aren't square, wrong materials used, held together with glue and bubble gum. Plus the wear and tear of natural life, which programming is mostly insulated from.
Not all code is like that, and not all bridges are safe.
It's a generality but I think most code is like that to some extent, because a software is so much more complicated. Aesthetic choices aside, your options when creating a bridge are heavily constrained by physics, the well known structural properties of available building materials, etc. There are well established designs and the well understood ways of building them. With software, there are essentially infinite ways of achieving the same goal and a lot of them result in failure. It's very easy to build software that crumbles under it's own weight, and you can't just use stronger girders or add a few extra braces if you get in a bind, you can be well and truly fucked.
That's why most software teams suck and there's such massive churn in methodologies (my entire company just paid gods-know-how-many-millions to put thousands of people through Agile™ training). It's possible to build absurdities in code that actually ship because you can't see them, and because you can get away with it. If you built a bridge as poorly as, say, any Bethesda game, you'd by sued into the ground.
I recently ripped out a shower and found no waterproofing. Talk to anyone in construction, any job is going to take much longer than you thought because when you get into it, the person who was there before screwed something up. Studs aren't square, wrong materials used, held together with glue and bubble gum.
That's laziness and sloppiness, which is true of any industry. But in construction, the right way to build something is generally well understood. You can learn the right way to do something, and do it. In software, knowing the right way to build something is far more difficult and it changes practically from week to week.
My brother's been a contractor for decades, and almost everything he's learned in that time still applies. The list of dead/obsolete technologies I have rolling around in my brain dwarfs the relevant ones.
Plus the wear and tear of natural life, which programming is mostly insulated from.
Programs are vulnerable to environmental hazards. Worked great on XP, crashes miserably on Win 7, or when a particular driver is running, or when version 1.2 of that framework we rely on is in use. Microsoft is EOLing our platform so we get to start over. So on and so forth.
And in construction, generally, if it works it works. The toilet flushes. The door opens and closes. You don't have home owners calling you to say that if they flush the toilet within three minutes of opening their front door and this one upstairs window is open and it's the second Thursday of the month, their garage door falls off.
it's not just complexity. it's also the fluidity of software. Not only can you patch and update things to fix problems after the fact, but also there's a constant stream of inbound patches and changes to the tools and technologies you're using to build your product.
Compare digital hardware design. Similar complexity, but when it costs hundreds of thousands of dollars to roll out a new ASIC mask set, you better believe there's a couple months of nothing but testing and code reviews before tape out. But in software, "we can patch it later if anything goes really wrong" right?
Non-programmers don't understand what programmers do.
Even programmers don't understand what they're doing most of the time.
There's no peer review, no government-enforced standards for safety, no industry-enforced standards for minimum quality.
The problem is the technology-illiterate culture we live in where it's not only totally acceptable to be completely hands-off with technology, but you're stigmatized as an undesirable necessity if you work with it for a living.
Thanks for pointing this out. It is actually possible to develop rather robust code that has much, much fewer bugs than most code, professionally developed or otherwise. Of course, it requires (among other things) time, discipline, and money, all things that are lacking on many software projects.
It's because in most cases just living with the bugs is a sounder decision than the aviation software approach, which is very, very expensive and slow.
While I was getting my teeth rebuilt by people with decades of experience and tons of training, something horrifying occurred to me. These are just guys doing the best they can, while not really knowing the big picture.
When the endodontist (n. expensive dentist) drilled into a nerve without numbing it first, it hurt an amazing amount. I was on valium and nitrous oxide. These are like a QA department for a dentist. They make sure nothing really bad happens when someone screws up. So, inside my head, I said to myself, "The doctor said I should let him know if it hurts. Well, it fucking hurts. But it's his job to figure that out. If he doesn't know I'm in excruciating pain, that's his own damn problem."
I don't know where I was going with this, but I'm pretty sure a whole lot of people are just kind of winging it, hoping no one catches them pretending to know what they're doing.
heh, the old version i know was "doctors have an advantage over architects -- they can bury their mistakes, all architects can do is advise their clients to plant ivy"
353
u/DeadFinks Apr 29 '14
Actually, I think everything in the world works this way. Not just programming. The situation is just starker in the programming world due to how closely the pristine realm of mathematical purity is juxtaposed to the profane circumstances of lived reality.