The Time-to-Market Advantage in Mobile Application Development

As a visit to Damnoen Saduak Floating Market of Thailand will confirm, time-to-market and distance-to-customer are distinct advantages in business. 

It is difficult to know which came first: the customers with their curiosity and pocketbooks or the merchants with their bamboo and palm hats and colorful produce, but they are certainly mutually drawn to one another. People do not come here because the prices are cheaper but rather because the produce is fresh, accessible and sold in a convenient and interesting way. In bygone days, the vendors would paddle their boats on the waterways buying, selling and trading fruits, vegetables and other goods all across Bangkok’s canal system.  The canals were convenient, the boats efficient and the coverage of the canals was pervasive across all of the city. Where am I going with this?

Today’s mobile networks are pervasive, mobile apps are interesting and they can get to customers first, right where they are.

When it comes time to build mobile apps that can reach customers, time-to-market has more to do with the ability to develop mobile apps that run on multiple device operating systems and integrate to back-end business transaction systems in an efficient and agile manner. Distance-to-customer is the advantage that mobile apps have because they reduce the transaction distance between you and your customer to zero. Your ability to sell to customers is no further than the palm of your customers’ hand.

But quite frankly time-to-market is often a disadvantage of mobile apps because of the long lead times required to develop mobile apps using native platform development tools. That’s why when we see a platform that claims to marry the advantages of rapid development techniques, pre-built integration solutions and a capability for cross-platform mobile smartphone and tablet deployment, we have to pay close attention. Faster time-to-market for mobile apps requires a smarter application platform.

 Most development approaches fall prey to the time-quality-cost triangle and suggest that you can choose only two of the three beneficial qualities: less time and more quality or less time and less money or more quality and less money. The prevailing wisdom suggests that you cannot have all three. But frankly this popular dilemma is based on the preconceived notion that all approaches require a fixed effort.

What Magic Software initiated in the 1980s with the notion of a rapid prototyping platform for creating business applications carries forward today into some fairly slick and sophisticated technology that still gets overlooked far too often by the mainstream computer programming community. The benefits of an application platform can be found in the fact that it breaks through the problem of fixed effort. Platforms have built-in solutions. They allow for very rapid results by leveraging common application development requirements in an underlying solution set or platform.

Daniel Coyle, author of The Talent Code says: “Baby steps are the royal road to skill.” As I have said before: “Regardless of whether you use agile or scrum project management methodologies, early and frequent results are essential. Too many projects are cancelled midstream simply because their progress is shrouded in mystery.” An application platform gets you to those early victories and propels you to frequent wins that will keep executive sponsors engaged to completion and asking for more.

Native development suffers in comparison to Magic xpa application platform development for a number of reasons. First. More tools are needed. This is not opinion, this is fact. With native development you need a server-side language and deployment methodology and a client-side language. Furthermore, the client-side languages are different: Objective-C, J2ME, J2SE, etc. Because of the extra effort required by these tools, more programmers are assigned to a mobile app development project. While  environmental complexity increases with native mobile development, the Magic paradigm of platform based metadata development remains constant: one tool for all requirements – server-side and multiple OS clients.

To understand the absolute significance of this, one needs to consider the COCOMO II Model of software estimation perfected at the USC Center for Software Engineering. (Go Trojans!) The COCOMO II model can be simplified as follows:

                      Effort = (Team) x (Tools) × (Complexity)(Process)

As you increase the number of programming languages needed (tools), effort increases. The concept is fairly simple. As you increase the number of developers (team), effort increases. And as you increase the functional requirements of the application to be delivered (Complexity), effort increases. The relationship between these three components of effort is factorial.

Those restaurants along the canals of the Damnoen Saduak Floating Market want their vegetables really fresh. For really fresh mobile apps, consider the Magic xpa Application Platform.