This week I had several almost-accidents when riding my bike because my brakes was worn out. For every incident I got more careful and lowered my speed.
I changed my brakes, and I can tell you, it was a revelation. I could go much faster, and could stop almost instantly when required. The effects are only positive: I can go faster, safer and it is more fun. The safer part means I don't risk hurting myself and others. Good brakes kind of set you free.
During my first ride with the new brakes it struck me that this has analogies to many professional life as a programmer. When programming it is very easy to assume you have understood requirements, the technology I am using and all kinds of other assumptions.
Developers, projects and organizations should integrate feedback and brakes in their work. Good brakes is useless without proper signal to use them.
A brake in programming can be incarnated in several forms, which I will try to show here.
A programmer should listen to all feedback provided from compiler warnings, automatic- and peer code reviews. When struggling to name a software artifact, stop coding and take a break. Find a colleague that can act as a rubberduck or ask for advice. Do pair programming.
Unit tests provide concrete signal (when done adequately), and will in some ways act as a brake. They can let you refactor, delete and improve code more freely. A good test can also stop you from implement plain wrong functionality when you can not satisfy correct asserts in any way.
Likewise performance tests, security reviews, coding guidelines etc can act as signal to brake when things are going in the wrong direction. The more you can automate of these things, the faster it will let you go.
I think the principle of integrating feedback and brakes in all work done in an organization is valuable. For software projects frequent releases will provide feedback, and tell you occasionaly to clutch the brakes. Open discussions in the project can reveal bottlenecks and inadequate ways of doing things. No topic should be avoided, as avoidance can hide potential problems.
Requirements must be asserted too with prototypes and design can be explored and refined with CRC
A promising new technique that is beeing developed for decision making in software architecture can provide a much tighter feedback, brake and correction loop. I think the boardgame approach can be adopted for a lot of complex decision making processes.
A Policy Advisory Board (PAB) will be responsible for overseeing obedience of common rules and update outdated rules. At the organizational level the same yields as for projects regarding open discussion. Let people discuss freely, use wikis, and microblogging to unlock knowledge about inefficiencies.
The key observation of brakes, is not only the slowing down aspect. It is also about changing direction. Changing direction at high speeds may be impossible, risky or it has to be done with a large turn radius. Slowing down for a moment improves your quickness.
Now after a lot of talk about brakes it is important to state brakes are essentially a hook into work processes. These hooks should let people intervene to change direction. The brakes does not provide the required decisions that must be made, just an opportunity to make them before too much damage is done. They also provide excellent opportunities to learn. Failures is valuable learning and is an integral part of an learning organization. Learning is, amongst other things, effectively brake checking and the loop is complete.
