For the past 8 years, I have been developing enterprise applications in Java and C#. When I first started developing iPhone apps in Objective-C, I missed the comfort virtual machines (vm) provided me. But, once I completed my first app (with smooth sliding and scrolling views, fancy graphics, and animations) I was happy to give up all vm benefits for the close to the metal nature of  Objective-C. I am so glad I didn’t forget the importance of explicit memory management from my early 90s C programming days.

When you think about it, performance is paramount when it comes to apps running on hardware constrained mobile devices.

Couple of days ago, Omid, our CEO, pointed out an important fact to me: Apps cover not just the traditional application space, they are also the new universal format for content that is both informative and functional.

Considering that the content space is orders of magnitude larger than the application space, it’s no wonder that app market had such an explosive growth in such a short time.

We are just at the beginning of this new phenomenon.

I came across the term “bloatware” in a Forrester Research report and right away I thought of RMC. The author, Clay Richardson, writes:

Bloat kills. Whether it’s excessive complexity in the application, its underlying platform or architecture, or the process used to deliver it, overloaded platform software and heavy processes impede delivery of the solutions the business demands.

RMC’s steep learning curve, heavy-client architecture, lack of support for collaboration, and underlying IDE platform make it a bloatware poster child.

Lately, being immersed in mobile application development, I have ever greater appreciation for lean intuitive applications and disdain for bloatware.

Its been a little more than a couple of months now since I last blogged. That post was about the release of the Yardistry design tool. This post is about the release of an iphone app + microblog site that I just finished work on. I regret not having taken the time to post regularly during this project because we discovered and realized so many interesting aspects of iPhone development during the development of this project.

While I cannot talk about the specifics of the iPhone application nor the problem it solves due to client NDAs, I thought that it would still be possible to talk about the interesting aspects of the app without giving away too much.

The project started off as a native iPhone app that would allow users to setup events in a particular domain and then allow the user to post updates on that event to their contacts/friends in existing social networks such as Twitter and Facebook. As analysis progressed, it soon became obvious that while posting to existing social networks is useful, we would not be adding real value unless we gave the audience that the updates were sent out to – the friends and family – a user experience that could not be achieved with Twitter and Facebook since we kept hitting walls in the API as well as the user experience on these sites. I posted my observations on this early on during the analysis and early development of this project in this post. 

The application that we ended up with is so much more useful and complete. Along with the iPhone app, we built a polished microsite that the friends and family could visit and view the updates and comment on them. We also hooked in a flexible REST-full API under the hood using which the iPhone app client could sync the events, updates and comments with the server. Clients built on other mobile platforms in the future can easily hook into this API. The iPhone app itself now includes utilities that focus on the problem domain and makes uses of the iPhone capabilities such as camera and location awareness to bring real value to the user experience. It is a little frustrating not to be able to talk about the problem the app solves or the details of the application as the value does not come across without it. But this will have to do for now.

Our choice of the technology stack on the server side is interesting to note because it’s the first time we used Groovy & Grails with mySQL to build both the microsite and the REST API. It was a very rewarding experience to work with Groovy & Grails because it allowed us to build a sophisticated scalable site in record time and I can foresee how maintenance pains will be eased dramatically compared to other technologies we have used. The focus on convention over configuration opened up a huge number of shortcuts to achieve what would have been laborious manual coding otherwise that would have taken us twice as long to complete the microsite. Since Groovy & Grails lie on top of the Java platform, we did not have to make any sacrifices since we still coded any complicated business logic and algorithms in Java. It all plays together seamlessly.

Among the many interesting problems we hit and thought about, one that stood out was syncing data between the iPhone and the server especially when the device moved between being online and offline. What should we do when the device is not online and the user posts an update or a comment? What approach should we take here? Should we have offline storage that gets synced with the server once the device goes online? Should we sync all the data in timed syncs and on specific actions? We took a look at what a lot of the apps out there do and noticed that most apps tend to allow actions that require talking to the server *only* when the device is online. When not online, the app would not allow the action. Ultimately, that’s the model we went for.

