Greg Wilson pointed me to this old (1989) IEEE Software article: Structured flowcharts outperform pseudocode: an experimental comparison by David A. Scanlan.
In the paper, the author empirically shows that significantly less time is required to comprehend algorithms represented as pseudocode flowcharts. He ended up saying “I am not suggesting that we should all
retrieve our flowchart templates from the attic, but I am suggesting that we continue to move toward graphical documentation. We must develop methods that optimally combine graphics and text”. He even says:
Flaws in previous research may have masked the superiority of structured flowcharts … for helping programmers understand algorithms
The following Figure (Fig.5 in the referenced article) reports the mean times subjects spent looking at algorithms when answering a set of test questions about them, clearly showing that the more complex the more flowcharts become a better tool.
So, as you can see, the discussion modeling vs programming (or what it is the same, about the benefits of modeling) is almost as old as computer science itself (well, I´m exaggerating a bit here, but you get the point). It’s a pity that even if some papers like this one already showed the superiority of modeling and using higher abstraction representations (at least for some tasks) a long time ago, many practitioners prefer not to listen.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Interesting to see such an old paper that is still relevant today, thanks for sharing. However, I disagree with your assessment that this results shows the superiority of modeling.
The paper investigates comprehension and not creation of code and shows that in order to understand an algorithm, a flowchart supports users better than pseudo code.
These flowcharts might be extracted from the code, with no model (driven development) involved.
Well, I agree with you that the paper does not say anything about model-driven development or code-generation but if you read my comment on the paper I talk about the superiority of modeling and refrain from more ambitious claims (in this post at least 🙂 )
Yes, this research is still relevant today.
Jordi,
there is a continuum between programming and modeling. What we see as evidence of X better then Y, is simply that some semantics of that continuum are more or less expressed in a particular formalism and therefore fit a certain class of problems better. For instance the “repair lamp” flow chart is a poorly constructed state machine, but still better than pseudo-code which cannot express state at all -without out of band conventions.
The foundational semantics of that continuum are: State, Type, Action and Relationship (STAR). Computer Science, because of it’s mathematical foundation, is generally biased towards Action at the expense of State. It is also biased towards Types over Relationships (thanks to Liskov’s Abstract Data Types and all the OO nonsense that followed). The reality is that you cannot reify states with actions and relationships with type.
Once you understand that the STAR concepts are pervasive, that the world is not just “functional” , then you establish a continuum between programming and modeling.
http://www.ebpml.org/blog2/index.php/2015/01/16/state-machines-and-computing
Computer Science and MDE will grow up one day to understand that every action leads to a state and every state enables actions (and every type has relationships and relationships have types). Computer Science makes the gross approximation that any action leads to a single state and that state enables a single actions. But that’s a bit limiting, so one day someone patched that simplistic model with an if-then-else, and voila, why would you want to make state explicit when you have if-then-else. Right?
Another more recent paper made a bit similar study by comparing modeling of features in product lines using both a graphical modeling language and a textual language.
Users of graphical modeling got more done, in less time and with fewer errors than those using text. Paper is available at http://link.springer.com/chapter/10.1007/978-3-319-11245-9_7. All I can wish is more emprirical research!