Archive for September 2009

There seems to be an explosion of mobile phone platforms these days. Mobile phones is certainly where the growth is. The number of people regularly using them is expanding, plus people tend to break, lose or get stolen phones, that the replacement cycle is very fast. We have a number of legacy platforms like Symbian, Microsoft Windows Mobile, Motorola. Then there are a great number of new contenders including Apple’s iPhone, Google’s Android, RIM’s Blackberry, Intel’s Moblin and Palm’s Pre. Then there are dozens of smaller players all contending for developer’s attention.

Each of these systems has its own SDK (whether closed, proprietary or open) where you can write applications for the particular platform. Then if you can certify your application you can get it sold through some sort of proprietary app store. So as an application developer, do you just choose one platform and lock yourself into that and live with the risk that the vendor can kick you off the app store on a whim if they think you are competing with them or annoying a major cell phone carrier? Or do you develop the same application over and over in each SDK? Doing this is a lot of work and you can still get kicked out of major markets.

So what to do? Each of the major platforms now comes with a good browser (ever built in or via an add in). Google as Chrome, Apple has Safari, etc. These cell phone mobile browsers can browse and run most AJAX/JavaScript/HTML based applications. This gives a point of standardization that is outside the control of the cell phone platform software vendors, hardware vendors and cell phone carriers. If you write your application using web based standards then you can run in the browser on all these cell phones. All you need to do is make sure you application can render the screens nicely for commonly available screen sizes and allows varied input mechanisms.

Now doing this you don’t have access to the cell phone hardware, so you can’t initiate calls and can’t access the GPS (at least yet). But you still have open to you a wide range of things you can do. Additionally you are writing an application that runs on any hardware, not just cell phones, so your application can be accessed from Windows PCs, Linux PCs, Apple PCs, Game Consoles, WiFi devices (like iPod touch or PSP), and many more.

It seems that as hardware platforms are diversifying, it doesn’t make sense to develop for a single platform’s SDK anymore whether its Windows or iPhone. It seems like the cost effective way to get the widest audience is via open web standards. The standards based JavaScript/HTML world as evolved to the point were you can write extremely rich client experience applications without the use of any proprietary SDK. Java tried to get us to a write once, run anywhere world, but failed. Now AJAX/JavaScript/HTML has gotten us there.

For Sage Accpac ERP development we adopted the Agile Scrum development methodology back in June. Since then we are now on Sprint 5 and learning all sorts of things about scrum and agile as we roll out and practice this methodology. There are quite a few aspects to agile, but one of the key ideas is to relentlessly breakdown large tasks into smaller manageable tasks. Then to finish those tasks completely, don’t let them drag on, say code now and leave it to be tested three months later. For us we’ve realized quite a few immediate benefits:

Teamwork. Our agile teams are typically 6 to 12 people (most close to 6). This fosters excellent teamwork and shared purpose for the team members. It is also far easier to manage such a team, than say manage 40 people working on the same thing. The teams are also cross functional, so it aligns programming, quality assurance, user centered design and documentation together on the same team, rather than being members of separate departments with their own agendas.

Sprints. By running in three week sprints, it forces us to keep the product integrated and greatly helps preventing large numbers of bugs accumulating that need to be cleaned up later.

Better estimation. By forcing us to break tasks down to take less than one sprint, it forces us to fully decompose tasks and greatly increases our estimating accuracy in the process.

Better release planning. The agile release planning process is far superior to the older waterfall methods, with all their hand overs. With agile release planning you create your story backlog and when planned this is what you directly act on and track, without an conversion processes.

Better project tracking. Tracking agile stories and story points and measuring team velocities is far easier than traditional project management techniques which track by days or hours with all their complicated formulas.

Pushing decision making down to the teams. This has greatly eliminated roadblocks and enhanced teamwork. The teams make their own decisions and are responsible and accountable for the results. Works far better than relying on a Directory or Manager for decision making.

When adopting any new process there is some pain as you switch from what you know and what is tried and trusted to something more unknown. But it’s really a matter of having the patience to give the new process a chance. To see it working and to learn to trust it. One of the harder things to accept for Agile is the concept of not designing things until they are needed. There is an element of trust and confidence here that you will be able to successfully do this when the time comes. That everything isn’t laid out at the beginning of the project.