Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Development Is an Iterative Process, but It Does Have Rules

Few people today advocate the use of flowcharts to map out the functional behavior of applications. For one thing, the flowcharts would be immense. Today's model of event-driven programming, rich user interfaces, and the widespread availability of rapid application development tools make the concept of a flowchart mapping out all of an application's algorithms and user interactions seem quaint. Specific key algorithms can be mapped out in this detail if required, but by and large a higher-level approach is called for.

On the flip side, there is the ad hoc approach of "just sit down and start cranking out code until the application is done." Tempting as it is, this reckless programming approach is equally flawed and usually results in a messy ball of code that performs poorly, is riddled with bugs, cannot be maintained, and must ultimately be thrown out and be rewritten. These kinds of applications often appear hacked together or kluged for the simple reason that they are. All design decisions tend to become tactical answers to the question "How do I solve the specific problem I am facing right now?" with little thought given to the overall effect to the system at large both in terms of system behavior as well as code complexity.

In contrast to the ad hoc approach described above, one school of thought states, "Spec out the application in full detail before you write a line of code." Some projects with many developers may require this level of detailed coordination, but these projects also require the discipline to keep their specifications current if they are to remain meaningful through the development process. They also require a detailed level of foreknowledge about the end behavior of the application that is often not realistic to know ahead of time. Although admirable, the "spec everything to infinite detail" approach is usually not appropriate in modern development, particularly of first version products, because things will be learned and requirements will change as the product gets developed. This is especially true for mobile device applications, which may require field testing to understand how people will use them in the real world. It is important that a level of flexibility be part of the design process to accommodate learning and challenges that emerge through the development process. There should be a specification, but it should start flexible and move toward greater specificity as the product matures toward its completion.

It is important to pick a realistic level of process that you and your team can adhere to. Even if you are working as an individual, there is a level of self-discipline that it is beneficial to hold yourself to. Smaller projects, as mobile device applications tend to be, should adopt an approach that members can benefit from and buy into. Having too much plan breeds inflexibility when changes are needed. An overly rigorous and inflexible specification or plan will simply get abandoned. On the other hand, having no plan or too little process will result in a wandering product definition that will drift either into crises or mediocrity. There is a happy medium that is dependent on the size, scope, and maturity of the product you are developing. It is important to assess the size of the project and from there draw up a realistic process that will get you there.

Several great books exist on the subject of software development processes, so the remarks here are brief. The rules I have personally found to be essential in mobile software development are as follows:

Have a development methodology.
A methodology is a plan for how you will go about designing and writing code. The rest of this chapter is devoted to developing a methodology for mobile applications.

Have an explicit project plan contained in one central document.
Every project can benefit from having one master document that everyone has agreed to adhere to. A template for such a project plan is defined below.

Plan on iterating.
Changes will be required, and unforeseen problems will arise. Mobile devices are not closed systems, and successfully interacting with the user and the world at large is a complex process; you will learn as you go along. It is best to admit this and incorporate it into your planning process.

The Project-Description Document

For all software development projects beyond the most trivial, it is important to have a single "live document" that states (1) the project requirements and what the product will do when it is finished, (2) The design philosophy, (3) the architecture of the application, (4) current status of the effort, and (5) the plan that will bring the product from its present state to a successful conclusion. Large products may have additional subsidiary documents, but there should always be a key top-level document that states the essential goals, status, and plan. This document needs to be a living document that all team members agree represents the effort.

The single live document that drives the development process should be broken into the following sections:

The goals
This section of the document clearly states what the finished product will do and what the philosophy behind the project is.

The status
This section of the document accurately describes the status of the project at the present time. It is part of the logistical plan for the project and states where the project is along the path to reaching its goals. It should state which milestone the project development effort is working toward and what items remain to exit the current milestone successfully. Also stated should be a list of the biggest risks or unknowns that need to get resolved.

The application's architecture and relevant state diagrams
This information is the technical side of the plan. For mobile device applications, this should include the appropriate state diagrams that describe the discrete states that the application can be put into and how these relate to the memory and resources that will be kept in memory. (You will read much more on this later in the book.) This live design text represents the contract that all the development team members agree to adhere to in their implementation. If you are the sole developer, this document represents a way of keeping yourself honest; anyone who has ever built a large project by himself or herself will appreciate the temptation of cutting corners to get a feature working at the expense of good design. It is much harder to cut corners when you have an explicit contract defined that you need to state your proposed shortcuts in. This section should not be overly long or overly complex for the reason that it will be discarded if its use is onerous. It should state what is needed to keep the design organized and, importantly, it needs to be kept current with any agreed-upon design changes.

The development plan with discrete milestones identified
Even more than a schedule, a measured plan is needed that states the discrete milestones that your project will pass through to get to completion. By definition milestones are your way to track progress toward a defined final goal. Each milestone represents a resting point where you can stop to consider your progress, clean up code that has been left in a messy state, and adjust designs as necessary. The goals may change as your project progresses, and you may need to adjust milestones; this is fine. The architecture may change as your design evolves, and revised state models may be required; this is also fine. The user interface will almost certainly need to be revamped a few times. Achieving a prestated milestone (or failing to achieve one) is the surest way to measure your progress as well as to reflect on how your future path to the finish line needs to be adjusted. Milestones are your friend.

Plan on Iterating

You will learn things as you go along. Despite your best efforts at foresight, unexpected challenges will arise. You will hit performance problems and you will probably not get the user interface right the first time. Increased experience with mobile development means that you will hopefully make fewer mistakes in future development efforts, but you will almost certainly make some mistakes. Plan on design iterations during individual milestones and especially at the end of development milestones when you take stock of where the project is and what key problems have emerged. The iterative nature of modern software development raises the importance of having a design document that is kept current and a methodology that gives you a good capacity for iteration.