The Book of Fallacies

Objectives

Whereas the design side of software engineering has made significant advances since the arrival of Object Oriented approaches, thanks mainly to the Gang of Four and others proponents of design patterns, it’s difficult to see much progress on the other (and opening) side of the engineering process, namely requirements and analysis. Such imbalance creates a bottleneck that significantly hampers potential benefits, and our understanding of requirements should be reassessed in order to align external and internal systems descriptions;  in other words, to put under a single modeling roof business objects and processes on one hand, their system counterparts on the other hand.

Given that disproving convictions is typically easier than establishing alternative ones, it may be necessary to deal first with some fallacies that all too often clog the path to a sound assessment of system requirements. While some are no more than misunderstandings caused by ambiguous terms, others are deeply rooted in misconceptions sometimes entrenched behind walled dogmas.

Magritte’s Fallacy

Hence, to begin with a tabula rasa, some kind of negative theology is required.

Fallacy #1: Facts are not what they look like

Facts are not given but observed, which necessarily entails some observer, set on task if not with vested interests, and some apparatus, natural or made on purpose.  And if they are to be recorded, even “pure” facts observed through the naked eyes of innocent children will have to be translated into some symbolic representation.

Fallacy #2: Truth (or Objectivity) in Models

The mother of all fallacies is to think that models can describe some real-world truth. Even after Karl Popper has put such a fallacy to rest in sciences more than half a century ago, quite a few persist, looking for science in requirements or putting their hope in abstraction. Those stances cannot hold water because models reflect business and organizational concerns expressed at a given time for specific contexts. Negative theology provides an antidote: if a model cannot be proven as true, at least it should be possible to check that it cannot be falsified.

Fallacy #3: Requirements “Engineering”

Requirements are not meant to be “engineered”, otherwise there would be no difference between the system to be engineered and its requirements. Such delusion is especially dangerous as it blurs the respective responsibilities of business and system analysts and induces the latter to second-guess the former.

Fallacy #4: Object Oriented Requirements

Object Oriented approaches are meant to deal with the design of system components, not with business organization. While it may be useful to adapt object semantics and apply them to system analysis, there is no reason to assume that business contexts and concerns should be expressed along those lines: hope is no substitute for methodology.

Fallacy #5: Requirements in “natural” language

Except for plain applications (calling for trivial solutions), significant business domains rely on specific and often very formal languages which must be used for supporting system requirements. That may be illustrated with examples from avionics to finance, not to mention law.

Fallacy #6: “Conceptual” Requirements

Whatever the meaning of the adjective “conceptual”, it doesn’t fit to business. Hence, trying to bring requirements to some conceptual level is a one way ticket to misunderstandings. Business concerns are very concrete indeed, rooted in “here” and “now”, and so must be the requirements of supporting systems. Abstract (aka conceptual) descriptions will be introduced at a later stage in order to consolidate the different business concerns meant to be supported at system level.

Fallacy #7: Model is Code

If models were substitutes for code, or vice versa, that would make software engineering (and engineers) redundant. Surprisingly, the illusion that the information contained in models is the same as the one contained in programs (and vice versa) has benefited from the Model Driven Engineering paradigm whose rationale goes the opposite way, namely toward a layered perspective. A detailed rebuttal of the “model is code” fallacy can be found in Vincent Hanniet’s blog.

The same fallacy is also behind the confusion between modeling and programming languages. That distinction is not arbitrary or based on languages peculiarities, but it fulfills a well-defined purpose: programming languages target applications, modeling languages target systems.

Fallacy #8: “Pie-in-the-sky” Meta-models

As any model, a meta-model is meant to map a concern with a context. But while models are concerned with the representation of business contexts, the purpose of meta-models is the processing of other models. Missing this distinction usually triggers a “flight for abstraction” and begets models void of any anchor to business relevancy. That may happen, for example, when looking for a meta-model unifying prescriptive and descriptive models; having very different aims, they belong to different realms and can never be joined by abstraction, but only by design.

Fallacy #9: Problem/Solution Spaces

System engineering cannot be reduced to a simplistic dichotomy of problem and solution as it must solve three very different problems:

  • Business ones, e.g how to assess insurance premiums or compute missile trajectory.
  • Functional ones, how the system under consideration should help solving business problems.
  • Operational ones, i.e how the system may achieve targeted functionalities for different users, within distributed locations, under economic constraints on performances and resources.

