Sunday, September 16, 2012

The KWSN Guide to Rapid Mobile Application Development

I think I'll start actual content off with a pet topic of mine, that being Rapid Mobile Application Development [perhaps Rapid User-centric Mobile Application Development for the acronym win].  This not to say that the methodology as described below couldn't be used for any other kind of development, but mobile is my present area of expertise.  What I love about mobile as an environment is that it brought the focus back to getting the User information in as few steps as possible. As a result of the 'minifying' influence of the mobile revolution, applications don't have to be complex to be profound and effective.  We're seeing major innovation in a field that was starting to stagnate, simply because it doesn't take a massive industry player to generate an app that will move millions - free market at its finest.  So whether you're a seasoned veteran or a fresh face to coding, heres how THIS Software Engineer approaches mobile application development:

Phase 0 - Tools Development and Evaluation

Outside the periphery of the process described below, development, enhancement, and evaluation of frameworks and toolsets for the development team should not be ignored.  There are a lot of time and effort saving solutions out there that can facilitate and speed up development significantly!

Phase 1 - Initial Concept

Fundamental to any software project is the core concept to be delivered to the User.  In many cases, this initial concept will be relatively short and vague, somewhat in the nature of a Mission Statement - “I want to enable a <type of User> to be able to <do something>”.  One goal statement should be defined for each anticipated type of user of a product.

Phase 2 - User Stories / Wireframe Design

From the initial concept, a set of user stories are extrapolated and organized into a basic set of wireframes.  These wireframes are/become the overall information flow of the finished application.  The details of the user experience, such as appearance, animations, etc; are not typically put together at this point, but having the basic information flow and a good idea of the tasks a user will need to perform at each stage of the information flow allows development to begin.  In addition, This set of use cases and wireframes imposes a natural boundary on the scope of the software development effort.  
This style of application development is a top down approach, relying on user needs to form the scope limitations of the project, as opposed to developer limitations.  If engineering considers a given feature to be unnecessarily difficult or impossible, the story is shelved for later and the user stories are redrawn to meet User needs as best as possible without the feature. 

Phase 3 - User Interface Implementation

Note that at all points, the User needs are the priority.  A commonly heard counter-argument to this philosophy is that a UI will often change, but the underlying business logic will always be there.  Shouldn’t, then, the development focus be on developing the core of the product and then, when the core is well on its way, designing a UI to fit that core?  Many organizations have developed this way for some time, with varying degrees of success.  The goal of this strategy, however, is one of speed.  Remember that the end user will experience nothing of your ‘core product’ that they cannot access through the UI.  In developing the UI layer first, one can define the set of interfaces expected from the underlying system, even if that system does not exist.  The product is then ‘code complete’ when the underlying ‘core product’ meets the expectations of the UI.  In MVC terms, we develop the Views and the Controllers to determine what we expect out of the model, potentially saving unnecessary development effort in the core product due to poorly defined boundaries.
So, In coordination with the continued UI Design effort, development on the UI should now begin.  For most mobile application development, the user interface comprises the majority of the development effort, and in making use of MVC / MVP patterns, the UI also comprises most of the overall application structure.  At this point, UI elements should be written to pull data from interface/protocol objects that will eventually become our model.  The developers working on the UI should also write mock implementations of those objects, returning static/hard coded data as appropriate to the situation.  Meanwhile, the UI developer is working closely with the designer to add in the various pictures, textures, colors, and components that will comprise the finished product.

Phase 4 - Model / Complex Behaviour Development

As the definition of the interfaces/protocols defined by the UI solidify, work should begin on the Model implementation, as well as any other complex behaviour your application might require.  The scope of effort put in to model development should be limited to the interfaces required by the UI, and with a well defined interface/protocol, is relatively straightforward development.  Complex behaviours, of course, vary depending on the application being developed and are beyond the scope of this document.

Phase 5 - Debugging and Testing

Nominally, you’re finished!  But of course programming is the process of putting bugs in, so at this point you’ll want to ensure that your application meets your own defined expectations of quality.  Remember that users will forgive the occasional bug, especially if the developer is responsive to their complaints, so don’t spend too much time in this phase - just get the product to the point where it seems like something you’d want to use.

Phase 6 - Deploy, ???, Profit!

You’ve finished and your app is on the market! Congratulations are in order - you’ve sat down to do something and by golly you’ve done it - the world of Play/App store awaits!

Additional Considerations

  • Keep in mind your feature backlog while developing.  It’s a lot easier to code a new feature in later if you think about how you might implement it in the future - often just thinking about it briefly makes you structure your code better and more flexibly.
  • Don’t get too bogged down in architecture to begin with - pick a pattern, draw out a quick class diagram on paper, and start coding.  Often you’ll find a pattern that works for you as you go
  • As has been said many, many times, code to an interface[protocol] - not an implementation.  Even if you only ever write one implementation of an interface, code written this way is almost always flexible, easy to work with, and easy to understand.  You can certainly go overboard with design, but find the balance that works for you and you can't go wrong.

Saturday, September 15, 2012


Tempting though it admittedly was to have this domain and not actually produce any posts [LOL null], it seems counter to the principle of starting the thing if I'm not going to at least try to fill the vast emptiness of blogger's disk space with my assorted musings and ramblings.  To that end, I might as well put up some background as a means to get started.

I am a Software Engineer - and when I say engineer, I mean it.  A Software Engineer is one who constantly seeks to hone their skills, to learn and absorb tools and techniques that let them build faster and better.  They seek out the right and the wrong way to do things, always growing in their capacity for complexity.  Sadly software is still a vocation in which it is all too easy to ignore the Engineers among your development staff and push on through with shoddy workmanship because 'business knows best!'  It's all too easy to ship out a rickety house and call it a mansion.  It's all too easy to stretch a terrible UI over the top of an overdone back end... I could go on, but in short, it's all too easy to build crap; and for some reason, in this discipline crap is tolerated.  This is changing slowly, as Apple and Google hone their interfaces with polished precision, previously dormant Users are growing to expect applications that aren't crap.  Such is where the lay of the land when I burst [show up] onto the scene - young, but eager to seek freedom for the poor masses forced to cower behind frightening form based monstrosities!  I will help lead them into the light of tactile salvation!  I am their knight in shining armour! Or at least I hope to become so... for now I know my limits, and I do my best to make my tiny part of the software world clean, flexible, and easy to use - because in the end, thats what a Software Engineer is meant to do.