However, we are still thinking about this problem. We can see us hitting this problem frequently in the future in apps where not allowing the action is not an option. It seems like a problem we should provide an elegant and sophisticated solution for. Payman and I are going to be working on this in the background and if we come across any solutions we think might be worth discussing, we’ll put it up here. I hope you will look at them and leave us your thoughts.

There are other such interesting questions that we came across and continue to come across as we start on new mobile platform projects. I hope to find time to post them here as frequently as I can manage. 

An early version of MOF Mobile Reference is available at the Apple App Store now. I am already deep into the development of the next version, which will contain much more content, and it should be ready in a couple of weeks.

The App Store approval of CMMI Mobile Reference took 14 days. I was expecting the same duration for COBIT Mobile Reference app approval, but was  pleasantly surprised to get the approval in 8 days. So now the COBIT Mobile Reference is available for download from the App Store, free of charge.

I spent a weekend developing this app; it’s a basic reference for COBIT 4.1 processes and control objectives. Although it has limited functionality, I find it very useful and hope others will also benefit from it.

I have been working hard–with the help of our VSTS guru David Gowan–on a more functional iPhone app that tracks VSTS work items. I will discuss this app in a future post.

I am also planning other much more sophisticated role-based situational process improvement apps. At this point, I am still struggling with the appropriate representation of an end-to-end process on mobile devices. For the content of these apps, I am considering MOF, EPF, and a version of SCRUM, and am open to suggestions.

My overarching goal is to make the internalization of codified process improvement bodies of knowledge easier for practitioners.

On a separate note, I am amazed, given the iPhone tool set and developers’ support and using the right process, how rapidly iPhone apps can be developed.

The Yardistry Design Tool that I mentioned in my previous post is out! As I mentioned in that post, it’s been implemented using Flex 3 and Papervision3D and stands out where applications that leverage 3D in the browser go, especially in terms of the complex tooling it brings into the browser.

Here’s the direct link to the tool: http://designer.yardistrystructures.com/.  Select the ‘Custom Design Tool’ and get started modeling your outdoor structures.

A slightly technical aside: All the 3D part shapes that you see in the tool were created in popular 3D applications like Google Sketchup and 3DS Max and imported into our tool using our custom import utility so that we could apply rules to the shapes so as to work in the tool. Yardistry had these parts designed and available in the Sketchup format and we brought them in without them having to do anything special to make these shapes usable in the design tool.

Jane was the primary analyst on the Yardistry project and I was the primary architect/designer for the design tool and we are both based out of Toronto. Our development team is based out of Bangkok and they recently celebrated the completion of the Yardistry project and sent us a pic. They did such an amazing job – mad skills!!

This also makes me think about how we have got our development processes locked down. We were very agile with very quick short cycle times. At the same time, we were able to communicate and track requirements, design and development milestones for this fairly complex application between Toronto and Bangkok seamlessly and without compromise.  As with almost all of our projects, we used Visual Studio Team System (VSTS) for  managing and tracking development and bug tracking. It helps that we have a lot of VSTS and process expertise in-house so that we were able to leverage VSTS to the full extent possible.

We have an excellent team to begin with but we are able to leverage tooling such as VSTS to make a distributed team a non-issue – and in fact make it an advantage.

Congratulations to the team!

During the last few months, I have spent most of my time on mobile process improvement tools. Working on these apps has had the side benefit of giving me a more in depth knowledge of exciting process improvement bodies of knowledge and even more appreciation for their scope.  Bodies of work such as these codify a vast amount of practical knowledge and best practices from which any size organization or team–formal or agile–can greatly benefit.  I feel the persistent bottleneck stalling wide utilization of these bodies of knowledge is due to the difficulty of internalization.  I strongly believe that having the right tools is the remedy for this internalization problem.

The majority of these tools will be imbedded in or made accessible via the user’s exciting systems such as ALM platforms, but a subset of them will run on mobile Internet platforms such as iPhone, Android, and BlackBerry. The ubiquity and instant accessibility nature of these devices make them specially practical in situational usage. You are not always at your desktop when you need process improvement related assistance.

We at Osellus have been working on ALM based process improvement tools for over eight years, and more recently we have started working on mobile process improvement related tooling.

