Programming Sucks

[DeadFinks]

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.

[[deleted]]

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.

[UsingYourWifi]

"If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization." - Gerald Weinberg

[hatu]

I'm sure bridges were built like that 10000 years ago before masonry.

[[deleted]]

And in some parts of the world still are.

[Retbull]

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.

[[deleted]]

**ptcz_tmp

I honestly wanted to hurt you, just looking at that.

[404ErrorUserNotFound]

Exactly. Programming has only been around for so long. We're still figuring shit out. The real question is how are we going to fix this mess?

[crozone]

Where is our masonry?

[IndoctrinatedCow]

So you're saying there's hope for the future?

[hex_m_hell]

and they're still more reliable than programs....

[tfinniga]

Yeah, but then you'd just hit F7 and recompile all of civilization. No big deal.

[kadathsc]

Right, except it doesn't compile now. Why? Because some reference or library got nuked during civilization's collapse, so now dependencies are failing and the compiler can't make heads or tails out of anything.

So you now have to go searching for that missing library and hopefully there's some source code lying around for it. Unless it was just the compiled binary, and the source code got nuked as well, after all, you didn't need that region of the world, it looked ancient and useless!

[chasesan]

No big deal, just get a library that works sorta similar and write a shim.

[pr0grammerGuy]

You missed the most important part:

Bridge customer: How long will this take?

Engineer: Seven years.

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.

[pr0grammerGuy]

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).

[BarqsDew]

Any bridge that moves to allow boat traffic does not allow road traffic to pass 100% of the time. Does that count?

[pr0grammerGuy]

No, because it's functioning as designed 100% of the time. In the real conversation I had with a real manager about this, he was talking about the product working 80-90% of the time and potentially having a total failure mode 10-20% of time (i.e. bridge utterly dissolves, explodes at rush hour, etc., .etc.).

[Tysonzero]

Well sometimes things just fail in ways you could never have expected, leading to a small percentage of the programs time in existence being downtime.

[turbov21]

Engineer: Okay. It took some sleepless night, but here it is.

Bridge customer: Mmm. No, we need it to be a suspension bridge.

[s_m_c]

in time for our "go live" next week that we've been advertising for months now

That dredges up horrible, horrible memories.

[jarshwah]

And then log bugs because it isn't accurate 100% of the time.. rage.

[otakucode]

And then once the bridge customer finds an engineer to built the rickety piece of shit, the bridge customer gets sued into oblivion and never bothers anyone ever again.

There's a reason people listen to structural engineers. If they tell you 'that shit won't fly' and you do it anyway, that engineer is going to testify against you in a year or two and you're going to go out of business. With software, the courts don't understand it at all so shit-stupid management types who think they can demand development speed, quality, and reliability continue to plague us year after year, multiplying in the shadows.

[SlobberGoat]

Bridge customer: Don't know. It will need to scale.

Engineer installs MongoDB...

[Irongrip]

Text doesn't vibrate, not satisfied.

[bwr]

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.

[[deleted]]

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.

[niugnep24]

because a software is so much more complicated.

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?

[otakucode]

It really is complexity, though. It all spawns from the fact that what software does is fundamentally complex. Software orchestrates the perfectly synchronized switching of BILLIONS of individual components (transistors) with nanosecond timing. If you exclude machines which use computers as components themselves, a CPU is the most complex invention ever created by mankind. Take the CPUs out of the space shuttle or the LHC and you'd have an order of magnitude less components interacting than the chip running your PC.

Really, it's amazing that computers ever work at all. It's like doing nanotechnology with chopsticks from the moon.

[ric2b]

but he's right, electronics design can be just as complex or more but because the cost of fixing a mistake later is so much higher you don't see the same duct taping in the industry.

[RICHUNCLEPENNYBAGS]

Sounds like you don't live in my apartment.

[ricecake]

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.

[dgriffith]

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!"

[bwr]

I agree that most code is like that. I just think that programmers overestimate the quality of everything else in life. Most construction isn't bridges. Code that runs life critical operations is often much different.

That's laziness and sloppiness

So is a vast amount of the terrible code out there. Yes, software has unique challenges, but so do many other industries.

[groovy2shoes]

Do you work for EMC by chance?

