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

Programmers who want to change how we code before catastrophe strikes

theatlantic.com

Post reply on HN
Print view View original

121–130 of 274 posts

Re: Programmers who want to change how we code before catastrophe strikes

#121

Post by coldtea »

hwayne wrote: post #98
coldtea wrote: post #73

Earlier quoted context omitted.

>* Hang on. Sure, all engineering has hurdles. But how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? We hold civil engineers responsible when bridges collapse unprompted. We also hold them responsible if their bridges fail from some minor, anticipated harm like vandalism or a car cr…

How many software projects have to deal with gravity? Weather patterns? How many software projects need teams of construction workers to actually build? Different kinds of engineering have different requirements. Just because the challenges in software are different from those in building bridges doesn't mean we get a free pass on correctness.

>How many software projects have to deal with gravity?

Gravity comes with a pretty little equation, and as far as problems goes is as predictable as it comes.

Tolerances of various materials are also well known in advance, and their behavior under different designs and with different levels of stress assigned can be trivially modeled with CAD packages (and even manually).

Same for weather. It comes down to a few behaviors (rain, wind, earthquakes of various degrees, sunlight) that people can model, and have been modeling for ages. We have 25+ centuries old buildings that still stand.

>How many software projects need teams of construction workers to actually build?

Not sure what you even mean here.

>Different kinds of engineering have different requirements.

That's obvious. The question we ask here is different: sure they are different, but are those requirements equally well defined and equally difficult across software and other engineering fields (like construction)?

And to that I say no. Construction has pretty solid, rarely changing requirements (and almost never changing ONCE construction has begun), and works with specific materials with a limited set of interaction. With software modeling the entire universe is the limit as far as complexity goes.

Re: Programmers who want to change how we code before catastrophe strikes

#122

Post by jkaptur »

tasuki wrote: post #85

I'm surprised understanding the domain hasn't been mentioned. Whether I am developing for someone else or for myself, it turns out misunderstanding/misrepresenting the domain is the most common source of trouble. If your understanding of the domain isn't thorough, is TLA+ going to be much help?

> “The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with requirements, not coding errors.”

Did you mean something different from that?

Re: Programmers who want to change how we code before catastrophe strikes

#123

Post by BeetleB »

hwayne wrote: post #98
coldtea wrote: post #73

Earlier quoted context omitted.

>* Hang on. Sure, all engineering has hurdles. But how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? We hold civil engineers responsible when bridges collapse unprompted. We also hold them responsible if their bridges fail from some minor, anticipated harm like vandalism or a car cr…

How many software projects have to deal with gravity? Weather patterns? How many software projects need teams of construction workers to actually build? Different kinds of engineering have different requirements. Just because the challenges in software are different from those in building bridges doesn't mean we get a free pass on correctness.

>How many software projects have to deal with gravity?

A better question is: How many civil engineers need to deal with the fact that gravity keeps changing?

The nice thing about most engineering is that the laws of physics are assumed to be constant.

A program's universe is the hardware it runs on. When that hardware changes, the equivalent of the laws of physics changes.

Amount of RAM, clock speed, number of cores, cache size, etc are all things that you can't assume as constant. Real engineers need not worry too much about deadlocks the way we have to for software. If you have physically moving objects, you can easily design to have things synchronized (gravity doesn't change, friction won't change much, etc).

I have plenty of old software that won't work properly on today's PC's because they can't run on fast computers.

Re: Programmers who want to change how we code before catastrophe strikes

#124

Post by toss1 »

Bartweiss wrote: post #43
chroem- wrote: post #24

The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…

> The only difference is that these other engineers are motivated to be significantly more thorough about their jobs. Hang on. Sure, all engineering has hurdles. But how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? We hold civil engineers responsible when bridges collapse unprompte…

>> how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that?

Every bit of military hardware, or child's toy, for starters.

More generally, you cite anticipated harm from vandalism or car crashes as being part of the general environment.

It is far past time to recognize that the hacking environment in which we live IS THE NORMAL ENVIRONMENT, and these hacks ARE everyday anticipated harm.

Software does not live in a virtual vacuum of space. It is on the internet, and will likely be scanned withing seconds if unprotected. Even tall buildings are now designed after 9/11 to better withstand jetliners crashing into them. To follow your metaphor, most of the hacks are completely unsophisticated, the equivalent of a bridge falling because some kid came along with a can of spray paint, or a screwdriver and started pulling screws.

Let's also not pretend that other engineering disciplines doesn't also have to face real-world unpredictable and hostile inputs. Even children's toys have to be designed so as not to be hazardous from persistent, random, and clever unexpected attempts at use, misuse, and abuse from children.

The same thing for consumer tools, which have many design features to frustrate the unending supply of clever idiots out there trying to win Darwin awards and sue you if they fail (or their families if they succeed).

I've done both software and hardware, and your expressed attitude that software is somehow inherently more difficult or threatened is utter nonsense. The only basis for this is impatient project management where the key priority is to to ship yesterday because the management are idiots and think software is trivial.

