This article originally appeared on the BeyeNETWORK.
Like most people, I was really excited when I wrote the code for my first application. I remember it as if it were yesterday. I took the requirements and wrote them in code. I wrote code to get the data that was needed for processing, and upon achieving something worthy of output I wrote my output, to a printer. I had the feeling of real accomplishment when I saw my first output printed. Now I was a coder and a developer—a real application developer.
And so there is a very good feeling of having solved a problem that is almost universal when the application becomes real.
But then strange things started to happen. An end-user came to me and told me about a change in the requirements. Then somebody wanted output other than on a printer. Next my company was acquired and we had to run our code on a computer that was never considered. Then I was asked to have a different set of input devices. In a rapid flash my solution—my application—had gone from an accomplishment to a maintenance nightmare.
That was my first introduction to the difference between code and survivable code. I learned the difference between code and survivable code through the pain of failure, which is the best way to learn, because those lessons borne in pain are not quickly forgotten.
There is an important difference between just providing a solution and providing a survivable solution. Mature designers and developers know this. Rookie designers and developers have this lesson still to learn. Companies that invest in mere solutions and rookie designers and developers have to learn a lesson in both economics and technology. If one is planning to invest in an application of new technology, you need to invest in survivable code and applications. In many ways application flexibility is as important as the application itself.
So exactly what are survivable code and applications? Survivable code and applications are code and applications that can withstand the shock of change. And how exactly does a piece of code become survivable? There are many factors, but easily the most important factors are those insulated and abstracted. The mainline application code needs to be insulated from the immediate code environment. If code is written for a specific device then it can only run on an environment that has that device. Once the device changes, the application must change or the code is worthless. One of the ways that insulation is achieved is by abstraction. Take the simple act of writing to a printer. If I write to a specific printer, then my code is tied to that printer. But if I write to a print module, and the print module then decides what printing device to use, I have now insulated my mainline code from the printing device. I can change or add printing devices easily by altering my print module. My mainline code—the code that solves a business problem—is not affected by changing or adding printing devices.
These problems of maturity, insulation and abstraction are typical of what an industry goes through in its early stages. And today mobile computing is in its early stages.
Now there is no question that mobile computing has a powerful business value proposition. For any business that has a field force which many do, mobile computing is a natural. With mobile computing the sales or service person is information-enabled as they do their job. It does not take a vivid imagination to appreciate the business possibilities. Ask Fedex, Hertz and Avis. Ask almost any company that has a field force and they will tell you the value of an information-enabled sales and service force.
Mobile computing is still in its early stages compared to other forms of computing. The industry and the technology of mobile computing are still being shaken out, in many regards. And now mobile computing is rediscovering some of the lessons of the past.
Some of the largest and most widely heralded mobile applications are discovering that they have made a “rookie” mistake (albeit an innocently occurring mistake). Many of these early pioneers have discovered that their applications are grossly inflexible because they did not learn or heed the lesson of insulation and abstraction. Many of the early mobile applications are inflexible. This means that these early applications cannot take advantage of new technological innovations that are occurring at the hardware and software level. It means that when new requirements become manifest these companies that made the rookie mistake will have a hard time changing. Either change will not occur at all, or change will occur in an awkward manner.
But some development organizations in the mobile environment have heeded the lessons of the past. They have learned that it is possible to insulate and abstract data and processing in the mobile environment. Take Countermind for example. This startup company in Denver recognized from the beginning the importance of insulation and abstraction. Countermind has created an infrastructure in which mobile applications can be built and changed without having to completely uproot the environment. Countermind has employed the very valuable tools of insulation and abstraction and has created survivable code for the mobile environment. This is worthwhile because in today’s mobile industry the useful life of handheld devices is about six months, networks are consolidating at rapid fire and mobile operating systems are versioning faster than ever.
By creating a mobile design and development world that employs insulation and abstraction, it is now possible to create truly flexible mobile applications. And in doing so, organizations can start to build mobile systems. Because an infrastructure for insulation and abstraction for mobile computing not only creates flexibility, it also lowers the cost of entry to the world of mobile computing.
It is not surprising that organizations pass from code to survivable code over a period of time and as a natural consequence of maturing. Mobile computing is merely following in the footsteps of those that passed before it.
If you are interested in survivable mobile applications, Rachel Blevins of Countermind will tell you all about them. Rachel can be reached at Rachel.Blevins@countermind.com.
Bill Inmon is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.