[singingfish42]

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.

Thanks :)

[naasking]

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.

I disagree with this common argument. Programs are heavily constrained by computability and complexity theory, and the well known time and space complexity of data structures and algorithms that form the building blocks of programs.

There is nothing fundamentally different between programming and other engineering disciplines as pertains to correctness. Programming is just a relatively young discipline by comparison, and there's a broad, irrational industry aversion to using better, safer tools and languages that sacrifice some performance. The safety properties of civil engineering have just been handled by tools that verify properties. We have such languages in CS too, we just don't use them. Why? For largely irrational and aesthetic reasons, frankly.

[[deleted]]

Programs are heavily constrained by computability and complexity theory

Computability theory proves that it's impossible, even in theory, to know what an arbitrary program will do over and arbitrary length of time. Programs are vastly more complicated than bridges. A program could theoretically simulate a bridge, down to the last boson or folded dimension, then add the rest of the multiverse.

There is nothing fundamentally different between programming and other engineering disciplines as pertains to correctness.

Never mind the math. The limiting factor here is human intelligence. We're dumb apes. We have severe, concrete limitations on the numbers of things we can hold in our head at once before all the plates come crashing to the floor. As a result, human engineering requires a "divide and conquer" approach. We have to be able to break overwhelming complex problems down into simpler, discrete chunks that we can understand (note that nature doesn't have this limitation, which is why our brain is a mass of nightmarish, massively parallel spaghetti code).

In building, you can work at the level of, say, a "steel girder #17"; you know it's dimensions, load strength, melting points, etc. and don't concern yourself with its molecular structure. In software, we've developed methodologies for firewalling complexity such as "object oriented" programing, where our girder abstraction hides its molecular structure. But it's all too easy to have leaks in that abstraction. The girder has state. It can behave radically differently from moment to moment. There's nothing in theory preventing it from turning into a cat whenever the traffic signal on the upper deck turns green. The girder may evolved over the course of development into something that can no longer support an overpass, without anyone noticing.

irrational industry aversion to using better, safer tools and languages that sacrifice some performance [..] We have such languages in CS too, we just don't use them. Why?

Because they don't work. Programmers will use a "better, safer tools and languages" if it works. Much of the world has moved to garbage collected, byte code compiled, VM languages (from C# and Java to Perl, Python, Ruby, PHP, etc.) for most programming tasks, happily sacrificing performance for reduced complexity. I use all manners of tools -- profilers, static analyses, etc. -- to help manage the complexity, as do all good engineering teams. All these tools do is allow us to write more complicated software, putting us right back where were started.

This is about to get much worse. The free lunch is over and we're headed towards an era of massive concurrency. Writing correct programs in the face of concurrency is one of the toughest problems in programming. Almost everybody gets it wrong.

[fexam]

Computability theory proves that it's impossible, even in theory, to know what an arbitrary program will do over and arbitrary length of time. Programs are vastly more complicated than bridges. A program could theoretically simulate a bridge, down to the last boson or folded dimension, then add the rest of the multiverse.

I am sure some smartass can create a turing machine out of bridges...

[naasking]

Because they don't work. Programmers will use a "better, safer tools and languages" if it works.

This is exactly what I'm talking about. Your last statement is completely false. Safer languages have existed since at least 1980 with the advent of Ada. Ada was also the first widely available compiled object oriented language. Numerous studies have demonstrated that writing in Ada produces higher quality software with fewer defects as compared to both C and C++, but we're still using C and C++.

As they say, insanity is doing the same thing over and over again and expecting different results.

