Software Scouting And Recon

Scouting and Reconnaissance in Software Development

Abstract

Scouting and reconnaissance are two well known methods of discovery. By these means information and experience are gained when faced with the unknown. Experience is critical to writing good software. Experience allows you to correctly identify problems and address them. Scouting and recon for software development is a great way to gain experience and avoid the pitfalls of the unknown.

Introduction

In the well known book �The Mythical Man-Month� Frederick P Brooks states:

Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.

As the years passed and systems grew in size and complexity it became apparent that building a "throw away" as not the most efficient approach. In the 20th anniversary edition of his same book, Brooks states that developing a throwaway version is not as efficient as iterative approaches to software development.

In Extreme Programming Explained Second Edition, Kent Beck states:

"Defect Cost Increase is the second principle applied to XP to increase the cost-effectiveness of testing. DCI is one of the few empirically verified truths about software development: the sooner you find a defect, the cheaper it is to fix it."

Scouting and recon techniques are used to discover defects through experiments and to completely avoid the presence of the defect in the "real" software. These techniques work within phased or phasic development methodologies as well as within iterative methodologies and give knowledge and experience through their use.

Gaining Experience

There are many software development activities concerned with gaining experience. Some of these activities include creating proofs of concept, prototyping, and experimenting. I will refer to all of these activities as experiments.

How much effort should be placed in an experiment? Enough to gain the experience needed to get you to the next step.

Software Scouting

�Scouting� will be the metaphor. During the exploration of the American frontier, scouts were sent out ahead of the company to determine the safest path through unknown and hostile territory. Through software �scouting missions� one can save time and money, and reduce the risks to the company.

Brooks� first statement concerning building a "throw away" is akin to exploring the entire route first and then moving the company. His revised statement concerning iterative development is akin to scouting out a few hours (or days) ahead and returning to guide the company. This pattern of short scouting trips would continually repeat, making the technique both iterative and incremental. Through the scouting metaphor you can gain a certain feel for why building a "throw away" version is more costly than iterative development.

Scouting Tools

There are many ways to explore the unknown. These activities have many similarities. One of the key differentiators is the stage of software development in which the activity occurs. Following various "tools" for scouting are defined and the stage in which they are typically used is specified.

A "Proof of Concept" occurs after a solution has been conceptualized. Investigation is needed to gain confidence and verify the viability of the solution.

A "Prototype" is made after a design has been made. Investigation is needed to validate that the result of the design solves the problem. In software prototyping development activities are scaled back. In engineering prototypes may be scaled functioning models. In software there is no physical dimension so development activities are scaled back which include minimal effort for robustness and usually only implementing the HappyPath of the functionality. Also techniques to reduce coupling are skipped and cohesion is ignored as much as possible (Even though these activities are skipped the experience of prototyping bring to light how the software components should be coupled and an overall domain definition emerges that allows for better cohesion).

Ed Mauldin explains prototyping as thus:

�Prototyping is probably the oldest method of design. It is typically defined as the use of a physical model of a design, as differentiated from an analytical or graphic model. It is used to test physically the essential aspects of a design before closing the design process (e.g., completion and release of drawings, beginning reliability testing, etc.). Prototypes may vary from static "mockups" of tape, cardboard, and styrofoam, which optimize physical interfaces with operators or other systems, to actual functioning machines or electronic devices. They may be full or sub-scale, depending on the particular element being evaluated. In all cases, prototypes are characterized by low investment in tooling and ease of change.�

An "Experiment" occurs after software modules have been developed. Investigation into their behavior under varied conditions is needed. An experiment is conducted to observe the behavior.

A "Mock Object" is created during software implementation. Components have been developed and investigation into their behavior needs to be done. To isolate these components from the effects of other components the other components are replaced with "mocks" that have simple and specific behavior.

A "Driver" is created during software implementation. Components have been developed and investigation into their interfaces and usability need to occur. A driver is developed to interface with and drive the component. The interfaces or entry points of the components are confirmed correct and the pre-conditions of the components are exercised. The driver can validate the post-conditions of the component as well.

A "Stub" is created during software implementation. Functionality has been developed and investigation of the code paths needs to occur. Called interfaces are developed with the simplest means in order to return specific results and exercise the code paths of the caller. These simple interface implementations are stubs.

