Methodologies: Differing Perspectives
A common problem when discussing the need for methodology, standards, etc. is the differing perspectives of team members. The table below contrasts the differing experiences of three individuals:
|Small App Developer||Legacy App Developer||Large App Developer|
|Functional Complexity of Application||Small/Medium: the size of the application generally constrains its complexity.||Medium: an experienced team member will generally find most enhancements straightforward. New application modules will be more complex.||High: Large new applications generally solve complex business problems in new ways.|
|Technological Risk||Medium: a small number of tools are used but the tools may be newer and less proven.||Low: existing proven tools are generally used.||High: application is built with a larger number of "modern" tools|
|Analysis||Initial requirements are often vague.
Analysis often involves are series of evolving prototypes with little associated documentation.
|Analysis/Design are constrained by existing
database design, screen structure, etc.
Analysis is smaller in scope and is often quite "physical" in nature.
Smaller scope means a moderate amount of less formal documentation is often adequate.
|A new application provides good opportunity to
do business differently. It is largely unconstrained by the existing business, database or
Analysis needs to be more logical/conceptual to properly model new business processes.
Resulting functional specification is thick and detailed. Document allows large team to understand and design/develop application.
|Design||Relatively little thought is given to design.
Components are added as the prototype evolves.
Good database design and code reuse is heavily dependant on the skill of the developer.
|Existing application constraints make most
application required changes apparent so design documentation can be brief.
Even new modules will largely following existing way of doing things for consistency.
|Need to understand most requirements before
solidifying application design.
Design is formal to ensure final application will operate and meet its constraints (e.g. performance, integration, etc.)
Good database design and code reuse is generally an important goal.
|Development||Development is heavily tied into analysis and design since the prototype continually evolves.||Small enhancements can often be quickly
developed by experienced staff who know the application well.
Development of larger modules may require a longer process as many team members have to coordinate their activities.
|Development is generally carried out according
to formal standards to ensure new application is maintainable.
There is a lot of coordination between team members as complex application is built so all components work together properly.
|Testing||Testing is often informal perhaps a "beta" where users discover many of the application problems.||Testing may be very informal ("just put
it into production").
Alternatively, it may be more formalized for business-critical applications to minimize business consequences of errors.
|Testing is generally very formal. Application
is tested to ensure it accurately reflects each point in functional specification.
Integration testing of various components is also important.
There is often a final "acceptance" test where users test the application and verify it is ready for use with the business.
|Attitude to Other Approaches||The small application developer usually views the large application developer as paper pushers who are unproductive because of their bureaucracy.||The legacy application developer generally takes the same view of large application developer as the small application developer does (i.e. they are bureaucratic).||The large application developer views the other two groups as "cowboys" who hack together poor applications.|
The point is not that there is a perfect way to develop all applications. The successful small application developer and legacy application developers turns out more code or functional units per man-month. Their method is often appropriate to the type of work that they are engaged in.
These developers must be careful, however. Scaling that same informal approach to a larger new application will generally result in a failed application which gets caught in an endless "testing" cycle. The testing cycle ends up being the place where the detailed requirements are defined and application design and interfaces get sorted out. The costs of sorting out these problems during testing of a large application are much higher (if the problems can be sorted out at all). In addition, if the application ever does make it into production, it will likely be much harder to maintain because of its weaker design and poorer standards.
... back to Methodology Topics