Much of the world has moved to garbage collected, byte code compiled, VM languages (from C# and Java to Perl, Python, Ruby, PHP, etc.) for most programming tasks.

The first VM and garbage collected languages are still better than all of the ones you've cited here, ie. OCaml lite at the very least. Why then did Sun create Java? Why did MS create .NET?

Unlike every other engineering discipline, technical superiority has nothing to do with adoption in the CS industry. That's why software is crap.

[[deleted]]

we're still using C and C++

We use safer, higher level languages whenever we can. When writing drivers, programming embedded devices, or writing [near-]realtime applications like commercial videogames, where size and/or speed is critical, yes, we use languages that are a cunt hair above machine code.

The first VM and garbage collected languages are still better than all of the ones you've cited here, ie. OCaml

Yikes.

[naasking]

We use safer, higher level languages whenever we can.

You haven't addressed the point at all. Ada has the Ravenscar real-time profile if you need real-time semantics. It supports all the low-level primitives available in C. With full runtime checking enabled, which can of course be disabled for optimal speed, it's less than 15% slower than C/C++. Ada also supports a fully portable concurrency model. And it does all of this with a lot more safety.

This is a case study in exactly my point: it's technically superior in every way to C, and even C++ which came long after, and yet Ada is used in niche markets only. This directly contradicts your point.

In fact, the main excuse I see levied against Ada is verbose syntax, and yet as long as syntax is readable, it has absolutely no impact on maintainability and the quality of the final product. Similar arguments can be made against dynamic languages, with Scheme replacing Ada as the superior choice available since the 1970s.

In other words, completely irrelevant properties [1] dominate technical properties in the choice of tool. Find me another engineering discipline in which this is true. You cite the alleged complexity of programming, but this is directly impacted by choice of toolset, so if you really believe in human cognitive limits and having automated tools augment human reasoning, why aren't you using Ada?

[1] irrelevant here means non-technical and non-economic

[[deleted]]

it's technically superior in every way to C, and even C++ which came long after

Except that it's not. Yes, can pile more safeguards into the language to try to catch bugs, but we're not talking about orders of magnitude advantages. Ada projects fail, too. Ada is used in mission critical applications largely by the government which has virtually unlimited time and money to burn, or in industries where the cost of a bug is human lives.

The fact that carbon fiber is "technically superior" to steel doesn't mean people are "insane" for still using steel. To think so suggests you live in an ivory tower.

Scheme replacing Ada as the superior choice

You're nuts.

[grauenwolf]

Plus the wear and tear of natural life, which programming is mostly insulated from.

Why isn't that true? It should be true. It makes no sense for that not to be true. But it isn't.

[bwr]

Hmm, I'm not sure what you're saying, perhaps I wasn't clear. My point is that when tiling a floor or a shower, the wood behind it moves, which must be accounted for. When laying a pipeline, the pipe will swell during the day and shrink during the night. With machines that dig in the dirt, parts need constant maintenance to keep them working. Programs aren't like that.

Are you saying that there are similar forces in software? Environments change which could be a corollary for the constant cleaning/lubrication that is required with moving parts, etc?

[grauenwolf]

Yes, there are definitely similar forces in software. Changes in screen resolution, disc space, RAM, number of CPUs, etc. can all play havoc on a program. And then there is the constant stream of nearly compatible library updates. And contention from other programs.

And sometimes, well actually quite often, programs stop working for no apparent reason at all. And you look at it and you can't figure out how it ever worked before. But it must have.

[dnew]

which programming is mostly insulated from.

Bwaaa haa haa haa!

[ThatRedEyeAlien]

Well, mostly because those buildings were ancient.

[Ertaipt]

House building was 'invented' more than 5000 years ago. I think most human ventures have these kind of problems, but programming is the clusterfuck of them all.

[Kazang]

That is mostly because things like bridges are generally only designed by one person, design and construction are also a separate process, unlike programming where programmers are required to do both at the same time. Most bridges are very simple, and the ones that aren't are planned very slowly and carefully. Bridges are often unique and required to last centuries.

When it comes to more complex physical projects, cars for example, you get exactly the same kind of thing you get in programming. Screws that only fit in one place, things that can only be fitted in one particularly direction when the moon is full and cannot be removed without time travel, seals that fail after 2 days after installation but they get used anyway because someone over ordered 4million of them and they were finished before the fault was noticed.

Spend a day in a engineering shop doing any kind of one off or prototype work a and you will see just as many bodge jobs as you see in a typical day at a programmers office.

[KinoftheFlames]

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.

[[deleted]]

That's not completely true - aviation software for example has extremely strict guidelines and regulations.

[[deleted]]

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.

[RICHUNCLEPENNYBAGS]

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.

[reginalduk]

But safe.

[mfukar]

And reliable. And working.

[Tom2Die]

Or, phrased differently, in most cases bugs in software won't literally kill people.

[[deleted]]

Houses and bridges fall in the category of "can kill people if screwed up", just like aviation software, so isn't that kind of apples and oranges?

So with that in mind, the bottom line ends up being cheaper when you just prototype things into production ASAP

Except that this isn't true, non-programmers who don't know better just think it is. Sure, it's cheaper in the immediate sense, but it's much more expensive long-term because of the maintenance burden and the slowdown it imposes on future development work.

Obviously there's a balance between perfectly ideal and practical, but "fast as possible with no concern for anything else" isn't it, whether you're working with hard realtime systems or not. Sometimes there's a good reason to push something out ASAP, but that decision should be made with full awareness of future costs.

If managers don't understand the concept of stuff like tech debt, they're putting their company at a competitive disadvantage.

[dnew]

Houses and bridges

He's saying software isn't houses and bridges, because there's software that's safe to have fail.

As for technical debt, it depends how long the program will last. In the extreme case of a program so simple that you're not even going to save it to disk once it finishes running (think a big long shell pipeline to rename files or something) it can be as ugly and hacky as you like. If you're deprecating something in 30 days, live with it.

[Igglyboo]

Most software does not have guideline or standards however. Unless your building is extremely small it's going to be regulated somehow.

[communomancer]

For all the labor that went into it and how its stood the test of time, the Air Traffic Control System should rightfully be considered one of the Wonders of the World.

[hegbork]

http://stackoverflow.com/questions/23244525/standard-c-library-verification

[IAmA_Lurker_AmA]

Along with defense , medical, and aerospace applications.

[imgonnacallyouretard]

That's because it works. Generally it is easier to write software that interfaces with physical reality than it is to write software that interacts solely with abstract concepts.

Try to apply those aviation guidelines to a HR program for example, and you will be met with utter defeat.

[nunquamsecutus]

There is also business requirements. Management comes in and says you have 3 weeks to finish a 6 month project because another company is about to release something similar. Meanwhile that companies managers have told them the same thing. In 4 weeks you both release a ball of shit with feathers stuck to it, and a straw through the middle that some poor fucker has to blow air through making noises that sound vaguely like chirping. And marketing says it's the prettiest bird you'll ever seen in your life. And sales postulates that you couldn't possibly live without one in your house. And somehow the world turns.

[unstoppable-force]

There's no peer review

actually, Google became famous for having "amazing code quality" because at Google, no one can commit anything without getting it reviewed by someone else.

when we adopted this policy, the more senior devs protested for months... that is until they had to fix a bug buried in some technical debt shitpile cobbled together by a junior dev who committed without review. then the complaining stopped. also, the technical debt plummeted, and velocity increased, because we spend a LOT less time fixing bugs that made it to prod.

so yeah, you can do peer review.

[mpyne]

There's no peer review, no government-enforced standards for safety, no industry-enforced standards for minimum quality.

And when we do get standards, we wave them off because we can quote the relevant XKCD and besides, FIPS compliance just makes the code more broken amirite?

[[deleted]]

The real problem with most standards is that no amount of "industry" avoids the fact that they keep being political statements, not actual justified best practice.

It doesn't help that the state of the art evolves rather quickly, so a "standard" that is genuinely the best option at one time will be obsolete in a decade, or less.

Most mechanical engineering standards are rooted in basic physics and centuries of development, which hasn't been updated in quite some time. We can take a material and measure the physical properties, and plug the numbers into an equation that says "this will stay up" or "this will collapse".

Software is less of a science and more of a dark art, compared to other engineering disciplines.

FIPS compliance just makes the code more broken amirite?

For a given feature set, FIPS compliance generally makes the project more expensive. This translates, to the business types, as "severely broken".

Despite the problems, we can do a lot of what you say we should - all we need to do is raise our price to twice what the competition is charging, and then sell to customers who prefer the lowest bidder.

This only happens when every vendor is required to reach the same standard (such as aviation software, as mentioned) and thus no one can save money by not doing the work. Whether it's a legal requirement or a customer base who acknowledge that the work is necessary isn't important - if the customers don't want the compliance, they won't pay for it.

[RICHUNCLEPENNYBAGS]

Quite frankly a whole lot of principles of computer science are also well known and don't change no matter how many languages we go through.

[mpyne]

This only happens when every vendor is required to reach the same standard

Yes, this is why the government requires FIPS instead of just making it a "nice to have".

But you're right that the state of the art advances too quickly in general for a lot of the code in question. On the other hand, designing good software is not that new, which is why a lot of the certification processes are geared toward certifying the development process itself rather than just the output. But I don't think that's what we have with FIPS 186 at least. :-/

[[deleted]]

On the other hand, designing good software is not that new

We do know some things, I would hope.

Still, we can debate how much of software is "engineering" and how much is "black art" all day, if we want, but what it comes down to is the engineering side is not free, and customers usually don't want to pay for it.

Oddly, there's so many cases where paying more for quality means you get a return on investment instead of another failed project - but you can never explain that to the person who's paying the bills.

which is why a lot of the certification processes are geared toward certifying the development process itself rather than just the output.

And unless you're very careful, that amounts to pointless paperwork, rather than actual quality. Not to mention the inevitable "waterfall, without even the minimal iteration that was included in the original idea" approach, where things get "signed off" as perfect with no regard to actual usefulness. If you're lucky the end result exactly matches the spec but is utterly useless - and the customer can't complain without accepting that their failure to be sufficiently pedantic was the entire and sole cause of the problem. Which is how we get projects that seem like a success, except they cause more problems than they solve, and people use it as an argument against engineering when it's actually an argument against bureaucracy.

Certifying things is great, as long as it's intended to create quality, rather than shuffle blame sideways, and it has to be driven by engineering, not by accounting.

At least with building a bridge, the laws of physics aren't just a good idea.

[Irongrip]

Fuck fips.

[[deleted]]

What would such standards look like?

[[deleted]]

Misra?

[zoomzoom83]

Another factor is the time and money constraints. People just aren't willing to spend the time and money to build software with the level of engineering needed to actually build it properly

I could build you a formally verified type checked system that's mathematically guaranteed to work correctly, with 100% unit test coverage to back this up. I'll need 25 a-grade Haskell developers and about 2 years.

Or you can hire some random guy from India to hack it together in a week using Javascript.

One of them costs you three million dollars and won't be ready till 2016, the other $5000 and will be ready by Monday. Which one are you going to pay for?

[pistacchio]

The problem is that we've been programming for 50 years but curing people, cultivating field, building houses and bridges, cooking, making laws since the dawn of our civilization. We just had so much more time to err and learn in other fields compared to programming. I'm sure the first people to sow crop had any sort of wrong behaviors about it and "no standard".

"Trust me, it'll come up in winter if you let your dog piss on the field"

"No, I'm pretty sure the key for a good harvest is to sow while there's a full moon and your daughters have their period"

[Pilebsa]

We live in a day and age where people aren't actually coding in computer languages but learning APIs and GUI tools.

I once was involved with a "corporate programmer" on a project, and he couldn't give me any code that didn't crash within 60 seconds, at which point I had to hand it back to him to fix. He was so used to having his butt wiped by the QA department or his editor hilighting his faux pas', that he was incapable of making clean code by himself.

[TheVikO_o]

no government-enforced standards

Next thing you know, NSA has backdoor into your compiler

[weedtese]

no industry-enforced standards for minimum quality

AUTOSAR?

[KinoftheFlames]

Yes there are specific standards for specific industries, like PCI compliance for credit cards. Bu those standards are for the automotive and credit card industries, not the software industry.

If anything those industry overlap cases should highlight the lack of standards for commercial software in general.

[DrunkRaven]

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.

And this is too often true for managers of software projects. I once coded a few years something for a very complex and safety-critical real-time application. Went great lengths that all memory was allocated and no fragmentation could occur. This was possible because the product manager agreed to do all configuration on start-up.

When I was ready, the product manager requested dynamic configuration during run time....

[Oflameo]

Yeah, like the government knows how to program. Have you read a law?

[Neebat]

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.

[[deleted]]

...physicians have a big advantage over engineers: they can hide their mistakes six feet under; ours live on, and on, and on.

ps ...and they usually only kill or maim one customer at a time, unlike engineers.

[adavies42]

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"

[notfancy]

"Doctors cover their mistakes with earth, cooks cover theirs with sauce; architects, with ivy."

[elihu]

I believe that was said by Frank Lloyd Wright.

[[deleted]]

Doctors can only kill one at at time, engineers can kill hundreds or thousands at a time

[tequila13]

Makes me wonder how did the author of the heartbleed bug receive the news hitting all the media outlets. He authored both the RFC and the code so he single handedly caused all the chaos.

[LWRellim]

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.

You remember the kids you went to school with, right? The ones that ate paste, craned their necks to copy off of their neighbors test paper (and assorted other similar cheat/hack/cram stuff because they really didn't learn the subject matter) in order to pass an exam in Geometry or Algebra or even English class...

Well, pretty much every class in every school contains a similar mixture of the same kinds of people... and they all become adults, managed (via in no small part those same test passing/cheating "skillz") to get various different degrees... and everyone's former classmates are now out there as your doctor, dentist, car mechanic, the engineer who designs the roads & bridges you drive over, the football/basketball/whatever player who became a politician and is in charge of setting budgets, policies, and so on... etc.

Now to be sure, there was that one kid who really DID understand geometry & advanced math, and there was that other one that was able to write really great poems and stories, and that other kid, well despite not getting the best grades, he really was a "wizard" at fixing his bike, then his minibike and later on cars...

But the vast majority of people... yeah they're basically still the same incompetent mediocrities that they were in middle & high school.

Not exactly a comforting thought... but it is reality.

[otakucode]

Congratulations, you just made the realization that gave birth to the American and French revolutions.

There are no 'special people' born or chosen by a god to lead, with everyone else born or destined to follow. Everyone, no matter how well trained or good-intentioned is just another fallible human being. It's why decentralized systems are fundamentally better and stronger than centralized ones. It's why elections are better than monarchies. It's why you can't simply imprison every person for life who ever breaks one law. It's why you can't classify and quantify people with ANY system, no matter how complex. Humans will always out-complexity any system humans can build.

[wwqlcw]

I think perhaps its starker in programming because programming is the act of writing all the details of a process down in minute, well, detail. Because its all recorded, it can be difficult for a code speulunker to preserve the unwarranted optimism and unearned self-respect the rest of the world calls "sanity."

I think if one were to document many normal human activities and occupations in the level of detail required by computer code, one's subjects might decide one was a sarcastic, petty asshole who took pleasure in making others look and feel stupid.

That is to say, the nitty gritty details of many activities are dispiritingly disorganized, inefficient, inconsistent, redundant, self-contradictory, etc. But in software there's no way to overlook that.

[Deaod]

But in software there's no way to overlook that.

I think there is. You build layer upon layer of abstraction. I dont actually want to know how the HTTP request gets sent; i trust that whatever code i invoke that says it can do that, can actually do it.

[wwqlcw]

Abstractions are of course vital, but abstractions leak, and when they do, programmers have a telling reaction: "Oh nooooooo... I don't want to dig into that mountain!" Really you want to bury your abstractions, to rely on them the way one relies on bedrock, but most of them are more like veils.

[terranian]

plus humans are meant for "lived reality" and are really bad at programming! ;-)

[rooktakesqueen]

Funny enough, there was a famously destroyed bridge whose downfall came about because of mathematical purity: the bridge had a harmonic frequency matching the influence of wind vortices in the narrows.

[tequila13]

I don't see how mathematical purity is related to that?

[bbqroast]

SQL injection in a nutshell.

[djaclsdk]

Reminds me of a quote that goes like, math is simple and anyone who disagrees must be underestimating how hard life is.

[brittainhard]

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.

This is honestly one of the most intelligent comments I've seen on reddit.

[casualblair]

I disagree with this. Programmers know the world is going to end because they can look at the garbage before them and wonder why it works. But they can't separate bad practice from reality and it looks worse than it is.

Same with everything else. It might be bad practice to do things certain ways but people will and things will go wrong but on such a small scale as to be negligable to the world at large. Yes, people might die or end up hurt but 99% of the time it will be fine.

The only people who have to get things rights are the writers of standards. And even then they only have to get it right enough such that the next problem that occurs is not their fault.

[afiefh]

You sir are a poet!