20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting
As we mentioned in our previous discussion of software quality, maintainability of a program or maintainability of code is one of the six key measures of software quality. It is also the area where the Magic xpa Application Platform absolutely shines over alternative means of software development and deployment such as C#, ASP and Java.C# software projects are commonly derailed by bad engineering decisions that make the code un-maintainable. These bad decisions often fall into one of two categories: over-engineering or under-engineering. Under-engineering results in spaghetti code. This is particularly common with code conversion projects. The code conversion creates a giant meatball of code. Thick, impenetrable and impossible to understand. Those charged with maintaining that code by manually programming in C# start by adding a string of spaghetti here, a string of spaghetti there. Pretty soon you have a giant wad of overcooked, undercooked and raw spaghetti smothering your poor meatball. There was no plan, no experience and no recipe for code maintenance. The situation gets worse when a renegade hacker is called in to rescue the code. But all they can do is add more spaghetti of their own and the code gets worse and worse. With Magic xpa, the platform itself provides the needed “applistructure” for an easily maintained application. Magic xpa applications are more like a finely layered lasagna, well thought out, uniformly structured and therefore highly maintainable.
Maintainability of C#.NET code is such a common and ongoing problem for developers that
Microsoft, although unable to control bad coding practices, created a
maintainability index that tells you just how bad your code is. If you are
considering migration of Magic eDeveloper, uniPaaS or Magic xpa to C#.NET
instead of upgrading to .NET directly with Magic xpa, then you shouldn’t ignore
the problems of maintainability in C# versus Magic xpa. Here’s why:
The vulnerabilities of C# are also found in the area of code redundancy. Whereas Magic xpa leverages a platform, C# programmers have to create their own application architecture from scratch. The .NET framework is not an application architecture, that’s why the word framework was carefully selected because it is neither platform nor architecture. While every developer knows the DRY principle: Don’t Repeat Yourself. The problem with a code generator is that it is impossible for the developer to know when they are repeating code that was generated elsewhere. The converted Magic applications become so bloated and complex when deconstructed into C# code that the code to be maintained ends up having massively repetitive aspects. While efforts will be made and assurances given, it is just impossible to avoid code bloating by duplication of nearly-matched patterns.
Since the code generator won’t see the repeatability within complex patterns, it will simply engage in wholesale duplication of code. The code is not DRY conformant and therefore nearly impossible to maintain over time.
Magic xpa’s repository-based development approach enhances project organization. Rather than dealing with mountains of text, you work in well-organized Magic xpa repositories. C# on the other hand allows for wreckless programming. Poorly organized code can lead to the introduction of dumb bugs and will result in slipped schedules or worse.The superior organization of a Magic xpa application means that it is easier to on-board a new Magic xpa programmer from scratch than it is to orient even an experienced C# programmer to code-generated projects.