{"id":8911,"date":"2015-02-24T10:19:37","date_gmt":"2015-02-24T16:19:37","guid":{"rendered":"http:\/\/www.mrc-productivity.com\/blog\/?p=8911"},"modified":"2023-05-04T16:41:38","modified_gmt":"2023-05-04T21:41:38","slug":"how-to-create-applications-that-last-20-years","status":"publish","type":"post","link":"https:\/\/www.mrc-productivity.com\/blog\/2015\/02\/how-to-create-applications-that-last-20-years\/","title":{"rendered":"How to create applications that last 20 years"},"content":{"rendered":"

\"Education\"Summary: Technology is evolving at breakneck speed. No one knows what the development landscape will look like in 5 or 10 years. How can you create enterprise applications that stand the test of time…when you don’t know what lies ahead? This article lists 7 tips to help you create applications that last.<\/em><\/span>
\n<\/a>
\nWhat\u2019s the next big tech trend? How will development standards evolve? What will the web look like in 10 years?<\/p>\n

Who knows?<\/p>\n

That\u2019s the enterprise application development problem in a nutshell. No one knows the future, yet businesses expect future-proof applications. After all, no business wants to (or can afford to) recreate their applications every few years.<\/p>\n

So, the question is: How can you create business applications that stand the test of time? How can you create applications that will still be in use 20 years down the road?<\/p>\n

It starts with an underlying principle: Build for change. An application will never survive even a few years if left untouched. To stand the test of time, your application must evolve. It must adapt to meet changing business needs and trends.<\/p>\n

How can you do that? Creating future-proof applications is a passion of ours, and today, I\u2019d like to share some tips to help you do the same. Here are 7 rules you must follow to create applications that adapt to change:<\/p>\n

1. Focus on your data<\/h3>\n

Do you remember what caused the Y2K problem? It was the practice of abbreviating a four-digit year to two digits in the database. This led to software that couldn\u2019t tell the difference between the year 1900 and 2000.<\/p>\n

In other words, it was a data problem. Developers designed their database structure assuming the applications wouldn\u2019t last until 2000. This is always a mistake.<\/p>\n

A clean, well-planned data structure is the first step in building future-proof applications. Create your data schemes with the assumption that it will last for 20 years (or even longer). Just think–if everyone thought like that, the Y2K problem would\u2019ve never existed.<\/p>\n

\u201cFirst and foremost, when building your web application, your focus should be on the data,\u201d says Jitesh Keswani, Co-Founder of e Intelligence<\/span><\/a>. \u201cPlatforms may change, newer technologies may be introduced, but if your app has a strong future-proof relevant data, then users will adapt themselves automatically.\u201d<\/p><\/blockquote>\n

2. Don\u2019t build for a single platform<\/h3>\n
\"photo
photo credit: archer10 (Dennis)<\/a> via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

What happens when you build applications for a specific technology, platform, framework, database, etc\u2026? You\u2019re tied to that technology. Your application\u2019s success depends (in part) on outside factors.<\/p>\n

What if the technology becomes obsolete? What if the platform vendor stops supporting their software? What if the framework evolves in a different direction? I\u2019ve seen it happen time and time again. A business locks themselves into a single platform, and then struggles to adapt once it changes or becomes obsolete.<\/p>\n

Guess what? It\u2019s happening all over again with mobile. Rather than building for the web (a future-proof platform), some businesses are building platform-specific mobile apps. Will these platforms exist in a few years? Who knows?<\/p>\n

\u201cThe current trend is to build device specific apps for the iPad, Android devices, etc,\u201d says Kevin Baker, CTO of PageProdigy.com<\/span>. \u201cHowever, these apps cost a lot of money to maintain across all devices and platforms. Instead, building for HTML 5 and eventually HTML 6, an application can span across all devices. Since technology moves so fast, this method insures that all upgrades and improvements happen in one central place – maximizing resources and increasing the life span of the application.\u201d<\/p><\/blockquote>\n

3. Separate your architecture<\/h3>\n

\u201cTo future-proof your app, you’d better have your application architecture well thought out,\u201d says Dennis Kayser, CEO of Forecast.it<\/span><\/a>. \u201cIt’s probably THE most important thing to do right, unless you want to risk refactoring a large portion of your codebase. Hint: You don’t want to spend money refactoring many thousands of lines of code. It’s expensive and sucks! No matter the technology you choose, the overall system needs to be well architected. A good architecture makes it simple to change parts of the code for new tech, new features, to run faster or migrate to a new platform. It also makes the application easier and cheaper to maintain. The goal of a proper architecture is that it enables business strategy today AND tomorrow.\u201d<\/p><\/blockquote>\n

\"nTierMobile\"So, how do you create well-architected applications? We\u2019re a huge proponent of n-Tier architecture, which separates your application into layers. While you can learn more about n-Tier architecture in this video<\/span><\/a>, here\u2019s the main point: It lets you maintain and enhance each application layer separately.<\/p>\n

Why is that so important? Here\u2019s a great example: Suppose you need to make your applications responsive for use on mobile devices. n-Tier architecture lets you replace the presentation layer, without altering the other layers.<\/p>\n

\u201cThe key to building future-proof web applications is to build them in a modular way using proven open source technologies,\u201d says Reggie Cole, Software Engineer at Broadleaf Commerce<\/span><\/a>. \u201cProven open source technologies evolve and improve over time to solve problems as they come along and if you use them in a modular way, you can simply switch a part of your application to use another technology that is more suited to solve a new problem rather than having to remake your entire application.\u201d<\/p><\/blockquote>\n

4. Stick to the standards<\/h3>\n

Imagine if everyone designed applications using whatever standards they personally deem best. Now imagine you were suddenly responsible for maintaining applications built by others using no clear standards.<\/p>\n

Sounds like a nightmare, right?<\/p>\n

This highlights the importance of web standards. Web standards are the formal, non-proprietary standards that define web development best practices. In short, they give developers a guide so every developer isn\u2019t just making up their own \u201cbest practices.\u201d<\/p>\n

Standards aren\u2019t always exciting. But, they leave you with a solid foundation on which to grow.<\/p>\n

\u201cAdhere to the most current standards you can while creating your site,\u201d says Eric W. Brown, Contractor at ThoughtSynth<\/span><\/a>. \u201cEnsure your HTML, CSS, JavaScript, RDF, robots.txt, etc. all follow both the letter of the law per the standards for each and the industry best practices for each.\u201d<\/p><\/blockquote>\n

5. Use proven technology<\/h3>\n
\"photo
photo credit: geralt<\/a> via pixabay<\/a> cc<\/a><\/figcaption><\/figure>\n

Developers love using the \u201clatest and greatest\u201d technology. There\u2019s nothing wrong with that. Experimenting with new technology drives advancement.<\/p>\n

Just don\u2019t opt for unproven, new technology when building business applications.<\/p>\n

Why? You run the risk of choosing a technology that might never catch on. Opting for proven technology in your development projects promotes stability, security, and maintainability\u2013and the overall success of your applications.<\/p>\n

\u201cEnterprises are notoriously weary of new technology so if you’re building enterprise apps think twice before you use “alien” technology,\u201d says Kayser. \u201cWe all remember when Twitter moved from Ruby to Java because they had scalability issues. It’s a bit of a controversy, especially in the startup world where everyone is addicted to running the newest things. Enterprises like things to be predictable and with few risks, so they don’t end up supporting a system built on the next great thing, because what if it turns out not to be the next great thing? Then they’ll either have to redo the solution or end up paying huge amounts of money for a specialist to support them. Not a good situation.\u201d<\/p><\/blockquote>\n

6. Listen to your users<\/h3>\n

If your application will stand the test of time, it must evolve. But, how do you know which features to add? How do you know which direction to take your application? As explained below, it all starts with your users. If you stay in close contact with your users, they will give you more ideas than you\u2019ll ever have time to implement.<\/p>\n

\u201cListen to your users,\u201d says Harry E. Keller, PhD, President and Founder, Smart Science Education Inc<\/span><\/a>. \u201cYou may have the same product in 20 years, but it will have evolved if it has survived.\u201d<\/p><\/blockquote>\n

7. Do it right the first time<\/h3>\n

As mentioned above, your application will evolve. You will make changes and add new features. How you make these changes is of critical importance.<\/p>\n

What do I mean by that? Sometimes, you\u2019ll need a new feature added to your application quickly. Or, your application might need a quick fix. It\u2019s tempting to just throw a bandaid on the problem. Cobble together some patchwork fix and throw it on the application. Over time, those \u201cquick fixes\u201d become an unmanageable mess.<\/p>\n

There are two key principles to long-term application maintenance. First, fix problems the right way. Sure, this will take longer. But, it will save weeks of future headaches. Second, as explained below, document everything. Don\u2019t assume you (or anyone else) can figure out what was changed.<\/p>\n

\u201cAnother important aspect is to document everything, even the minutest detail,\u201d says Keswani. \u201cOver the span of two decades, you may not have the same staff that coded your app originally. A wiki like documentation system that can be tied to your data backup and bug tracking will help overall all such institutional shortcomings.\u201d<\/p><\/blockquote>\n

So, what do you think? Is there anything you would add to this list? If so, please share your thoughts in the comments.<\/p>\n

\n

If you enjoyed this article, sign up for email updates<\/h3>\n

Sign up below, and we’ll notify you of new blog articles via email. We value your privacy and will never share or sell your information. To learn more about how we handle data, please review our privacy policy<\/a>.
\n