Mobile development is young. The App Store opened on July 10, 2008. In just over a week from now, it will be 5 years old. Web development, by comparison, is over 20 years old. Mobile is popular, this is something we all know. What we don’t know, as an industry, is what does ‘doing mobile’ mean? Does the mobile experience complement or duplicate existing channels? There is also technical uncertainty: native vs web vs hybrid, thick vs thin client, chunky vs chatty messaging, etc.
We can defer technical uncertainty by starting with a simple base, measuring what we have and changing to suit. In order to do this we need to give up exploring different mobile architectures in Iteration Zero. I’m sick and tired of teams mucking about with infrastructure and not delivering value
Iteration Zero: I’m sick and tired of teams mucking about with infrastructure and not delivering value.
I don’t believe this is a good use of time. The decisions around mobile infrastructure have been made. Do this and you should be able to add value on day zero. Don’t go native, make it responsive, do useful REST i.e. hypermedia and your service will be a façade over any resources –legacy or otherwise. This will give you a decoupled front-end.
My mobile architecture will be responsive web. I’m a big fan of native apps, but I will only go native once I have collected evidence that native is necessary. Not before. Ideal candidates for native are apps that are used daily, and sit on the first page or two of apps on your home screen. Responsive web means I have to do less work to support multiple devices and give me more flexibility.
The mobile app must be decoupled from the back-end. You can’t force users to update their apps, so this decoupling gives you essential flexibility going forward. To make this happen; before I even have a backend, I drop a static JSON file somewhere and point my mobile app at it. It should work. If it doesn’t, I’ve got coupling. I use hypermedia links so that the JSON also describes how the app can interact with the resource. My app is reduced to rendering the resource and giving the user options based on what it’s told.
On the backend, if I have a legacy system my mobile app should never integrate directly with it. I put the simplest façade I can in front of it. This will be the REST API serving up, initially, those static files I used to start fleshing out the mobile app. Go beyond just serving up JSON. If it helps make my mobile app do less, then I’ll serve up CSS, JavaScript and, when necessary, pre-rendered HTML. I’ll use Sinatra or similar here because I can be ready in minutes. The API is given an easy to read url allowing the mobile app to hit different versions or environments with a quick url change.
With this technical base in place I can start dealing with the product uncertainty. There is a trend I am seeing in mobile towards smaller projects. The less you have to do the more certain you are about what you need to do. Smaller projects also call for smaller teams and lighter processes.
“I see a correlation between failed mobile projects and large teams… The traditional mindset of one person per role is too big.”
I see a correlation between failed mobile projects and large teams. I think the effective limit on mobile teams is six people. The traditional mindset of one person per role is too big. Everyone must be poly-skilled, and there are no managers. If it ‘doesn’t scale’, I don’t care.
More people make more things. The more people you have, the harder it is to steer through the uncertainty and pivot quickly when you need to. A small team working on end-to-end delivery putting it together bit by bit will get the right result. End to end delivery teams are very important. My mobile application is part of a larger ecosystem. To deliver value I have to be able to change whatever I need to.
The process has to become lighter, too. Fewer meetings, more conversations and no iterations. I don’t estimate, I just do the next most important thing. The story wall on my projects are truer in form to the information radiator. If we need something electronic, we choose something lightweight like Trello over heavier, more opinionated tools. I believe all of this is applicable to larger teams too, but they’re already moving slowly don’t often feel the same pain.
This brings me to what does mobile mean. How we interact with mobile has changed significantly over the last 5 years and will continue to change. No matter what your mobile app does, what doesn’t change is that your mobile app is accessing your data. The API to your data is your killer app.
My intention is to squeeze the mobile app; stripping out any superfluous behaviour. All of this, the decoupled backend, the thin mobile, the responsive web are all just tactics I employ for my larger mobile strategy. Think of the micro-service, small enough that it’s easier to rewrite than to maintain. Can you do that with mobile? My goal isn’t to build an iPhone App, and it shouldn’t be yours either. My goal is to make building new apps easy. This is how I defeat uncertainty, by being certain I can change.