Design vs the real world

Some more on the averages thing. For Agile Geosciences (let's call that the real world), averages are a concept by itself. All sorts of averages are related by the common denominator: calculate a central tendency.

If you look in OpendTect, you'll see this implemented in a Stats::RunCalc object. In design, it is much more important what type of operation you are doing, than what it's used for. So, we have an object that can calculate running average but also min/max, standard deviation and so forth. The interesting part here is that in that object, the median is the outlier. All other operations are done in a similar way, only median requires buffering numbers and sorting.

This is a common 'problem'. The solution model (the design) has another conceptual structure than the real world. This fact crosses the idea behind all the 'unified' approaches I have seen. These invariably see the design as a sort of transformation of the analysis. The 'problem' explains why there are almost no successful code-generation-from-analysis-models around.

If you look at old applications, you can see that progress in software development is ongoing, and huge. Quickly made amateur programs can do so much more than multi-man-year programs from 20 years ago. This is in no way related to advancements in the code generation world. It's the result of a bottom-up process of making the developer more powerful in his design/implementation process.

Advancement in software development comes from the implementation side. Successful applications spawn more generalized toolkits. These in turn enable the building of even higher level applications. This is how we can now make things with 3D visualization and modern GUIs in the time you could, years ago, make bundles of hard to use, limited functionality batch programs.