All software design companies recognize how important it is to let its programmers make mistakes, as long as they have an established process. The idea of a branch-and-merge mechanism in version control software reflect this; the designer expects to experiment, make mistakes and fix everything before merging his code back into the code. While the programmers are not encouraged to make mistakes, making them in as safe a way as possible very often grants a team the freedom to make happy mistakes, where they learn a new trick, a simpler interface might be used or new approaches or functionality might be invented.
The team still has to work on a schedule, but the confidence to experiment new things is the first way to learn and improve. I believe it’s the best way of turning a team from good to great, especially if I use an agile approach. I recently saw a funny video about ‘The Institute of Mixing Random Things Just In Case the Result is Good” – it had a better name, but you get the idea. Random tests, mutations and errors are 99.999999% bad, but sometimes, very rarely, they are useful. Awareness of it is important and encourages the open mind necessary to realize that an unexpected result might have a positive impact.
Have you ever tried out something or given someone a task and they come back with something that isn’t at all what you expected, but it makes the rest of the project better? I could give you a few examples. An intern created a simple launcher (what I asked for) but stored more parameters than he needed to (a waste of resources at the time); it saved our bacon at a conference when the loaned machines needed a different configuration. A developer created an user-defined attribute system on top of the business objects (what I asked for), but the simple lightweight system meant that most of the previous storage code could be made irrelevant. Investigating performance problems of a tagging feature led to removing a very slow, convoluted and totally useless loop in unrelated database code. Have you ever experienced this rare, but happy, event?
This morning I was wondering if the capacity to ‘revert’ things could be applied to anything else. I know I often depend on ‘undo’ in my word processor to stop most of my logorrhea, or at least tide it back. I make a backup of drawings before I try to color them or edit them. It lets me screw up in confidence. But there are still plenty of places where I feel like I don’t know what I’m doing or if there’s a better way of doing it, and I can’t find out because I’m afraid to screw up. Take this WordPress platform for instance. There are a ton of options and features I have never used and might never even try, just because reverting to a state I like might be impossible.
So where else could I use recoverability? What software packages don’t have it but would be easier to learn if they did? Can I implement recoverability with simple, generalized backups in most cases? And do I actually learn to use my stuff better if there’s no chance of messing up? Can I apply this to everything? Can I make a team better by giving them a safety net? If I let a dev. team self-manage and edit their bug list instead of making it my exclusive domain, would they screw up or would they learn quickly and get more efficient at it than I would alone?
Any truly Agile process needs to adapt; being able to experiment (and having the freedom to screw up from time to time) is a basic need. I think it’s important to adapt your tools, processes and thinking to learning by mistakes and being able to revert at any time.