RAD tools focus on providing code generation and automated testing capabilities with the use of convention over configuration to provide a streamlined workflow to create applications.

Even with the most advanced and easiest to use RAD tools, there are times which the traditional enterprise and the business software development vendors which are having their own implementations and in-house built frameworks are continuously refusing to adopt them.

Most of the misconceptions on the RAD are based on FUD (Fear, Uncertainty and Doubt) which has been created around the internal complexity of the RAD tools.

Here we take a look at the biggest common misconceptions on RAD tool adoption in the enterprise.

1. RAD tools are magical

This is a common myth among the developers who insist on writing their own code from scratch.

Due to the elegance and the accuracy of properly generated applications, they will assume that the changing of generated code would cause the application to lose its beauty.

They are reluctant to see patterns in commonly developed applications which could be easily generated by the use of RAD tools.

According to the latest news, Nokia is likely to wind up encouraging Symbian application development. There are a few things which can be learnt from this move for most of the software companies and businesses.

In a nutshell, Symbian was bought over by Nokia and, which intended to make it an industry wide standard in developing mobile applications – made it a foundation run by member subscriptions. To aid this, Nokia gathered a number of mobile phone vendors which were starving for a mobile operating system. Times passed by, and the Symbian source code was made open source and freely available since last year. Since then, Nokia has experienced a reduced amount of market share and has gone down.

Following is a list of lessons which can be learnt from Nokia and Symbian experience.

Design by Committee

Making Symbian design governed by a committee instead of a central designer, largely contributed to the failure of the Symbian to adopt to the environment. Committee members had their own proprietary implementations of the platform architecture, and then the platform started to starve from lack of usable components.

Nokia probably had great management people at its top, but lacked any with a technological vision. This is also clearly visible in many software companies engaged in business and enterprise application development. A clear technology visionary would allow any organization to reach its maximum potential with its existing business and technical resources.

In addition to the technological vision, a marketing visionary is also needed within a company to promote its technological efforts to the mass market.

Iterative Development

The traditional waterfall software development method along with phased releases used at Symbian and Nokia [not applicable to Series 40 platform] were too destructive for the foundation as a whole, specially at the times where other mobile operating systems were developed and delivered in faster release cycles and the customers were eagerly waiting for bug fixes and new feature additions which can unlock the best features of the device hardware.

As a platform, Symbian was too complicated for the developers to develop applications for. The platform API(Application Programming Interface) has been too complicated for regular and rapid development. This has not been the case for mobile operating systems that were coming from developer centric organizations.

It should be also noted, that the platform has to be maintained by a core-team, with contributions accepted and merged from different products and projects which use the same platform. This has been the case for Qt framework, which Nokia acquired along with Trolltech. Now, Qt has become the only platform that Nokia will ever promote.

Developers, Developers and Developers

Steve Ballmer’s famous lines, has been reiterated at the recent Nokia World summit by the new Nokia Chief Executive Officer, Stephen Elop who previously headed the Microsoft business division. Developer centric organizations rarely go down in business, in spite there would be many management people arguing against the fact, simply because they see developers as inferior to the managers or they have a bad perception of overly expensive developers. Developers are the ones who would be defining the boundaries which a modern organization can expand.

Don’t let the hardware limit the developers

At Nokia, hardware rules, this is no different from many traditional software companies which focus on reducing costs by limiting the hardware and capabilities available to the developers (whether at the runtime environment or the development environment). Give freedom to the developers and a solid foundation which they can simply focus on software and logic, they will do magic. Otherwise, it’s very likely that developers would be compelled to waste time optimizing [or debating the best way to concatenate Strings, which is a classic example] instead of delivering new, interesting and usable features to the end-user.

Product based Matrix Organizations don’t work

Considering Nokia and it’s recent products, one can always see that there is a large amount of different devices which run the same platform, but have different features. It is largely possible that these devices are coming from different teams which are headed by different product or project managers. Very likely that there are developers who excel in different areas of development put into different projects, causing increased fragmentation of the operating system and the device software, making it difficult to maintain. It also reduces the chances of platform improvement by making it difficult to merge individual improvements to the main source code base.

