In Steven McConnell's book,
"Code Complete" he describes why a person should not jump right in and start developing code for a mobile software solution for use on handheld PDAs on the first day that the business thinks it is a good idea. Often business motivations help drive a sense of urgency to start coding a software application immediately, but there are also business motivations NOT to start today. Coding without gathering ALL the requirements and architecting the system has a high cost.
Here is an excerpt from McConnell's book that is very interesting and true:
Explicit requirements help to ensure that the user rather than the programmer drives the system’s functionality. If the requirements are explicit, the user can review them and agree to them. If they’re not, the programmer usually ends up making requirements decisions during programming. Explicit requirements keep you from guessing what the user wants.
Explicit requirements also help to avoid arguments. You decide on the scope of the system before you begin programming. If you have a disagreement with an other programmer about what the program is supposed to do, you can resolve it by looking at the written requirements.
Paying attention to requirements helps to minimize changes to a system after development begins. If you find a coding error during coding, you change a few lines of code and work goes on. If you find a requirements error during coding, you have to alter the design to meet the changed requirement. You might have to throw away part of the old design, and because it has to accommodate code that’s already written, the new design will take longer than it would have in the first place. You also have to discard code and test cases affected by the requirement change and write new code and test cases. Even code that’s otherwise unaffected must be retested so that you can be sure the changes in other areas haven’t introduced any new errors.
...Data from numerous organizations indicates that on large projects an error in
requirements detected during the
architecture stage is typically 3 times as expensive to correct as it would be if it were detected during the
requirements stage. If detected during
coding, it’s 5-10 times as expensive; during
system test, 10 times; and
post-release, a whopping 10-100 times as expensive as it would be if it were detected during requirements development. On smaller projects with lower administrative costs, the multiplier post-release is closer to 5-10 than 100 (
Boehm and Turner 2004).
McConnell lists 5 steps in the software development process:
- Requirements
- Architecture
- Coding
- System Test
- Post-release
There is simply NO way to bypass these steps for the purpose of saving time and money. If there is an urgent need for the mobile software solution, then there needs to be an urgent need to define the requirements, and architect the system so coding can begin.
I am continually surprised by the wide variety of business processes and geographical locations where our mobile software applications are being used. We are regularly helping with large mobile software projects in Africa. Who would have predicted that? Here are some sample applications:
