On my terms

If there is something that is booming right now, it is mobile software. In spite of the vast variety of incompatible platforms, the number of mobile applications is growing very rapidly. Business houses know that mobile presence is imminent for them, and developers just can’t stop themselves from making new applications for their mobiles. Given such a huge development activity, one would expect current day mobile handsets to be full of software to do almost everything. However such is not the case. The discovery and distribution of applications is still an open problem. People want to try out software on their phones, but they don’t know what software to try, where to get it from, etc.

App Stores from Apple, RIM, Palm are initiatives in this direction, and they have definitely solved a part of the problem. For these phones, there is atleast  one place where software can be found. However all these initiatives are very specific in nature, and are usually not very unbiased. There is usually an entry cost for applications, and a number of other things one could of have done without.

There has to be something simpler, something more genuine. So there is Munimo. Munimo is a community initiative, started by myself & Mobisy Technologies (P) Ltd in association with MOMO Bangalore, where mobile enthusiasts come and share their favorite applications. With a very small number of contributors at the moment, Munimo has already started turning useful for new users. Go there, and you can see the favorite applications of most avid mobile users. You know of an application and you want to share with others, just log in to Munimo and add it to the collection. Your contributions will surely go a long way in making mobiles more useful for everyone.

In its current state, Munimo is simply a web portal where people come and tell about the applications they love. The next step for us is to push out Munimo mobile application for as many platforms as possible. Though it may sound like an ardous task, but thanks to Mobitop it essentially is just a few clicks job. Oops, not aware of Mobitop? For the uninitiated, Mobitop is magic wand for mobile application developers developed by Mobisy. Mobitop is an application platform which allows developers to convert their wap sites into mobile applications via a packaging tool. As of now, Mobitop is not directly available on Mobisy website, however that’s going to change soon. But feel free to get in touch with them, Mobisy team is more than eager to share their creation with everyone.

Once the applications are out, what would you like to see more? If you got any ideas, please let us know. Ideas/Suggestions are more than welcome. Code to implement them - even more :).

What do you think about a Mobile Application Profile (MAP). So you use a phone, and have a number of applications on it. The applications and their genre is what I call a MAP. When you move on to another phone, chances are that you are going to use a similar set of applications. What if all that happens by itself using your MAP. I think it’s very cool. What do you think?

Let’s make it happen.

Quality is one of the most talked about, and yet the most ignored aspect of software development through out the industry. Organizations take a lot of efforts to create a buzz about the quality of delivery. In one of the software companies that I worked for, every week someone from HR would put up a new poster in each employee’s cabin, featuring inspirational quotes about quality, and it’s benefits. Such efforts do create awareness, but rarely do they translate into the production quality.

One may wonder if quality is just a nice to hear thing, or if there is a tangible definition to it. There is of-course no common definition to it. Quality means different things to different people. For some, it may be about a polished & chic user interface, for some other it may be low memory foot print & zero leaks, and for some others it may be just about the number of bugs filed by the quality team. It is not essential to have a common definition of quality, but what is essential is to have a definition - to each one his own.

Quality has very commonly been seen as an outcome rather than as a process. All the examples stated in the last paragraphs are the outcomes of the development activity for a software. They are just ways to quantify quality. And more often than not, that is where the story ends. Organizations follow rapid development models, with minimal thought. The understanding is - time not spent on coding, is time wasted. They would make the software in what they think is the minimal possible time, and would then devote the last phase to quality by fixing as many bugs as possible. And that is what they call making quality software. What this process conveniently ignores is that quality is not a top-down process, it is bottom-up. In a top-down process, one just makes sure that the software works at least in scenarios which are important by putting patches, hacks or whatever comes to rescue. The result, as you can imagine, is that in every two-three releases the entire software gets scrapped and needs to be rewritten so as to accommodate the new requirements.

Software development has been plagued with the can-do approach for a very long time. Anyone reasonably comfortable with the programming language constructs is considered fit to write software. How can one believe that a few programming courses can make someone a programmer. This is like expecting the leadership courses to actually produce great leaders.

Then there are some really disastrous myths that exist.

• Adhoc development can help you make a quick prototype. Oh, I see people doing this all the time. They write the code in a day’s time, try to make it work for the next 2 weeks, and then spend another month to accommodate a requirement they forgot to take care of. And still the program crashes, if one clicks on a button in quick succession.
• A well designed software can not run fast. Ahh, as if the software gives you extra credits for reckless programming.

Disclaimer: This article is not intended to preach a way of programming, or to define quality. It is just a plea to care enough to think before churning out code. A software can do much better with a fewer lines of code put at the correct places.