Summary It is an often-quoted and time-honored maxim that "a mediocre plan well executed is far superior to an excellent and detailed plan which sits unimplemented." So it is with modern software development. It does no good to have a rigorous plan and development methodology if it is too inflexible to adapt to the reality of iterative learning. "Different development projects require different levels of rigor and experience" is the best guide to understanding how much formality the development process can both bare and benefit from. Then there is dealing with the unexpected. As you develop and test your mobile solution, things will invariably happen that will force you to change your plans in some significant way. Count on it and have a process that can handle it. So in chronological order:Have a development methodology and stick to it. In this chapter, I have presented one and elaborate on it more in the following chapters. It is a good methodology for mobile device development. If you find your needs differ, modify the methodology, but do have a methodology.Have a single top document that defines your goals and tracks your progress. The level of formality of this document will depend on your organization. If you are a single developer working alone, the document may simply track the high-level goals and scenarios, your milestones to get there, and track undone items that need to be addressed; it need not be more than a few pages long. If you are a larger organization, this document may represent a formal contract between you and other organizations that tracks in detail what is being delivered, the design decisions being made, and detailed milestones and status along the way. Have a document that you can live with and keep "live." Make it a single document that represents the goals of your project and honestly tracks your progress.Define milestones with well-specified exit criteria. This is the best way to keep yourself and other members of the development team honest. A set of clearly defined milestones that tracks your progress to completing the application and meeting the defined goals is an invaluable asset whether you are working alone or in a large organization. The value of milestones can simply not be overstated. If you are unsure how many milestones to use, I recommend starting with five. If you cannot break up your project into five measurable steps, it is either so trivial it can be completed in a day or two or you are just not trying. Five milestones represent a reasonable number to start with and allows for a reasonable level of granularity in your development progress. For larger projects, you may find it desirable to break these milestones into smaller sub-milestones; for smaller projects you may get away with four, but try not to go smaller than that. These milestones serve three important functions: (1) They allow you to honestly measure your progress to a known goal, (2) they allow you to reassess your goals and future milestones and incorporate whatever learning you have done along the way, and (3) milestone exits define a formal time for review, code cleanup, and any rationalization of the design that needs to take place. Without milestones and end-of-milestone cleanup, there is a strong tendency for coding to occur without interruption and for all coding decisions to become tactical fixes. This results in an unmaintainable spaghetti mess. You may or may not set dates to your milestones; the larger the group the more important target dates become. The most important thing is that everyone needs to cross the current milestone finish line together before moving to the next milestone. Milestones are your friend, use them!Be guided by performance. For mobile device applications, usability is king, and your mobile application's performance will have an overwhelming effect on its usability. As your development progresses, unresolved performance problems will only get worse; this is an absolute truism. The constrained memory and resource models on mobile devices are a significant difference from the more elastic model present on desktops. Set strict rules about your applications' performance and responsiveness and hold your development process to them. Tie solving performance problems to milestone exit criteria. Performance will be the final arbiter of what your mobile device application is capable of achieving. The silver lining to this dark cloud handing over your development process is that good mobile device performance is achievable. It is achievable through good design, disciplined process, and creative problem solving. Developers operating in a "desktop mindset" may hit a performance problem and just assume that devices are not capable of doing what they want to achieve. By and large this is a failure of imagination on the developer's part. Through good user interface design, having an explicit data and memory model, and good communications model design, there is little modern mobile device applications are not capable of. |