The nameless is the origin of Heaven and Earth, while naming is the origin of the myriad things.— Lao-Tzu
We live in a complex world and one of our first challenge is to structure it so that it seems simple. Obviously, we will not be left to ourselves facing this major challenge. Early on, our parents will provide us with the foundations. Among other things, they will teach us a language and the meaning of words. We often forget that the simplest way to reduce complexity is to name things appropriately. A Chinese proverb says that the beginning of wisdom is to call things by their right names.
Slingboards Lab is not the first company that I founded. In 1991, after completing my master's degree in management of technology from the Ecole Polytechnique de Montreal, I founded a software company to market a drawing program for value engineering. Unfortunately, my company did not had the expected success. This is explained by the fact that my product, whose name was Fastdraw, found himself competing against the Visio drawing software. I had customers, but not enough for this to be very profitable. After a few years, I closed the business. Oddly enough, 24 years later, I still have an old client using my product. They still consider Fastdraw as a better option than Visio. Lately, they contacted me because they wanted me to program a modern version. I politely refused while freely providing them with the original source code.
A few days ago, I took a look and I was amazed by the structure of the sources. This program was a 16-bits Windows 3.1x app written in C ++ using the Borland C++ v4.0 IDE and OWL library. Each object has its own CPP and H files. The naming convention makes it easy to identify visual objects such as windows and dialogs.
For those too young, in early 90’s the filenames were limited to 8 characters (a MS-DOS constraint), here is why we find names like TOOLBARW instead of TOOLBARWIN.
As you can see, already at the beginning of my career, I was from the school of those who believes that words have meaning and names have power. By setting up an appropriate structure such as the combination of words with a convention, you can reduce complexity and make your code easily understood even 24 years later. Success is all about structure.
Sixteen months ago, I wrote on this blog that if a startup has to build a mobile application, the entrepreneurs should never go native. At the time, there were only three options for building a mobile application:
- Build three different native applications: Native apps are specific to a given mobile platform and are built using the development tools and language that the respective platform supports (e.g., Xcode and Objective-C with Apple iOS, Eclipse and Java with Google Android, Microsoft Visual Studio and C# with Windows Phone).
- Build an hybrid application: Hybrid apps make it possible to embed HTML5 apps inside a thin native container. Hybrid apps combine the best elements of HTML5 app but, unfortunately, they do not provide a native user experience.
Since last spring there is a new option:
- Build native applications with Xamarin.Forms: With a C# shared codebase, Xamarin.Forms is a cross-platform development tools that enable to easily create user interfaces that can be shared across Android, iOS, and Windows Phone. The user interfaces are rendered using the native controls of each the platform, allowing to retain the appropriate look and feel for each platform.
The option proposed by Xamarin seems very promising, especially since this company is not a newcomer. Xamarin was founded in 2009 by the instigators of the Mono project. Xamarin.Forms is the result of five years of work to build a cross-platform natively backed UI toolkit abstraction for mobile development. This is a serious player in the mobile arena. In fact, last week they held their annual conference in Atlanta. With over 1,200 registered developers, the event was not only sold out but also the largest cross-platform mobile development event.
Why all the interest about Xamarin? Probably because there is a growing awareness in the industry that when it's time to write a mobile app -- something interactive, not just a document with some hyperlinks, the Web is a second-class option. I was not surprised to read this week that Tim Bray lamented that the mobile apps are leaving Web work in the dust. The reality is quite simple, native rendering is important and the three major mobile platform vendors (Apple, Google and Microsoft) are embedding this feature in their proprietary operating system not in the open Web browser.
For those of you who follow this blog, you know that in recent months we have repositioned our startup and that we are currently building a personal task planner for smartphones. Following the above arguments for Xamarin, what development tools do you think we chose to build our mobile app? The very nature of a startup is that you have little money and need to be super fast on the market to validate your assumptions (and discover that you're wrong). On the other hand, because the apps are the natural structure for mobile experience, I think native rendering is mandatory. So there is only one logical choice. Do we think that everything will be perfect and really easy with Xamarin? No, but we are confident that in the next 12 months we will not regret our decision. Anyway, if Xamarin proves unsustainable and our product is a success, then we should have the resources to rewrite the application with another option.