At what step in your mulit-tiered review system does it usually occur to that you're not writing for publishing, but partaking in a online discussion? How often did you decide your phrasing does not fit the purpose and started over? How often did the discussion move along to other sub-threads and your carefully worded post ignored?

You make some good point. Howevr, imagine the following not uncommon scenario:

1. A small number of experienced developers starts a project
2. The devs choose to build their own framework for the reasons you describe
3. PM wants ever more features, the project grows, more developers join
4. All new code is build on the framework made in step 2
5. Framework is extended
6. Original devs leave

So now everyone can use the framework, but it's original devs stopped maintaining it. Everyone know how to use the framework, but nobody knows its inner workings well enough - we have a custom, still lightweight framework tailored for the job, but nobody's maintaining it. The worst of both worlds, a framework maintained by people you can't rely on to understand it and fix its bugs, and the initial investment to build it in the first place.

In the end, you're right, there is no clearly defined criteria for which approach is better than the other, both ways has a very good chance to bite you in the ass. My perspective however, not as a developers of production systems but a software testing engineer (writing code to break other people's code ;)), what I see is bugs, bugs everywhere. Hardly any new feature, however straight forward it appears in its original specs, that's not can of worms of new and exciting issues. That's why I'm very skeptical of using new code when existing, already tested code exists.

This is hard to prove or disprove. Sure, throwing some huge framework on a small problem is not a sensible approach. Seems like a no-brainer. But where to draw the line? A real life application constantly grows, and has a good chance to eventually use a growing percentage of the features exposed by a given framework. If you know your application will not outgrow its initial specs (in an unexpected way), it might make sense to opt for an own framework.

My personal experience, however, is that developers too often opt for their own solutions, maybe due some kind of not invented here syndrome, and duplicate a lot of work. That is bad in a lot of ways, as a well maintained framework with multiple developers and documented bugs is always preferable to completely new code.

Indeed, that's a distinct possibility. Still wouldn't say that guy panicked - going at ~200 km/h with the perception of having no control is a corner case for the human psyche, and he made it through.

If that was the AC's point, he didn't bring it across in any sensible way. He literally said "I code everything by hand", and that's plain stupid.

Usually, frameworks are not written and maintained by one person. And thus, you are free to worry about your own code and its bugs, and have others worry about the framework's bugs (within reason, for crucial bugs you will of course need to worry about finding a viable workaround). Code reuse is a good thing, and no single person is smarter than > 1 person.

Also, frameworks do not usually change completely in less than a year, and the change that does happen is gradual - as long as you keep the framework you use up to date the learning curve is flat.

Hehe, yeah, you're sooo much smarter than those idiots who wrote this framework with the sole purpose to enable other idiots to take shortcuts instead of doing things properly[tm]. Anyways, "Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans."

I don't know about that specific case, but from your description it doesn't apply to my argument: Either the car worked and the guy was joyriding, which isn't panicking, just general douchebaggyness, or the car did indeed fail, and the guy killed neither himself nor anyone else, which also isn't panicking.

Generally yes, in most cases the guy operating the "failing" machine is himself the point of failure. But that doesn't mean that's always the case.

As you understand the argument on bad road conditions, all that's left is a situation where the road condition turns from bad to worse unexpectedly. Shifting back into gear still takes some time. Plus, using the hydraulic brakes where the engine brake would do causes additional wear. However, I don't know how much wear would warrant how much additional fuel intake.

Provided the car did indeed work, maybe. However, had he really panicked he would have crashed his car into the next concrete wall. Instead, he managed to keep it on the road, not crash it, and call emergency services. Not exactly the signs of mental problems.

While those stats are interesting, it doesn't matter. It's not enough to warrant the loss in vehicle control you get by detaching your engine from the drivetrain.

Well, that guy made it through an hour of uncontrolled cruising at high speeds. I think it's safe to say his mind works well enough. Many, maybe most, people I know would panic.

Steering lock is not the same thing as non-powered steering.

Interesting. However, we need to figure out what the car will do at high speeds. One could argue that it's a bad idea to turn off the engine then, as it will leave all control of the vehicle to the brakes (plus inertia and friction of course) - provided there is no such critical malfunction of course. The brakes in the story did not work with the engine running, no way to know how they would react without engine power.

It's dangerous to get turn your car into a very heavy soapbox. You are left with only your brakes to control your speed, overusing them unnecessarily, and as you said, actually accelerating requires you to match the rpm (and gear) to the actual speed first. Just not accelerating will let the wheels keep the engine at the correct rpms. Plus, as superdave80 said, modern cars stop fuel intake when not using the acceleration pedal.