Adding it all up: the case for migrating to HTML5 (Part 1)

Let's say you've got a line of business (LOB) application that just chugs along, doing its line of business thing, day after day, week after week, year after year. Every big company has at least one of these, often dozens and dozens. 

Many were written years ago by well-meaning people who had a user base to satisfy. Like my Uncle Fred's chicken coop, they were improved, added on to, upgraded, repaired, repainted, electrified. When the original builders retired or moved on, someone else stepped in to keep things working. 

And time goes by.

And more time goes by.

And one day, someone realizes that Something Must Be Done.

That app is old: the roof is leaking and covered with moss, the doors sag, there's a busted window. Time to do something, but what? Tear it down and build something brand new and shiny? Or save the good parts of the existing structure and make it new again? Does it make sense to reuse part of a legacy application to get a more modern version?

Since the dawn of time, people have talked about code reuse. Code reuse was going to save all our bacon. OOP was going to make code reuse a reality. Reusing code cuts development costs and reduces bugs. Blah blah blah. 

The thing is, almost nobody ever reuses code. 

Instead, whenever I talk to developers about apps they support what I almost always hear is: "This app is crap. We need to scrap it and rewrite it from scratch." Code reuse, anyone? 

Hey, the app can't be all bad, can it? It's working, isn't it? It still has business value, or you wouldn't be running it, right?

Something in that app has value. But what? And how to reuse it? And why not just toss it and start over? 

Not all old code is bad code

An overly simple way to describe a lot of LOB apps is that they consist of a user presentation tier, a business rules tier, and a data tier. 

The data tier is inviolate; it has actual data in it! The access to that data might change; the storage of that data might change--for example from a local database to a shared database to a cloud database; the schema might even be tweaked with new data structures being added carefully over time. But the actual data represents a valuable asset to the company.

The business rules have, for argument's sake, evolved, improved, and been purified over time. Business rules might be processes or algorithms or the recipe for KFC Original Recipe, but they are the intellectual capital of a big company. They need to be preserved and protected, once encoded as programming instructions, tested, debugged, and deployed.

That leaves the user layer, the user interface. This is the part that is the most fragile, the quickest to show age and infirmity. Our expectations for user experience have raced forward over the last few years, driven in part by cool new startups with apps that run on phones, tablets, and in browsers. We want--no demand--to access apps from BYOD devices of multiple form factors with different operating systems. We want access to data inside and outside the corporate firewall. We demand responsive designs so we can work on our iPhone, our laptop, our Surface Pro. And we want it yesterday.

So at the end of the day, that's the order of business. Preserve the data layer and the business rules, but modernize--mobilize--the user experience. And, by the way, we need it yesterday.

The case against rewrite

When we build we learn, and when we learn we see the glaring errors and omissions of what we built. We hide our heads in shame, for it is imperfect and hideous in our sight.

But the fact is, it works. Sure, it's always more fun to start with a blank slate and design the perfect system, with lofty goals like perfect encapsulation, a full services layer, lofty OOP practices with no compromises. A system which will be easy to maintain and elegant in its execution.

And then reality hits. Schedules compress but work expands. Resources leave or redeploy to fight fires. Meetings abound. New requirements crawl out from under the baseboard like an invasion of cockroaches. Shifting specfications are bolted to existing architecture like cattle horns on the front of a pickup. Elegance is suffocated under the pillow of pragmatism--this thing has to get finished. 

Maybe it won't happen to you. But statistically something like 70% of new development projects fail or are abandoned. It's a grim casualty rate. 

The case for migration

You can have your cake and eat it too. Automated modernization provides a fast path to a modern web application that sidesteps the traps of mission creep and schedule slips. With automated migration, you get a disclipline with respect to scope while reusing valuable code. 

Development patterns like MVC or MVVM abstract the user presentation into a view model which is invisible to the other tiers (business logic and data). This means the UI is completely abstracted from anything that references it. 

Of course, you can't just re-imagine a Winforms UI as HTML and JavaScript. You need a lot more than that. You need a server-side architecture that can build pages dynamically, something like ASP.NET. You need some kind of JS framework on the client side to render a rich control set for a great user experience. You need to manage multiple sessions and both server-side and client-side state. You need to be cloud ready, which means being able to support server farms, load balancing, non-persistent connection, and more. In the world of desktop apps, you could get by nicely if all you knew was .NET, C#, and SQL. Now you need to add a host of other technologies, like JSON, CSS, HTML, jQuery, and maybe things like Angular, KendoUI, Knockout, and Bootstrap. 

If you try to do all of that plus rewrite everything from scratch how do you think it will go? 

Here's where automated migration--modernization really--comes in. The automated part does the UI recreation for you, while wrapping the back end code in the necessary technologies to make it work as a web server instead of a desktop app. The vital business logic is not rewritten, only wrapped in the MVC pattern where necessary, so no new bugs are introduced.

Writing code by hand, any code, introduces some number of bugs per thousand lines of code (KLOC). Bugs are expensive to find and fix. And most studies show that new code has bugs still in it when released, bugs which could have significant consequences when (or if) they actually become apparent. 

MIgration through automation is true code reuse. It lets you leverage existing assets, rather than pitch them out and try to recreate them.

Need help figuring out whether or not your app is a good candidate to move to HTML5?

Let us help! We'll develop a free proof of concept and show you what your app looks like on a mobile device.

Click below for more info: