I was almost a month ago when I was given a tour of the patterns and practices group offices to meet up with the team working on the Mobile Client Software Factory. This new Software Factory was designed to address some of the most common issues with regards to building Enterprise Applications on Windows Mobile.

Some of the issues developers face today are :

  1. Having to deal with multiple form factors and screen resolutions. It is thought that you need to address 13 different screen resolutions in order to support all possible device profiles. There are basically 3 ways of solving this:
    • Build an exe for each resolution. (doh)
    • Build one exe with multiple forms and have the main form instantiate the appropriate form for the detected resolution. (tricky)
    • Build one exe with an intelligent form that renders the form and repositions the controls based on the detected resolution. (ideal. p&p uses this approach)
  2. Disconnected nature of Mobile networks. As connected systems become more popular and essential to a success of a business, having the application run on a mobile device brings up a whole new challenge. Due to the nature of mobile devices, connectivity is never guaranteed, thus forcing developers to building compensating code into their applications in the form of queues and callbacks.
  3. Being able to be part of a full fledged Software Development Lifecycle process. Most mobility solutions today are developed in isolation from the line of business applications due to the fact that tools today do not allow developers to practice TDD or Unit tests on mobile devices.

Obviously there are more issues such as security, authentication and reliability of messages and those have been or will be addressed in time.

Here's a cool picture of them working and practicing Test Driven Development (TDD). As you can see from this picture, two developers are working on the same PC using 2 sets of keyboard and mouse.

One person writes the code, while the other looks on and provides confirmation.

Because they are practicing Test Driven Development, what they're doing is writing the unit test and once the test is completed, the other will swap and write the actual method to pass the test. Pretty amazing actually, esp. someone who's an ol'school developer.

I remember talking to John Socha-Leialoha who's the developer on the left about practicing TDD and he looked at my astonished faced and said "yes. It's a leap of faith". Developers have to let go of the notion that they'll write great code or what hardcode developers would call, "Code of Art". Where programming is an Art form and developers spend countless hours writing beautiful code that is both efficient, small and caters or covers a lot of ground in terms of functionalities.

Practicing TDD requires developers to write Test Code that determines the functional features or restrictions and writing minimal code to pass the test. You basically leave the correctness of the resulting application to the Tester instead of the developer. What a concept, and you know what? it works. It works so well that it's better and faster than the traditional SDLC method.

If you want to find out more about TDD, I recommend these articles:

http://www.agiledata.org/essays/tdd.html
http://www.testdriven.com/modules/news/

One of the great components that is shipping in this Software Factory is the CFUnitTest or TestRunner which allows developers to run unit test directly onto a device to get actual test results instead of running on an emulator. This test harness also allows you to enable Visual Studio Team System's Unit Test on mobile devices.

Only issue we see now, is that VSTS doesn't explicitly support TDD so if you rely too much on intellisense, you might feel out of place as writing unit tests before implementing the code would make intellisense useless. I believe we're building support for this soon.