PP16: Applying Agile Programming Principles to IETF Protocol Design

[Lisa Dusseault <[e-mail]>]

For those attending AAAW next week: This brings the total to 16  
papers, with 3 days left.  If you haven't read any yet, that's 5  
papers per day...

Lisa


Applying Agile Programming Principles to IETF Protocol Design

Tony Hansen



Back in the early days of the IETF, many of the protocols were  
created from the ground up and the documents written afterwards. The  
mantra ‘running code’ reigned. Many protocols were written this way  
and became full standards.

Over the years, this method of creating protocols made way to follow  
more closely the waterfall model of software development: a proposal  
would be made, requirements would be written, and subsequently a  
design would be written. The protocol would sometimes wither and die  
at this point, as implementations may or may not be written.  
Sometimes the protocol would get implemented and be found wanting,  
requiring revisions and recycling back to proposed standard.  
Sometimes the protocol would actually make it, but rarely would a  
protocol get revised in order to make it through to the full standard  
status.[1]

(Concomitant with this trend has been the increased participation in  
the IETF by “professional standards people” and the decreased  
participation by engineers.)

In the software world, it’s been found that there are many flaws in  
the waterfall model, and other models have been proposed that attempt  
to alleviate those flaws. In particular, some other models are  
iterative development, incremental development, extreme programming  
and agile programming.  Proponents of the Extreme Programming   
practices claim that “exercising these practices—traditional software  
engineering practices taken to so-called ‘extreme’ levels—leads to a  
development process that is more responsive to customer needs  
("agile") than traditional methods, while creating software of better  
quality.” [2]

Here’s an overview of agile development methods from Wikipedia:[3]

There are many agile development methods; most minimize risk by  
developing software in short amounts of time. Software developed  
during one unit of time is referred to as an iteration, which may  
last from one to four weeks. Each iteration is an entire software  
project: including planning, requirements analysis, design, coding,  
testing, and documentation. An iteration may not add enough  
functionality to warrant releasing the product to market but the goal  
is to have an available release (without bugs) at the end of each  
iteration. At the end of each iteration, the team re-evaluates  
project priorities.

Notice the emphasis on quick iteration, with a complete set of  
development steps occurring in each cycle. Also notice that each  
cycle does not necessarily end in a finished product.

Is there a way that we could make use of similar principles in IETF  
protocol development? And if so, what benefits can we possibly achieve?

What if a working group were to develop protocols in the following  
order?

Work on requirements
Work on an area of the design
People implement the updated design
Test implementations in an interoperation event
At the end of each cycle, you then check for these things:

Were the implementations able to interoperate?
Does the protocol still satisfy the need?
Is the design complete? Are there any areas not completed yet?
This continues until everyone agrees that all of these criteria have  
been satisfied.

During each iteration,

The purpose of the requirements work is to refine the requirements  
from the previous iteration using the insights gained during the  
previous implementation effort and interoperation event.
The purpose of the design work is to pick off another part of the  
whole. You do not need to have everything perfect in all areas of the  
protocol, but instead can focus on a smaller piece of the protocol.
The purpose of the implementation step and interoperation event is to  
gain insights on those portions of the design that were worked on  
during this cycle, as well as how well things work together.
The output of each cycle is an updated version of the requirements  
document and the design document(s), that is, updated internet drafts.

Only when the exit criteria have been fully satisfied do the  
documents get published as RFCs.

Notice that it is conceivable that an entire cycle can be  
accomplished in the time between IETF meetings. The interoperation  
events could potentially occur during the IETF meeting week.

Note also that

There is a renewed focus on running code.
At the end of the cycles, in addition to the protocol description,  
you have multiple interoperable implementations.
It is conceivable that protocols developed in this fashion could be  
considered to be Full Standards right out of the box.
The key to making this work within a cycle is focusing on only a  
portion of the design each time and not trying to solve the world’s  
problems each time; focusing in on a smaller piece of the puzzle.

A BOF is still useful for determining if there is interest in working  
on a proposed protocol, and as a way to encourage initial  
requirements and designs for it. They would prime the pump for the  
working group cycles.

The style of managing a working group would need to be more directed  
towards forcing a workable set of code at the end of each iteration.  
It also requires a thought process that allows certain parts of a  
protocol to be left unfinished while working on other portions of the  
protocol. This requires a somewhat different set of skills than is  
commonly found in current working group chairs. It also requires the  
working group to be in agreement to use this methodology.

This methodology is oriented toward

Brand new protocols
Discrete extensions to existing protocols[4]
This methodology is not oriented toward small increments to existing  
protocols.

Summary: I propose running a process experiment.


[1] A case in point is the Message Tracking protocol. It had lots of  
support during the requirements and design phases, but when it came  
to being implemented after it was published, forget it.
[2] http://en.wikipedia.org/wiki/Extreme_Programming
[3] http://en.wikipedia.org/wiki/Agile_software_development
[4] For example, many of the proposed IMAP extensions are of this  
nature.