• Recent Articles
• By Topic
• By Year
• About me

Fast Feedback

28.02.2014 Permalink

Uncertainty is a permanent companion when developing non-trivial software systems. The combination of technology, industry, organization and individual constraints that we find in a project is almost always unique. There are hundreds of decisions that have to be taken, and it's hardly possible to foresee all consequences for even one decision on a theoretical level.

Certainly the costliest mistakes we can make is building the wrong system: software engineers believe they understood exactly what users need but they err. Even if the project team documents all requirements in a precise specification odds are that users or their representatives are not able to check if the described system will meet their true needs. This is a well-known risk and agile processes aim to mitigate it by delivering increments of the system on a short-term regular basis.

The underlying principle is fast feedback. We acknowledge that building a complex system is actually more trial-and-error than a linear, foreseeable process. So we produce artifacts that can immediatly be judged by stakeholders. They provide feedback, the creators recalibrate the product and the result is true progress. Agile process methodologies usually apply this principle to the whole system only, but actually there are numerous opportunities to apply fast feedback in a project.

Many days before the first line of code is written usability engineers have the chance to elicit needs and context information from users by jointly working on cheap (paper) prototypes of the user interface. While users always have a hard time describing their needs in prose they can usually decide quickly if an imaginary UI supports their workflow or not.

Another area where feedback is invaluable concerns the architecture of a system. Instead of just plumbing available libraries together in order to produce the first increment with business value, a careful implementation of a few simple use cases on the basis of a rough architecture blueprint reveals deep insights. The result usually has no business value. Developers learn if and how things fit together. They are able to conduct very early load tests to learn about scalability.

A project team that uses a continuous integration (CI) system practices fast feedback. A developer quickly notices if her changes break the existing code base and can apply a fix to it. Here, the importance of "fast" becomes visible: since the feedback is given within few minutes there is no mental context switch necessary, so the fix will usually take only a blink of an eye.

Code reviews are the most effective (and usually cheapest) way to improve on code quality. Actually they promote code quality as well as developer skills at the same time. But in order to keep "technical debt" small these reviews must be conducted quickly, which means it's ok if they are informal and almost spontaneous. I found the combination of Git, Gerrit and Jenkins to be a viable tooling that integrates code reviews as a mandatory step in the CI process.

I have experienced more than once that early system testing of a software that is still under construction actually helps with product quality. Although bug reports for a half-finished system are sometimes a little disturbing for the developers it urges them early to recalibrate their quality standard to meet test expectations. In addition, the cooperation between test and development team is trained, which is beneficial when things start to get hectic.

As the last example in this row I'd like to name interactive development as it is practiced by Lisp developers. With Lisp and its REPL (read-eval-print-loop) it is common to change the running system. Lisp developers try out snippets of code in the REPL, one feedback cycle literally takes only seconds. They apply changes to the code base by using these snippets and what they have learned "in the REPL". The result is usually software that "just works" because it was written under permanent test. (But - of course - well-known test activities like unit testing and system testing remain indispensable.)

To conclude: I'm a firm believer in the merits of the principle of fast feedback. Examples of its beneficial application can be seen throughout the software development process. Therefore I tend to reject everything that may inhibit or slow down feedback: clumsy application servers, writing lengthy specifications up-front, long discussions on the basis of merely belief etc. We can certainly make more use of it if we actively seek for opportunities to apply fast feedback regardless of the process model.