Live data from Hacker News

The Power of Ten – Rules for Developing Safety Critical Code

spinroot.com

101–110 of 155 posts

Re: The Power of Ten – Rules for Developing Safety Critical Code

#101
post #89
post #42

Earlier quoted context omitted.

> ... it doesn't matter if a competitor ships buggy RoR-based systems a few months earlier. You hit the nail on the head! However, I would like to mention that competition is only one very important factor. I'd add that IT is a cost as it is a baker for a bakery, a cook for a restaurant, a mechanic for a repair shop. Do you want to be the n.1 restaurant? Then you must pay, so that your business is good food , not mar…

> Do you want to be the n.1 restaurant? Depends on what you mean by "n.1". The "n.1" restaurant in terms of monetary value is McDonalds. They do market (heavily). They don't pay for the best cook (not anywhere near). And they don't have the best recipes. But they are wildly successful. Conversely, michelin star restaurants go bankrupt all the time. There's nothing wrong with aspiring to produce michelin star code. Bu…

Aside from marketing, which you mentioned, the quality McDonald's pays for is standardization.

Standardization is why chain restaurants exist at all. They give people a way to get a meal they know is going to be of a certain quality at a certain price with a sufficiently low probability of being surprised. Surprises are, on the whole, generally negative: Good restaurants are few and far between, especially at the fast food price point, and a sufficiently bad surprise can have health implications. There's a reason one of the first chains was White Castle: White implies purity and a standard of cleanliness, as opposed to the local greasy spoon cafe where the only assurance of quality is that it hasn't been shut down yet.

So McDonald's pays for processes and materials that it can blast out into a million little restaurants, all the same, secure in the knowledge that minimum-wage workers can be sufficiently skilled and motivated to carry out those processes and use those materials the right way. Doing anything better might lead to a much improved experience in some restaurants but it will reliably lead to total disaster in others, which is utterly contrary to the business model.

By that standard, McDonald's is fairly high quality.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#102
post #89
post #42

Earlier quoted context omitted.

> ... it doesn't matter if a competitor ships buggy RoR-based systems a few months earlier. You hit the nail on the head! However, I would like to mention that competition is only one very important factor. I'd add that IT is a cost as it is a baker for a bakery, a cook for a restaurant, a mechanic for a repair shop. Do you want to be the n.1 restaurant? Then you must pay, so that your business is good food , not mar…

> Do you want to be the n.1 restaurant? Depends on what you mean by "n.1". The "n.1" restaurant in terms of monetary value is McDonalds. They do market (heavily). They don't pay for the best cook (not anywhere near). And they don't have the best recipes. But they are wildly successful. Conversely, michelin star restaurants go bankrupt all the time. There's nothing wrong with aspiring to produce michelin star code. Bu…

McDonalds has an executive chef with a high-end restaurant background.[1] He heads a team of other chefs. Their job is to design and test recipes that can reliably be implemented by following the directions.

[1] https://en.wikipedia.org/wiki/Dan_Coudreaut

Re: The Power of Ten – Rules for Developing Safety Critical Code

#103

> a function shouldn’t have more than 60 lines of code. I started having headache spikes after reading this sentence that refers to keeping functions "short", in the article about safety critical programs.

Keep in mind that we're talking about C code here. Error handling etc. blows that up quite significantly.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#104
post #89

Earlier quoted context omitted.

> Do you want to be the n.1 restaurant? Depends on what you mean by "n.1". The "n.1" restaurant in terms of monetary value is McDonalds. They do market (heavily). They don't pay for the best cook (not anywhere near). And they don't have the best recipes. But they are wildly successful. Conversely, michelin star restaurants go bankrupt all the time. There's nothing wrong with aspiring to produce michelin star code. Bu…

> The "n.1" restaurant in terms of monetary value is McDonalds. No, the No. 1 franchised chain of restaurants is McDonald's; there's a pretty big difference between the No. 1 restaurant and the No. 1 chain of restaurants . > But they are wildly successful. The chain has, over its lifetime, been wildly successful, a success initially fueled by a reputation for extremely high quality , consistency, and efficient servic…