As it happens, and not by chance, those layers are congruent with modeling ones on one hand, architectural ones on the other hand.

14 Responses to “The Book of Fallacies”

  1. Steven Fancher Says:

    GOLD…

  2. Nick Malik Says:

    Your experience tells you that these are “fallacies,” correct? What makes them fallacies? Is there any anecdotal evidence or case study or even a set of blog posts where professionals tried these techniques and they failed, or is this list based on your experience only? Can you give us, your readers, a reason to believe that your experience is specifically note-worthy?

  3. caminao Says:

    I don’t ask anybody to believe anything. Those are arguments open to refutation. Some find them convincing and corresponding to their own experience. Others don’t. But counter arguments and examples are welcome.

  4. Ron Segal Says:

    ‘The mother of all fallacies is to think that models can describe some real-world truth.’

    It depends on what is meant by ‘truth’.

    In systems engineering, models are used to represent the world as observed and to express and explore ‘a’ truth that we want to create.

    Generally, I agree with Nick, that some supporting examples would help people to better understand the issues that you are attempting to expose.

  5. caminao Says:

    Ron, I’m not sure about engineering models used to represent the world, that would belong to science. As far as engineering is concerned, descriptive models are used for requirements, and prescriptive ones for artifacts, both clearly based (biased) on (by) contexts and concerns. As for truth in models, I’m only following K.Popper position about empirical falsification.

  6. Ron Segal Says:

    Rémy, my view is somewhat different.

    To create, modify or engineer systems, start with an exploratory model of the part or aspect of the world that is of relevance.

    Models for expressing ‘what’ versus ‘how’ may be but aren’t necessarily different, rather their usage typically evolves through different phases. Initially as a scratchpad for exploring the problem, or the requirements, then for stating the problem or requirements, or whatever, then as a blueprint for specifying how the changes are to be implemented. The phases are rarely distinct, and I suspect the less distinct the better, particularly as usually different parts of a problem/requirements evolve at different rates.

    Ok, empirical falsification is pretty fundamental to scientific thinking but I don’t understand your point about models. Good ones can be used to infer facts that can then either be observed as true, indicating that the model is a sound representation of the truth as we know it, or observed as false, indicating that it is flawed in some respects.

    What I do see though (particularly in requirements analysis) is descriptive models that cannot be used to infer anything. In which case it is impossible to prove or disprove whether they represent any kind of truth beyond local consensus. Is that your point?

  7. caminao Says:

    Ron,
    When you write “the model is a sound representation of the truth as we know it”, you’re falling in some circular reasoning.
    Models are symbolic constructs meant to represent the world through the lenses of our contexts and concerns. They are all we know about the world, our only knowledge.

  8. Ron Segal Says:

    Rémy, that’s why it is the truth ‘as we know it’!

  9. Ron Segal Says:

    A model that is valid in representing our understanding of the truth, means that the model, within its scope, enables inferences that continue to be congruent with our observations.

    When I say ‘our observations’ I mean the majority of rational people.

    A model that represents a madman’s world, is probably not going to be shown by observation to be a valid representation of the truth as we know it. Of course people who believed the earth was round were considered deranged at one time, until observations about the inferences of their ‘mad model’ continued to be shown to be correct.

    • caminao Says:

      But models don’t represent “our understanding of the truth”, they are “our understanding of the truth”: all knowledge is representation. So, a “valid representation of the truth as we know it” is circular because it can only mean “a true representation of the truth as we know it”.
      About the relationships between models, knowledge and truth I like the article by Davis, Shrobe, and Szolovits (see Selected readings or the post about Knowledge Architecture.

  10. Ron Segal Says:

    By ‘representation’ I mean an expression of our understanding. My models at least are always an imperfect expression of my understanding, some worse than others, if they were perfect then I would have to agree that they ‘are’ my understanding.

    There again I was never particularly keen on philosophy so probably wouldn’t have made a very good monk or theoretical physicist!

  11. Terry Roach Says:

    I understand your point now to mean that if 3 of us were to independently produce a model of a domain it is unlikely that any of them would be identical. That I agree with, there is no “right” model of a state-of-affairs (although there could be lots of “wrong” ones).

    • caminao Says:

      Right. Requirements model cannot be validate in-vivo, and in-vitro validation is pointless. But perhaps models could be proven wrong. I’ve tried to explore the idea of “ghost models” for that purpose.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 296 other followers

%d bloggers like this: