I'd say build the feature and deal with the consequences in an evolutionary fashion. To use your flying car example, if everybody bought a flying car, there would quickly arise a need for regulation and airspace control - and that need would just as quickly be filled. Even in your hypothetical situation where there's no mechanism for regulation and control, if the problem got out of hand, someone or some organization would quickly create that mechanism. The end result would be that people would have their flying cars, but only be able to operate them in a restricted but safe fashion. That's still better than not building the flying cars because you're afraid of the consequences.

So I'd say build whatever it is, and let things adapt as necessary to deal with the consequences.

You gotta love the English language. Only in English (or some other natural human language) can you create statements like this that almost seem to make sense.

My world is different -- mostly mid-sized (up to 500K or so SLOC) applications generally written in C/C++, with little to no dependence on RDBMS's. When we've used databases, we've generally kept the SQL stuff contained and well-separated from the main application.

Testing is always important, but when you're thrown into supporting an application that's been there for years (which was generally the case for me), you don't have the luxury of developing test code that's fully integrated with the application. So you write test cases -- vignettes -- that run the entire application on a set of input data, and look at the results to make sure they're what they're supposed to be. And you start building in automated unit tests into new code. It's infeasible to refactor the entire application to integrate automated unit testing, but we've had pretty good success building up large sets of automated vignettes that end up testing most of the applications' functionality. It's not perfect, but it does catch a lot of errors. And we instituted a policy that any new functionality or bug fix had to have a test case written for it before it could be incorporated into any production code. That also helped a lot.

How you do it depends on the application. Your case seems like one of the more difficult ones, since it seems you have lots of places where unpredictable inputs are injected, and you have all of the associated issues with security, robustness, etc. But for a well-designed application where external inputs are controllable, it's a lot easier.

I have to disagree. For a reasonably small app that doesn't require certification or formal acceptance testing, it doesn't have to be all-or-nothing. You can start with just a few test scripts, and build up a test suite a little at a time. There's nothing that says the test suite has to be all-encompassing, especially if you've never had one and are doing testing ad hoc. Developing a complete test infrastructure from scratch can be a bit intimidating, but it's a lot easier if you start small and build it up. Eventually you'll have to refactor the test suite (most likely to improve automation and make it easier to write & integrate new tests), but by then you'll have a good idea exactly what you need to do. Also, depending on the app, there are a number of 3rd party test tools that make it easier to set up a test suite. These may or may not be applicable, but it might be worth looking into.

To convince the owner (the one who's paying the bills), you need to make an economic argument. That means you need to estimate both the cost to develop the test suite and the savings you'd get from it. This in turn means two things. First, the initial estimate - you'll need to guess how much it time it will take to write the test suite (that's one reason to start a little at a time - it keeps costs down), and how much time you currently spend fixing bugs you've seen before or that would have been caught by a test suite. You'll also need to take a guess at how many of those would be fixed with a test suite, both in the short term (when the test suite is immature) and in the long term (when it has matured). Second, it means you'll have to start collecting data to back up your estimates. How much time do you spend fixing bugs in the delivered product? What sort of bugs (i.e., would they have been caught earlier)? How much time do you spend on new development? During development, how much time is spent fixing bugs in new code, and at what stage do you find the bugs (unit testing level, integration, system?). With data like that, you can make a pretty strong argument.

One more thing: you may not be in a position to do this, but any data on customer satisfaction would also be helpful. Lacking data, you could make an argument based on anecdotal evidence, but this gets risky. In any case, all this would go into the "savings" part of the argument (which is really the ROI).

One final comment - reading between the lines, I'm wondering if it's worth paying a bit more attention to configuration management. Keeping track of exactly who has touched the code, when, and for what reason, plus the whole revision history, can really help with making sure bugs don't reappear and to quickly fix it when they do. I don't know if CM is an issue in this case, but it's critical to have solid CM - not just for development, but also for a test suite.

Not really. It's an electroweak process that actually creates the particle-antiparticle pair.

No. "Decay" implies a weak interaction. And the weak force only interacts with left-handed particles (or more precisely with the left-handed fields, or components, of a particle).

The Higgs field can couple the left- and right-handed fields of a particle. But when you're talking about "Higgs particle decay", that's a weak interaction, which is only left-handed.

That's why you can't have a purely left- or right-handed massive particle. Any massive particle (like an electron) has to have both a left-handed and a right-handed (chiral) component. It also has to be invariant under Lorentz transformations, meaning that as you change reference frames, the particle looks the same. Only massless particles can be purely left-handed or right-handed, and for them chirality and helicity are equal. But not for massive particles.

By the way, the evidence of neutrino oscillations means that the three Standard Model neutrinos must have some non-zero mass, which means they're not purely left-handed. They were once thought to be purely left-handed, but that was when they were thought to be massless. Now we know that they're more like electrons, with a left- and right-handed component.

Your reasoning looks pretty sound to me; I don't think there is a fundamental reason to assume that right-handed neutrinos don't exist. I think the main reason people make that assumption is that there is no experimental evidence for it. It appears that the weak force only acts on left-handed particles

You're right in that a right-handed neutrino would interact only gravitationally. But if they exist, how did they get created in the first place? That creation process had to involve some combination of the other 3 forces -- gravity doesn't allow for particle creation or decay.

Another thing is that if it were massive (and it would have to be), it would have to have a left and right-handed component, and be invariant under Lorentz transformations. (One way to think about it is this: If it's moving in a certain direction, you could look at it from a reference frame moving even faster in that direction, and it would appear to be going the other way. This would change it from a right-handed to a left-handed particle, which would mean it could interact with the weak force, etc. etc. So it would have to be a mixture of both left- and right-handed components - you can't have a purely right-handed neutrino with a non-zero mass).

It also turns out (mathematically) that you can construct a (sterile) neutrino by using only left-handed fields, and still make it behave as if it had a right-handed component. This is the so-called "Majorana spinor". So you don't really need to invoke right-handed neutrinos, you can get the same result using just the left-handed fields.

Well, IAAFPP (I Am A Former Particle Physicist, now no longer active in the field), and you have to be careful what you mean by "neutrino". In the Standard Model, neutrinos are partners to the charged leptons: electron, muon, or tau lepton. By "partner to", I mean connected (in a sense) by the weak force, which is the only non-gravitational force that acts on them (being neutral, they are immune to the electromagnetic force, and being leptons, they don't feel the strong force). Neutrinos are also very light, having near-zero mass.

This is what the Standard Model calls a neutrino. And there are, in fact, only 3 kinds. This was shown pretty convincingly by LEP at CERN. And it's also enough to discredit Heim's Theory (which no one really took seriously in the first place).

What this story is suggesting is that there may be a different kind of neutrino -- a so-called "sterile neutrino" -- that doesn't even feel the weak force. This isn't part of the Standard Model, but it is possible in certain extensions of the SM. This kind of neutrino doesn't act the same way as the SM neutrinos; it's a different beast, and comes about through a different part of the mathematics.

The best programming course I've had (a long, long time ago) was 6.001 at MIT. One of the things that made it successful was that they didn't focus on the language (Scheme); they focused instead on the underlying programming concepts.

In order to make this work, you have to use an interpreted language (such as Python, which is trivial to learn and translates well into most other common languages) for assignments and projects. This allows students to try different ways of doing things without getting too hung up on syntax, and helps them focus on what they're trying to do instead of how to use the language.