McDonals is the Ford of restaurants. Automation (using procedures and equipment) to reduce cost and keep a consistent relatively high level of quality.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#105
post #37

Earlier quoted context omitted.

Type based programming does not quite work in weakly typed languages.

I think you should take what he said as saying we should get rid of those

> get rid of those

There are many legitimate uses for scripting languages. It would be impossible and undesirable to get rid of them.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#106
post #99

Recently there was a thread here where many argued against some company owner that has set the objective that the code created by his employees should be as simple as possible. Often the arguments boiled down to: It looks only clever if the skill level of your employees is too low, you should work on that. When I look now at the rules that NASA enforces, it seems to me that their objective is to prevent bugs by not a…

It seems that people often confuse complex with clever or impressive. Impressive is unifying the falling of an apple with the orbiting of the planets into three simple universal laws. Complexity is an emergent phenomenon. It occurs when there are too many interactions to track. To make something simple is to take all of that complexity and to understand and model it as the interaction of a few simple rules repeated o…

Great analogy, I agree!

Re: The Power of Ten – Rules for Developing Safety Critical Code

#107
post #54

Earlier quoted context omitted.

In my experience that what's will happen in practice, especially when there is a specific metric attached. Doubly so once there is a mechanically enforced required amount of assertions. Wouldn't it be better if we could create programs that were correct by construction (and thus needed no assertions)?

I see — your experience suggests that rules inevitably get turned into thoughtlessly evaluated metrics that then get gamed. It is a shame when that happens, but when it does, it's not the fault of the rules, it's the fault of the organizational culture. The rules would still be valuable if you used them thoughtfully and with the aim of improving the reliability of the product, not gaming some management system.

I don't think they're intentionally gamed, it's just part of human nature. If you don't have to defend your assertions (because more assertions is presumed better, as per the rules), then people are liable to err on the side of putting more in that they need to.

With the exception of assert(ptr != NULL) assertions, I think most of the ones I've hit have actually been completely duff, and with some thought could just be removed. I dread to think what would happen if I grepped the commit histories of all the projects I've worked on for "removed duff assert".

Re: The Power of Ten – Rules for Developing Safety Critical Code

#108

Earlier quoted context omitted.

If I grasp that right, it says that if something is provable mathematically, then you can write a program for it with an equal meaning. I still don't see how that prevents user error. My question is then how do you mathematically prove intent? Also, how far should "sufficiently advanced" be? We already have a tool for that in the forms of unit tests and types does help if the subject is abstract enough.

You can't prove intent. However, you can consider the formal specification of your intent (the type), to be an example of fully declarative programming. Since you write your type without any care about how it might be executed -- the holy grail of abstraction -- you are less likely to make errors. When using a type system that isn't capable of fully specifying what you're doing (i.e. Haskell), you are of course subje…

> However, you can consider the formal specification of your intent (the type), to be an example of fully declarative programming.

The vast majority of formal specification and verification tools (I believe Coq and Agda are the only exceptions, and they are rarely used in the industry) express the intent directly in logic rather than in the types (HOL in Isabelle and HOL Light, ZFC+LTL in TLA+ and maybe Scade, ZFC in Alloy, and a typed set theory in SPARK, I believe).

> But in practice it's usually enough to catch the sorts of mistakes that you're likely to make.

I think this claim is supported by little evidence. Most non-dependent type systems are extremely weak (or require cumbersome encoding) to express even all but the most trivial of properties (e.g. they can't even express that the value returned from a max function is indeed maximal, let alone more elaborate properties). Their expressive strength is that of a finite-state machine. How much does that prevent real bugs requires empirical study.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#109

Earlier quoted context omitted.

I think you should take what he said as saying we should get rid of those

> get rid of those There are many legitimate uses for scripting languages. It would be impossible and undesirable to get rid of them.

Scripting languages are just that, for plain scripts, not full blown applications.
Post reply on HN