Introducing: Mobile CodeCamps

One of the greatest rewards in life is the feeling of satisfaction that is gained when you are able to share knowledge with others. This is something that I have always believed and enjoyed doing with the teams that I have led or otherwise guided over the years. The mobile application landscape is prime with challenges and opportunities to learn and expand. For example, many of the best ideas in the mobile app landscape were not born from people with a hardcore development background… Instead they came from Joe Simple and Jane Realist… In other words, regular people that see the world and its challenges very differently from those that are trained to see problems at the code level. This is the objective of our code camps – to bring a new fold of creative thinkers (normal everyday people) up to a level that will allow them to bring some #awesome #ideas to market.

Not a crashing-crash-course

This isn’t going to be the typical two day crash course, but rather an interactive, hands on series with a physical classroom presence. We chose this option because with a classroom setup, the team will be able to work with our students at the individual level. We don’t want anyone to leave without having a full grasp of all the content that we deliver. At the end, we are aiming to have all students leave with 100% retention of all the skills that are delivered.  Don’t worry though, the entire class content will be available online for those that prefer to learn at their own pace (URL to be provided at a later date, but if you are excited send an email to info @ to be added to the early access list).

In addition to the above, the courses are structured in a modular fashion that takes the student from #ZeroToHero in a short time, by covering basic programming constructs all the way up to advanced topics bridging into software architecture. Students will have the ability to pickup modules where they are most comfortable.

So, who is this course for?

Well, the course is primarily for people that have no programming experience. If you have considered a career change, or you just have great ideas but have no knowledge of the app development process; the series is written just for you!

In summary, we are very excited to see the brilliant apps that will be born out of this course and look forward to working with each of you in the near future.

– Martello Jones


Breaking the monolith: scalable native apps

Building one-off apps that have a single focus (for example games, picture viewers or “ToDo” apps) is relatively easy because those apps can be designed, tested and implemented in a wholistic manner.  In other words, the product teams that build those apps have a very clear picture of what the end product will be. Banking or telecommunications self-serve apps on the other hand are often less clear or constantly evolving.  These apps are generally produced by large organizations with competing or conflicting  internal objectives, timelines and budgets – as a result, these apps (when built as monoliths) are delivered late to market because each feature that is owned by a sub-division of the company has to wait on one or more major pieces provided by other sub-divisions.

How can these apps get to market faster?

Simplify, decompose into reusable units and break dependencies – In other words, large apps can get to market faster by going back to the basics of software design. Let us use a simple example of a restaurant app… Let’s call it is (fictitiously) an app that allows a customer to submit an order that gets prepared by a crowd-sourced chef… (Before I go any further, I would like to shamelessly ask that if any reader wishes to build this app, please credit back to this site for inspiration :-D, please and thank you!!!). The app must be available on Android & iOS and must be launched on the same date.

Implementing this is relatively straight forward. Build the app, ship it. How we build this app however, will determine how quickly we can iterate on its features in the future. The typical approach here would be to have a single project with all the logic embedded, maybe sorted by folder structure or package name.


This approach works, but we can definitely break the app into discrete units.

Step 1: Create a core component that does the basic functionality

A good example is to create an application scaffold that provides the UI layout and interaction design. This scaffold will reference the components defined in step 2 by library version and also have any visual integration points that are required.

Step 2: Identify the discrete functions of the app

In CookR, this could include taking an order, sourcing a chef, providing status update via push notification or processing payments. These units would then be built as components/libraries that can be uniquely versioned, expanded upon or completely re-written at any given time without affecting the progress or delivery targets of the overall application. This also means, that each of these components can have their flows defined and implemented in total isolation. In the case of a large organization, this translates into a situation where separate sub-divisions can quickly meet their own objectives and deliverables without affecting other teams, unless of course they have a hard dependency on a specific version of another component.

Step 3: Integrate each component

With steps one and two out of the way, integrating the components will be a breeze. The only requirement here, is that the core application scaffold defined in step 1 creates visual entry points (buttons, links etc.) that will trigger calls into the components. The components can then take over and deliver the experience that is defined in that component.

Our decomposed application now looks like this:


As you will see above, the overall application is now less brittle to changes because stable versions of the components (libraries) can be referenced by specific iterations. Departments are then free to re-use, re-create or otherwise augment the functionality provided by these libraries at will. In our example, if the organization decides that the application needs to go to market with a Chef Sourcing functionality that has Facebook integration on March 9… This structure allows all the team to build this entire flow in Chef Sourcing 2.4.1 without affecting any existing code that depends on 2.4.0. The improvements can be unit and functional tested independently without a single code merge request until required (lets say march 7 for example). In practice, the date may not be so close, but the key thing here is that on March 7, depending on the UI design for Facebook integration this feature could be delivered to market with zero code changes to the application, since code changes were only done in the Chef Sourcing library that is consumed by the core application! Neat right?

Of course, this doesn’t account for crazy scheduling or other factors but this approach to mobile application structure opens up a world of possibilities for cross functional team collaboration and faster application delivery.

This is the high level concept… Next week I will use the example to illustrate how this can be done on both iOS and Android…

#UntilThenCodeTight #HappyMonday

-Martello Jones