Don’t keep incompetent people

There were loads of people who were working at Nokia from top to bottom (including the CEO and the factory worker) who were simply incompetent for their current role, highlighting a real world occurrence of the Peter Principle. The maximum from them could have been obtained from their competencies if there had been a proper mechanism that would have prevented such. Unfortunately, when the company as a whole goes down, these people are less likely to find a better job and will have to step down and go down another step when joining another company.

Research is important

At all times when these things happened, Nokia Research has been making great advancements in the fields which they conducted research. In the coming times, probably the only Saviour for Nokia would be the product features which can be improved through the in-house research. Microsoft, Google and Facebook are also examples where in-house research has benefited an organization to come out and perform soon after difficult times.

This is a moment where most businesses start to realize the truth and lessons about managing their customer requirements and product releases.

Found this article on My Nokia Blog on how most businesses can learn from the release and product strategies of Apple.

What Steve and Apple do best is explain why features are great, why they’re useful to you. Regardless if it’s mundane, it helps general public and the press vomit it verbatim. It helps in direct word of mouth conversation and even more so in online social media. Even if people are retweeting nonsensical bullshit, people are talking about your product in the positive way you choreographed it.

You can read more on Apple product strategies and requirement management strategies on similar articles in here within Zero Lines of Code Blog.

Steve Jobs doesn’t hate flash. It’s just the energy consumption and increased competition from other mobile phone manufacturers due to the nature of platform independence that he is concerned about. Accept the fact, he is the CEO of Apple.

Flash and many other runtimes are now becoming a trend of the past as most mobile device makers are now focusing on enhancing energy consumption through the use of native code.

What about Apple?

In his now famous post published on Apple website, Steve noted that there are six (6) reasons why he has decided to keep flash and other runtimes away from Apple devices.

Openness – Flashis completely proprietary as Jobs says.

Full Web – Flash stands blocking the way for the completely open and total web experience without separate plugins for most browsers.

Reliability, Security and Performance– There are known reliability and security vulnerabilities in Flash plugins. Flash is known to be the number 1 reasons that Macs crash, according to Jobs.

Battery Life – The device battery dies fast, when Flash is running. This is a known and clearly visible fact, in instances where operations such as video decoding is performed through software, when it is possible through a dedicated chip. The processor is usually a heavy resource consumer, when compared against a dedicated video decoding chip.

Touch – Flash doesn’t completely support touch. This is somewhat notable when you run Flash applications on a Symbian device. The highly famous ‘On Mouse Over’ effect in Flash sometimes destroys the user experience for most touch based Flash applications.

Proprietary and Third party – Having Flash on board the Apple devices means it creates a third-party dependency on Apple.

What about other manufacturers?

Interestingly, Nokia is trying to lead a different trend. They are promoting QT runtime as the future in mobile and desktop application development as a solution to the highly criticized Symbian platform native application development. Actually QT runs faster on Symbian than most native Symbian applications [as I have noted].

On contrast to Apple, Nokia smartphones are known to support a large number of runtimes including Adobe Flash, Microsoft Silverlight, Sun(Oracle) Java,Nokia QT and Python. I have used apps that run on Flash, Java and QT runtimes, and have to say that they are pretty impressive and works almost fine as the native applications on Symbian.

Speaking of QT, even now I use WordPress for Symbian application which runs on QT runtime and is pretty much impressed with the performance and the user experience.

Google has stated that it is and will continue offering support for Adobe Flash runtime on their Android mobile platform.

What about the users of mobile devices?

The expectation from a mobile device is somewhat independent of what Adobe and Apple are fighting for. Consumers use mobile devices for various purposes and the needs of most consumers are largely different from each other. Some would like to play games on their mobiles, and some people focus on staying connected all the time.

It is almost impractical [at least for the moment] for mobile manufacturers to reach both ends of being able to support processing intensive applications and prolonged battery life.