A "Simulation" is typically created after the system is implemented. A deliverable needs to be tested in various environments and conditions. A simulation of an environment is developed and it is used for testing. Common examples are simulated users, simulated load, simulated outages, and such.

When to Scout

Remember, scouting activities address the issue of gaining experience in unknown territory. These activities are not necessary when experience is present. Simply said, �If you know how to do the job, then do it!�

When one is in unknown territory scout ahead for information, then come back and apply the knowledge gained. Have enough discipline not to get distracted by the sights along the way. Stay focused, travel light, and get back to camp as quickly as possible.

Can you afford not to scout ahead? The answer to this question only comes at the end of the journey. Did you make it to your destination or not?

Scouting for Phasic Methodologies

One reason that experiments work is because they address issues and concerns in context and as they occur. It is a "learn as you" go approach. Below are some scenarios in which scouting can be used in a traditional phased or phasic methodologies.

Phase 1: Analysis and Requirements.

� Paper prototypes of the user interface . � Proof-of-concept of a requirement (i.e. the database must support 500 simultaneous connections).

Phase 2: Design.

� Refined paper prototypes of the user interface. Paper models of the architecture and model (i.e. UML).

Phase 3: Implementation.

� Develop an experiment for the �happy path� to discover boundaries and interfaces.

� Create prototypes ahead of implementing frameworks so that the framework's approach can be reviewed.

Phase 4: Testing.

� Create experiments to test scenarios.

� Create testing harnesses that allow for proxy users (a proxy user can be a user simulated by a computer program).

� Simulate extreme conditions such as system load.

(Testing is scouting ahead of the user to make sure the user�s experience will be a good one.)

Scouting for Iterative Methodologies

User Stories

Create a proof of concept to verify the User has conveyed their desires.

Project Planning

If the user story involves a User Interface, create paper prototypes of the interface to stimulate user input and direction.

Release Planning

Create a prototype to identify dependencies to facilitate iteration planning.

Iteration Planning

Create design prototypes using a modeling language such as UML.

Iteration

Create stubs, drivers, and mock objects to increase confidence in the behavior of isolated units.

Create an experiment to observe object behavior.

Create a simulation to test things like performance under a heavy load.

This list is supposed to be thought provoking, not complete. The idea behind scouting is to perform some scouting activity when faced with the unknown. When doing experiments in conjunction with an iterative development methodology the experiments are "lighter" than they would be in a phasic development methodology if the customer/user is taking an active role. With the customer present one can prototype a user interface with a white board and some drawings. If the customer is not present then a prototype for a user interface is usually mocked up with some kind of computer aided drawing package or even a "quick and dirty" user interface is developed with a GUI building tool or scripting language.

Benefits of Scouting

Scouting brings light to a situation. Through scouting activities estimations become more accurate. The accuracy comes from the application of the experience, not from an improved ability to predict the future.

Scouting reduces coupling and improves cohesion. When writing software in the light of experience, the coupling between objects is reduced and the experience unifies the system's terms and metaphors which increase cohesion.

Scouting builds trust and confidence by eliminating incorrect notions and avoiding drastic changes in design and implementation.

Risks of Software Scouting

Is management mature enough to allow the proper use of an experiment and not try to �ship� the prototype and undermine the effort?

Is development mature enough to refrain from features creeping into the product because the experiment revealed something interesting?

Project Management Ensures Adequate Software Recon

Project Management should scout and see if their development environment can support activities that rapidly gain experience.

Probing questions include:

Are the software developers aware of all of the activities that can lead to experience?

Are the stakeholders aware of the benefits of prototypes and experiments?

Is everyone aware of the risks of not doing recon and the risks of doing recon? Remember, one of the risks of a prototype is that sometimes people try to ship it!

An interesting exercise would be to listen for concerns expressed by developers and ask them what activity would address their concern. Some concerns expressed by developers that can be addressed through recon are:

�If I just had time to write this right�

�I don�t think we know how difficult this is going to be�

�I really don�t have any idea how long this is going to take�

When a concern is expressed ask the developer what they would do to address it. Listen for solutions that bring experience and shed light.

Conclusion

Experience is key to writing good software. The sooner you discover a problem and correctly fix the problem the cheaper it is. Scouting ahead in software by using prototypes and experiments is a great way to discover the right path without risking the entire company to the unknown.

GeoffreySlinker?

http://home.att.net/~geoffrey.slinker/maverick/Scouting.html