These approaches to start slinging code, write it fast and change it often are useful only for prototyping. In writing real software, my first two steps are 1) understand your problem in depth, and 2) work very hard for a long time to avoid writing code (i.e., better architecture to simplify, separate dependencies, etc.++). After substantial effort is put into those, then write only the code that is necessary. I take a similar approach to manufacturing, understand it, design a process with minimal key elements, then build those.

Software is not a 'special snowflake'.

Re: Programmers who want to change how we code before catastrophe strikes

#125

Post by AnimalMuppet »

ScottBurson wrote: post #92
AnimalMuppet wrote: post #86

Earlier quoted context omitted.

How long have you worked as a professional programmer? Because you sound like a just-out-of-school idealist with an idea of the "right way to do it". That ideal tends to get blunted after a decade or two of experience in the real world. In particular: Set theory ? I don't want to program using set theory for the same reason that I don't want to program using octal - it's the wrong level of abstraction for what we're…

I don't know what kind of code you've been writing, but I've been working in compilers and static analysis for decades, and set theory is exactly the right tool for the job. I don't imagine it's the only thing you would ever need for any kind of programming, but I bet there aren't many kinds of programming to which it is entirely irrelevant.

For static analysis, OK. For a compiler, OK. But I want the static analyzer and the compiler to do that so that I don't have to - I don't want to have to think in set theory to program.

And in saying that, I see that I was probably unfair to haskellandchill's point. The claim wasn't that I needed set theory; the claim was that the tools needed it (at least, so it appears to me on re-reading).

Re: Programmers who want to change how we code before catastrophe strikes

#126

Post by tasuki »

hwayne wrote: post #95
tasuki wrote: post #85

I'm surprised understanding the domain hasn't been mentioned. Whether I am developing for someone else or for myself, it turns out misunderstanding/misrepresenting the domain is the most common source of trouble. If your understanding of the domain isn't thorough, is TLA+ going to be much help?

It helps in two ways: 1) You have to specify your system, right? With TLA+, you can just wave you hands and say "okay this part does something, I guess." You have to force yourself to understand what, exactly, you want your system to do and what you want out of it. 2) Most systems have edge cases, side effects, and race conditions. Are you sure your design is robust against them? You might think you have good argumen…

Good points!

Writing unit tests before code can help avoid mistakes in the interface design.

Perhaps similarly, writing formal specification could expose the holes in your domain understanding.

Re: Programmers who want to change how we code before catastrophe strikes

#127

Post by AnimalMuppet »

haskellandchill wrote: post #100
AnimalMuppet wrote: post #86

Earlier quoted context omitted.

How long have you worked as a professional programmer? Because you sound like a just-out-of-school idealist with an idea of the "right way to do it". That ideal tends to get blunted after a decade or two of experience in the real world. In particular: Set theory ? I don't want to program using set theory for the same reason that I don't want to program using octal - it's the wrong level of abstraction for what we're…

8 years of web dev under my belt, but yes I do have some academic pedigree and have been investing my time heavily in the history and techniques of formal methods. I'm hoping to contribute to bridging the gap. Don't get too hung up on set theory, I was just referencing the article.

It is my impression (as an outsider) that web programming might be the hardest environment for formal methods. Yes, I could see formal methods proving that only valid HTML was ever emitted. But how do you prove that your layout aligns on Firefox 55.0.3?

So it seems to me that, if you can make progress on formal methods in your environment, you're not picking low-hanging fruit...

Re: Programmers who want to change how we code before catastrophe strikes

#128

Post by worldsayshi »

insertnickname wrote: post #48
p0nce wrote: post #32

This gives an idea for an interesting tax. Every (money-making) codebase should cost money commensurate to the number of LOC.

It'll just encourage companies to rewrite all their software as one line of Perl.

Perhaps it should be taxed by number of conditional branches then?

Re: Programmers who want to change how we code before catastrophe strikes

#129

Post by tasuki »

jkaptur wrote: post #122
tasuki wrote: post #85

I'm surprised understanding the domain hasn't been mentioned. Whether I am developing for someone else or for myself, it turns out misunderstanding/misrepresenting the domain is the most common source of trouble. If your understanding of the domain isn't thorough, is TLA+ going to be much help?

> “The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with…

Well spotted - missed that!

Though I think the "and don’t care to" part is a little harsh. I do care, though mostly fail. Sometimes I find it difficult to get useful information from the domain experts, and it doesn't help that domain experts often keep subtly changing the meaning of the concepts we've been working with, until nothing is left of the original and the whole system is a bit of a mess.

Re: Programmers who want to change how we code before catastrophe strikes

#130

Post by freshhawk »

fusiongyro wrote: post #119
valuearb wrote: post #104

"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round…

I feel like this is part of why Brooks says build the first one to throw away, because you're going to. People seem quite unable to imagine life with a program that doesn't exist. Building a more precise specification would be valuable if people were really able to evaluate the specification as if it were a program, but they don't seem to be able to do that. So we wind up building the whole thing to see if it's right…

They are able to do that. But, unlike the physical world, it's really expensive compared to just building a virtual one first. And then really tempting to just use that prototype, or patch it up.

If it was super cheap and easy and almost free to build things in the physical world we'd probably do the same thing and just skip the architecture and wing it.

Post reply on HN