Tuesday, August 13, 2013

Reason # 13: Maintainability of Applications

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.

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:

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. 

Over-engineering results in bloated code. A great many C# developers, including those who create code-generators, are overly enamored with patterns. Since they have no application platform to work with, they are forced to create application design patterns and it is extremely common to go overboard with these code snippets. Developers who inherit migrated code are also highly likely to overcompensate and be pattern-happy. It is almost impossible to see it in the early stages of code maintenance. The over-engineering of converted code is problematic however, because it causes incremental  amounts of overhead code to be added for each new change or piece of functionality implemented. Over-engineering will crop up when trying to cope with new operating system and database changes as well. Over time, these chunks of overhead snowball and negatively impact maintenance costs, lag schedules and ultimately cause projects to be abandoned and fail. The Magic xpa Application Platform provides the applistructure that allows you to focus on business logic. Maintaining code is never a matter of over or under engineering but instead a focused activity of measurable improvements.

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.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NETconversion please convert here.

No comments:

Post a Comment