After Sun Microsystems was acquired by Oracle, there has been a large amount of discussions in the business and developer community on the future of MySQL community involved in its development.

A Community Fork?

Interestingly, MySQL community has been able to create a new Database by a fork from the public branch and has revived the project as MariaDB.

On it’s website, AskMonty.org [founded by Michael “Monty” Widenius, the founder and creator of MySQL] states that its aim is,

To provide a community developed, stable, and always Free branch of MySQL that is, on the user level, compatible with the main version. We strive for total interoperability with both our own, and our upstream, communities.

It also states that,

MariaDB is a backward compatible, drop-in replacement branch of the MySQL® Database Server. It includes all major open source storage engines, including the Maria storage engine.

What about cloud?

There is another branch of MySQL survived as Drizzle which aims to focus on Cloud. The Drizzle project states that,

…[It] is building a database optimized for Cloud and Net applications. It is being designed for massive concurrency on modern multi-cpu/core architecture. The code is originally derived from MySQL.

Looking at both of the above, it can be seen that even if the main source of the above two projects are same (MySQL), they are going on different directions as a result of the community turmoil created because of Oracle’s acquisition.

The Future [and the Community Edition]?

Oracle had stated that it will be continuing to serve existing business customers of MySQL of Sun by providing more investments to the development and continuing support for the existing customers, but has not issued any statement related the community editions of the MySQL. It is seen that Oracle plans to retain existing customers of Sun but most probably, not the community. Having a closed source culture and being business minded, Oracle is highly able to transform the existing MySQL customers to Oracle Database solutions by strategically reducing and finally discontinuing support for existing MySQL customers.

Adding with the demise of MySQL [probably within the next couple of years] from almost every xAMP stack, the free and open source community has to reinvent the wheels to continue its race against the well-built closed source commercial software.

Open up your code, watch it grow and let it go. Most open source software have started small and has grown up to be large projects that sometimes have changed the entire game of software business and the economy.

While certain projects are totally open, in some projects, the authors have only shared certain components of their applications [not the complete application] and have asked the community to contribute to the code while retaining the revenue [and profit] for themselves.

Open for Extension?

Most open source projects become total messes in terms of usability and product focus because of the community members and other people requesting various features that are sometimes totally unrelated to the main intentions and goals of developing a particular application.

For an example, in the recently opened up Symbian Ideas project, one had even suggested an idea for a platform feature to romance and pamper one’s loves ones through a simple application which is built into the Symbian Operating System. When Symbian votes down this idea, it would be affecting the Symbian perception for the particular person who suggested it [as he would be feeling being let down by a whole community instead of just a single entity such as a person or a company].

If it was a closed source project, when an idea gets voted down, the person would not be feeling offended as a there is a person who is officially responsible for taking the blame and to follow the suggestion afterward.

A typical reverse example for the above is Apple, which dictates what their users should be able to have access to. In the case of Apple, the users have less choice for customization and modification while Apple takes all the credit and the blame for the feature set that is offered along with its products.

Google is almost doing the same, but with a different model of open source software development, retaining the power within the paid and experienced developers who work within Google, instead of letting everyone contribute their various ideas and messing the usability and source code up with the myriad of user requirements coming from millions of users.

The completely free and open source software distribution model is facing increasingly tough challenges everyday from companies that are heavily investing in their development resources and marketing their products, instead of opening up their code, giving the source and the product away for free and charging for support.

Closed for Modification?

Taking the above case as an example, it can be seen that the developers and the market are following Apple and Google instead of Symbian[sadly]. Due to the less amount of change [predicted and ongoing] in the core of the project [People are reluctant for rapid change]. Apple and Google have released neatly documented and easy to use Application Programming Interfaces (APIs) that allows easy integration of the underlying platform instead of completely opening up the source of the platform.

This has increased trust over their particular projects [brands] because of the simple fact that these entities having complete control and total responsibility over their source and project at a single point.