Inductive Reasoning

Inductive reasoning, also known as induction or inductive logic, is a type of reasoning that involves moving from a set of specific facts to a general conclusion. The problem with induction is the whether inductive reasoning leads to knowledge... or only the illusion of knowledge.

Is it correct to generalize about the properties of a class of objects based on some number of observations of particular instances of that class? Is it correct to presuppose that a sequence of events in the future will occur as it always has in the past?

Inductive reasoning may be reason so many software project fail: We build a the model for the software based on knowledge we obtained via inductive reasoning, and then a BlackSwan arrives that makes our model invalid. Sometimes the impact is so strong that all the effort of months may crumble in to pieces in a matter of seconds... the funny (or very sad) thing is that BlackSwan failure is so common in software development that we should have found better ways to deal with by now... but we just haven't.

Domain models - the elements, their relationships, and even the rules guiding them - should be considered a point of change in any software project that requires them. You should, therefore, favor representing these models in a manner that allows them to change independently of the processes that control when and which modeling occurs and what happens before and after. That way, when the BlackSwan arrives and you have to change your model, that is all you need to change. It helps to favor a discipline or paradigm suited to such modeling, such as LogicProgramming or ConstraintProgramming or TermRewriting, as many such paradigms are much more efficient than ObjectOrientedProgramming when the purpose is to tweak the elements, the relationships, or the rules (behavior, physics, etc.). We do have decent ways to handle the BlackSwan failure, so long as you keep these issues in mind. Learn about InformLanguage (http://www.inform7.com), if you are short on inspiration.

I don't believe BlackSwan issues are a great cause of failure, at least in applications and services. YouAintGonnaNeedIt would tell you to avoid the BlackSwan until you do need it; a working product early without black swans is superior to a product with black swans coming late or never. I'll grant that SystemsSoftware (including FrameWorks) should include an 'in' to deal with the 'generic' components (i.e. white swans, pink flamingos, cows, hippopotamuses, and everything else). But, so long as you ensure the 'generic' case is also a rare one (in the 'deep inner performance loop' sense, not the 'amount of dedicated code' sense), it doesn't need to be handled superbly well. You can, in the future, optimize and clean up handling of the most common 'general' cases without breaking backwards compatibility.

But.. how can you ensure the 'generic' case is also a rare one? After all the InductiveReasoning that leads you to believe that a particular case is rare might be flawed... and that could be precisely the mistake the BlackSwan uses to kill your project
If you are uninformed about your domain, simply follow YouAintGonnaNeedIt. Everything starts in the generic case until it proves itself both common and suitable for whatever optimizations and other features that specialization might buy you. The BlackSwan is just another generic case until such a time as you have huge flocks of BlackSwans. But, for most SystemsSoftware, you can reason about known common cases by looking at how existing software is already used. I.e. look at the competition, including previous versions of the same software!

I think a greater risk for most projects the features we include, rather than those we miss. It is easier to add features than to remove them. And, after having had a feature for some time, you may later learn that it could have been achieved 'better' (for some measure of 'better') in a subtly different way... but, for various reasons, you are stuck with the current design. Application software can usually handle a considerable amount of FeatureCreep before collapsing under its own bloat and demanding a rewrite. SystemsSoftware, such as OperatingSystems and LanguageDesign, are considerably less tolerant; one bad feature choices can break all sorts of things (security, safety, performance, etc.) due to FeatureInteraction.

See BlackSwanTheory, OopNotForDomainModeling, MultiMethodsDiscussion, ObjectVsModel,