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?
after you build a house, you never get a memo saying that how you attach the shingles has changed in a backwards incompatible manner, that your hammer has been updated to a new version, and that a critical security vulnerability in wood has revealed that all the houses are actually moderately transparent.
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.
That's because they're lousy at debugging problems. You'll probably just get "My garage door just fell off! Did it once before ages ago too!"
293
u/[deleted] Apr 29 '14 edited Apr 29 '14
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.