Recently I was part of the FDA 21 Code of Federal Regulations Part 11 (Part 11) audit of one of our custom software development projects. Part 11 audit is mandatory for any pharmaceutical system that uses electronic records and signatures in lieu of paper records. Our audit went surprisingly smoothly, and overall a positive experience for the team, reaffirming my beliefs about the benefits of established development processes and tools. This post briefly covers what contributed to the success of this audit.

Part 11 requires a software development process to be defined and followed. The process should have specific requirements, such as reviews of all the key milestones (e.g. System Requirements), and a well defined Validation phase (functional testing).

One of our internal product development processes was a good starting point for the definition of the process required for this customer project. As all our processes are stored in IRIS Process Author (IPA) in a reusable form, at the outset of the project, we were able to easily make the required adjustments to the selected base process to better suit the project. The process was then shared with the project team in a published form—in the project portal. During the audit, the external auditors carefully reviewed the details of this process and were fully satisfied with its coverage.

I was also required to demonstrate to the external auditors that our team was aware and followed the process. We use Microsoft Visual Studio Team Foundation Server (VSTS) as the development tool. IPA can generate VSTS process templates. In doing so, each activity of the process becomes a work item. In addition, all the process information such as description, steps, and roles, are captured as work items ensuring that every member of the team has access to process information when they need it. Hence the project team was steeped in the process being enacted. This showed the external auditors that the process was fully internalized by the project team and would not be abandoned at times of stress.

VSTS was also used for planning and managing issues, risks, and tasks, a single repository for all project artifacts. As VSTS is tightly integrated with MS Project, project managers were able to generate schedules and track the team’s progress.

In one of my sessions with the auditors, I did not have printouts for all issues and defects with me. When the auditors asked for evidence for certain scenarios, I was able to use VSTS (through web interface), and generate excel spreadsheet for the requested scenarios on the spot. This drove home for me the importance of having a central repository that instantly provide access to all project artifacts, which can be used as direct evidence during the audit process.

I believe process and tools are like two wings of a bird. To fly this bird needs both. Having a well-defined process in place is a great first step but unless the team has the tools that seamlessly incorporate the process into their daily work, the process is not internalized. High performance teams such as ours value being process-centric and disciplined, as long as processes are not a drag on their daily work. The integration of processes with tools not only helps with a positive audit experience, it also results in a motivated and disciplined development organization.

Software development processes capture—in reusable form–the organization’s best practices and lesson learned, making them sharable across projects. Today, the benefits of process-centric software delivery are well understood. So, why is the industry’s adoption of software development processes so dismal? The lower than expected adoption can be partly explained by a phenomenon called groupthink. For this post I will rely on materials from James Surowiecki widely cited book: The Wisdom of Crowds.

The coinage of the term, groupthink, predates Surowiecki’s work, but he frames it concisely within the larger arena of group decision making, which he shows is more accurate, in most cases, rather than decisions made by subject matter experts. This easy to read book draws from and consolidates various scientific and empirical bodies of work from diverse fields–such as psychology, statistics, and economics–making the subject generally accessible.

For crowds to produce correct decisions, its members must be diverse, independent, and decentralized, and should have a mechanism to consolidate the individual judgments into collective decision. However, the decision making fails when the members of the crowd are too conscious of the opinions of others and begin to emulate each other and conform than think differently. This failure is called groupthink.

I believe commercial software methodologies have been suffering from groupthink. For over a decade, most efforts have centered around Unified Process with all participants—mainly methodology theorist and consultants-emulating each other and conforming rather than thinking differently. Any new development—such as Eclipse Process Framework or SCRUM—has been forced to fit in a UP mold. The practitioners have found these expertly devised methodologies irrelevant, and, hence, have mostly avoided them. At the same time, new practical ideas that arise during actual development projects are prevented from blossoming. The potential methods devised by diverse projects’ practitioners are likely to be more relevant, as they convey the wisdom of crowds (mobs) and consequently have a better chance of wide adoption.

The good news is that with the recent availability of integrated ALM and interactive process asset repository systems, it is now possible to involve practitioners in the end-to-end methodology development effort. I will cover this in more details shortly.