2010 in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

A helper monkey made this abstract painting, inspired by your stats.

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 11,000 times in 2010. That’s about 26 full 747s.

 

In 2010, there were 13 new posts, not bad for the first year! There was 1 picture uploaded, taking a total of 5kb.

The busiest day of the year was April 26th with 779 views. The most popular post that day was Oracle starts to monetize Free Software, is it wrong?.

Where did they come from?

The top referring sites in 2010 were dzone.com, digg.com, reddit.com, twitter.com, and theserverside.com.

Some visitors came searching, mostly for mariadb, mariadb vs drizzle, drizzle vs mariadb, mariadb drizzle, and drizzle mariadb.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Oracle starts to monetize Free Software, is it wrong? April 2010
15 comments

2

MySQL is gone. Here comes MariaDB and Drizzle. May 2010
10 comments

3

Adopting RAD in the Enterprise: The 14 Biggest Misconceptions November 2010
2 comments

4

What Apple taught other businesses tonight. June 2010
3 comments

5

Nokia and Symbian : Business and Software : Lessons To Be Learnt October 2010
10 comments and 1 Like on WordPress.com,

Adopting RAD in the Enterprise: The 14 Biggest Misconceptions

Rapid Application Development (RAD) is a way of developing computer software applications with less effort than the traditional means.

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.

Read more…

Nokia and Symbian : Business and Software : Lessons To Be Learnt

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.

This was highlighted back in April 2010 on this blog, in the post titled Is Open Source software a classic example of fail for Design by Committee?

Technological Vision

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.

Platform, Platform and Platform

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.

Please feel free to share your views and additions.

Additional Links

What Apple taught other businesses tonight.

It’s here. Steve Jobs announced the iPhone 4g.

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.

Related Articles

Follow

Get every new post delivered to your Inbox.