Agreed Bernd.
NB: See my edit above, though it does not detract from your observation.
MDG Technologies have to be assembled by hand. In cases beyond very simple constructs the process quickly becomes labor intensive, and very fragile. There is a high probability of simple errors - file overwrites, missed steps, version mismatches, data values out of sync - which quickly overwhelms attempts to build things correctly.
Some (many) of these errors result in some visible failure when the technology is deployed, most being annoyances or things that are obviously wrong. A few problems lead to scenarios where the technology is not completely correct, but the flaws can be subtle and difficult to find immediately; there is a danger that these problems will make it through testing and into deployed products.
Even worse, attempts to correct even minor problems often require that the entire sequence of manual steps be repeated. This essentially resets the counter for simple mistakes, as each step could be done incorrectly this time, even if it had been correct before. It is like retyping an entire document by hand to fix a spelling error. You run the risk of incorrectly spelling any words in the document, including the one you intended to correct, in the new version. All your earlier correct work is now at risk. The larger the document, the smaller the chance that you will get the entire thing correct; it quickly becomes essentially impossible. So too with MDG Technologies.
I have had almost no luck addressing this issue with Sparx. They have resolved several bugs that could corrupt the technology even if the development work was done without error. They have also been excellent at updating specific documentation errors I've pointed out. But they have not as yet been able to address the overall issues.
'nuff said...
