Raleigh Schickel, Manager of uShip Development and self-proclaimed videographer, created two renderings of the Android and iOS team’s development efforts of uShip’s first native mobile applications. He used Gource, an open source project, to create these visualizations of the uShip code base (https://code.google.com/p/gource/). Gource is a software version control visualization tool that shows the revision and commit history of a code base. According to the Gource website, “Software projects are displayed…as an animated tree with the root directory of the project at its centre. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project.”
Collin Bass, uShip’s resident DJ, added a mix of space-inspired music to guide you through the coding journey.
Why Visualize Software Development?
It’s mind-blowingly cool! Renderings or visualizations can help you analyze and uncover patterns and trends in the data. The outcome? Visualizations can help cut time, costs, and make your development strategy more efficient. The analysis helps decrease ramp-up time on similar projects. The analysis also helps engineering understand and manage large software systems more effectively.
The one that started it all…. The mobile development team made decisions about how to handle next generation applications by running a discovery period. This rendering shows those decisions with an additional 6 months of changes. Once the decision was made to go native, the in-house Android team worked with a head start. Notice in the Android video, there’s a distinct section where the entire visualization is wiped out and a new formation appears. That change marks the time when the Android team’s discovery period ended and they started native Android mobile app development. They deleted the code base from the discovery period and started fresh from that point.
July 2012 – May 2013.
The native iOS app wasn’t far behind… The mobile team then brought the dedicated iOS team on board. The delay between the Android and iOS projects explains why the length and patterns of development of the two videos are slightly different. The raw footage is much longer in the Android video. Note that both videos have been sped up to fit in the period of time when discovery, development, testing, and launch took place.
January – May 2013.
We sat down with mobile team leads to glean the lessons learned from developing the company’s first native mobile apps. These professionals come with years of mobile application development experience. They share their insights on building a successful mobile app for your office in a lean and iterative way.
Matthew de Anda, Android Developer
- Timebox research during the discovery period. For example, the mobile team looked at several solutions from a development strategy standpoint. The solutions they ruled out were based on the limitations of the framework, libraries, and technologies. They looked at each solution based on the need for the following:
- a great user experience
- ability to reuse and share business logic and code between Android and iOS development
- Prototype the solutions. The mobile team used Mono (http://www.mono-project.com/), an open source C# platform from (http://xamarin.com/), to see if they could build a framework to reuse logic and code for both native and Android and iOS app development. They discovered that since the UI was vastly different, they could not share that portion. Even though the business logic was shared, the UI had to have separate code to translate native concepts and standards. In addition, Mono had a steep learning curve, was difficult to maintain, and not enough information was available for research and implementation. The team chose the solution in the discovery period mainly because it was in C#, the programming language developers use in the main uShip.com product, with hopes that the mobile development could be shared among existing developers. In addition, other solutions seemed to be more expensive.
- Discovery and Prototyping may help you decide to Go Native. After the discovery and prototyping periods, the mobile team decided that building native mobile applications would deliver the best user experience.
- Native App Development by Dogfooding the API. The success of native app development which relies on consuming the API depends in close communication between all development teams. If your development team is developing the API for the mobile app, make sure that both the business and technical needs are described clearly so that both parties understand what is needed. Dogfooding the API has the benefit of internal consumption contributing to iterative design that makes the API easier to consume externally. In addition, the API and mobile app can quickly adapt based on Agile development when feedback loops are quickly closed.
- Plan Ahead and Speak Up to Stay in Sync. Building a client-server solution in an almost parallel manner requires a high level of communication between the mobile and API development teams. uShip addressed this issue by having the native team leads to closely plan ahead of the product pipeline to map out an interface for the API team to review and modify based on proper RESTful conventions.
Samuel Downs, Senior iOS Developer
- Each iterative version should have clearly defined goals for the release. Stakeholders can work together to communicate clear goals in the beginning so that teams have time to flesh out the implementation. Fleshing out the business cases 1st helps product managers and developers properly scope the work.
- Start with an 80% prototype to nail down the foundation or major core app functions. The prototype should include screenshots and working mock-ups that you can play and re-play. To nail down 80% the core functions, you get a feel for how the app will work and workflows using this method. When you play and replay the mock-ups, you can accurate test behaviors and real context. Then, when you go to build the app, you’ll have de ja vu when using the actual app because you’ve worked and reworked details and flows in the beginning.
- Keep the feedback loops small and specific. After coding and testing, the changes for each revision should be minimal and not major changes. Each revision is iterative and are large useful chunks of the minimum viable product.