Fail Fast

In software development, there is a programming philosophy called “fail fast”. The idea is that you start by generating an immediate and visible failure, and then you add just enough code to fix that failure. This is a paradigm shift, since normally in software development you write code first, then test to see if it works. Both approaches work, but failing fast has the advantage of helping you be more proactive in developing reliable software, but it also has a side effect: confidence.

Here is an example, from a fail fast software development approach called Test-Driven Development. You want to write some code for a mobile gaming app, and you have your IDE (Interactive Development Environment) ready to go. You’ve sketched out some screen designs, and you want to work on initial game play by placing an object on the screen that can be interacted with. Instead of writing the code that starts drawing things on the screen, you write a test for that code. Then you run the test, and of course it fails, so now you start to write the program code to get that test to pass. It might take several quick attempts of writing program code for that test to pass. Next, you add some variation and elaborate on that simple test by adding more.

Once you are satisfied with your combination of program code and tests, you proceed with your program development. Again, write a new test first with no corresponding program code, run the test, watch it fail, then add code until it passes. After a while, you have a suite of tests that you can run when you change your code, to verify that you haven’t broken existing functionality. That suite of tests provides confidence that allow you to make simple changes, but it also makes you think more about writing code that is more reliable as you are writing it. In short, the computer provides you a level of safety before you commit a program to a build and deliver it for people to look at. It feels really weird at first, but your brain makes the paradigm shift after a while.

FAFO

FAFO, or fucking around and finding out, is a popular term in online culture, but it also applies to learning. In fact, much of learning is about fucking around and finding out. Kids constantly do this. They try something, they observe the effects, and they learn and move on. Adults do this too, and not just when they engage in crappy online discourse. The scientific method, or hypotethico-deductive model is a formal, powerful, peer reviewed version of FAFO. FAFO, when it is safe, is a fantastic learning tool, and it comes completely naturally. As kiddos, we touch things, we taste things, we poke them with a stick, and we squeal and run away when things go awry. Trying, observing and adapting is crucial to learning. When you start adding knowledge and facts, FAFO gets squeezed out.

In childhood learning, we put a lot of pressure on kids to get things right. Instead of putting a worksheet in front of them, encouraging them to write out answers, then grading them on an answer key, how do we get them to fail fast and build their confidence? For me and my kiddo, using play and technology helps us fail fast, so we build confidence and explore in our learning, before committing to a correct answer. FAFO is a great learning tool, but it’s high risk when you use worksheets. You have to commit rather than explore and find out. That ability to explore wrong, right and indescribable answers before committing them to get graded is key.

…using play and technology helps us fail fast, so we build confidence and explore in our learning, before committing to a correct answer.FAFO is a great learning tool, but it’s high risk when you use worksheets. You have to commit rather than explore and find out.

Feeling Safe is Crucial

Failing fast in software development is possible when you have a safety net. FAFO is fun and a great learning approach when it is safe to do so. It turns out that other things like productivity, quality problem solving and providing feedback also require safety to be effective.

In the corporate world, there is a lot of talk and training about creating psychological safety in the workplace. In essence this means you create a culture and environment where people aren’t afraid to ask questions, make mistakes, or speak up when something is wrong. A psychologically safe workplace isn’t about enforced or toxic positivity, in fact, it is a place where problems can be confronted without punishment. Criticisms about product can be raised without also feeling forced to offer solutions. Outrageous ideas are welcomed and brainstormed together. Tough feedback, especially to leaders is welcomed. The people who need to hear the hard truths welcome hearing those hard things because it makes the product and the workplace better. The article What Is Psychological Safety at Work? How Leaders Can Build Psychologically Safe Workplaces articulates this well:

“Psychological safety at work doesn’t mean that everybody is nice to each other all the time. It means that people feel free to ‘brainstorm out loud,’ voice half-finished thoughts, openly challenge the status quo, share feedback, and work through disagreements together — knowing that leaders value honesty, candor, and truth-telling, and that team members will have one another’s backs.”

In my consulting work, I found that high performing teams had a high degree of psychological safety. They could try and fail without judgment, they could provide brutal, but important feedback without fear of reprisal, and they handled conflict well. I also noticed this in training sessions, especially with corporate clients. When I would set up in an office and participants in the company would start to trickle in, I could sense the fear almost right away. They were also afraid to take part in any of the group learning activities, because they were afraid of failing, and then being judged or punished for it.

In many companies, if management was around in the training room, people were extremely tentative. They didn’t want to answer questions or participate in the vital learning activities. If management left the room, they started to participate. I put a lot of work into my courses to make people feel safe to do whatever they needed to do to learn, as long as it was respectful of those around them. I didn’t always get it right, but I worked at it. Two instances stand out in particular.

In one instance, I had a room of about 60 employees with their managers sitting at the back. The development manager left early on along with several other senior managers. The QA manager though wanted to stay to learn for himself. At the first break of the morning he came up to me and said he felt his presence was interfering with participation levels, so he was going to leave. Sure enough, once the bosses were gone, people started to speak up, and they brought up problems they were having with their software development and asked how to apply coursework to their current situation. We had an extremely productive two days. My third day on-site was partially spent going through a highlight reel of the course with the manager. This was early in my training career and was extremely eye opening.

In another instance, I had a smaller team of about 15 people in a training session. When the development manager would come into the room, everyone went silent and would look at the floor. When they left, everyone would look over their shoulders to see if she was gone, and then they would participate again. She walked in again during a complicated systems problem solving activity and no one noticed. Instead of working as a group, they had asked to work on it individually to make it more challenging, and then they would compare their work as a group. This is a fantastic learning opportunity because you get a lot of perspectives. The right or correct answer with many systems thinking exercises is to generate different, yet valid perspectives. One of the shyest participants spoke up first, and mentioned that one of the prompt categories had been hard for her. It turned out she had misinterpreted the prompt, and wasn’t able to think of anything relevant. Usually when this happens, it leads to rich discussions about mental models, shared language and how different people or groups can interpret things differently. In fact, they may have completely different definitions for words that you use in a different context. The participant wasn’t “wrong”, and in fact, she had inadvertently brought us to our next discussion point, all through doing the work and feeling safe about it. Unfortunately, this didn’t happen. The manager who was standing at the back of the room suddenly spoke up, joking around and mocking the person for getting it wrong. She was instantly deflated and upset, and the tension ratcheted up with the entire group. The afternoon learning was completely ruined, no matter what I did to try to get them back on track.

When kiddos learn, we can put enormous levels of pressure on them, even by accident. When you are a parent homeschooling, this pressure increases. You want them to get the “right” answer, they want to please you, and you can give away a lot with your body language, your tone of voice, your approach, etc. Imagine this scenario. You work through some simple addition facts with small numbers. You carefully review the addition and equals symbols. You help them translate an equation into spoken language, “one plus one equals two”. You help them visualize it with some of their toys. You then have them review it with a fun online video. You then take out a math facts worksheet with 10 questions that have simple equations for them to solve. You read the directions on the worksheet, ask if they understand, and then you work through the first question together. You review, and they seem to get it. They know what is expected, they have the required background information, and they understand the concepts and have the skills to work through the problem. You turn them loose, and what happens? Are they feeling energetic and having fun with a challenge to show what they know? Or, are they freezing up and serious? As a parent learning coach, I’ve had both experiences. At first, we had a lot more of the freezing up and pressure than challenge and fun.

To help make this activity feel safer, I did away with the worksheet. I would take toys or math manipulatives, a plus sign and an equal sign and put them into an equation. I would take 2 Hotwheels cars, set them down on the table, then next add a plus sign. Then I would add 1 Hotwheel car. I had two Hotwheels representing the first addend, and then one car representing the next addend. I would add the printed out equals sign, and leave the sum empty. I asked kiddo to get Hotwheels to fill in the sum. After a bit of trepidation, he grabbed three Hotwheels to represent the sum. Next, I asked him to use his mini whiteboard to write out the equation in numbers. “2 + 1 = 3”. It took a few attempts, but in a day or two we had finished off the worksheet material, but in a way that allowed him to experiment before committing an answer. he could manipulate the Hotwheels or other manipulatives until they felt right, then write it on the whiteboard. Also, the whiteboard was easier to fix mistakes than writing down in pencil and then erasing. Also, I worked with him on how to check his work, so he could feel more confident before asking me to check his answers.

Experimenting with toys and math manipulatives are all well and good, but technology makes experimentation, failing fast and FAFO even more psychologically safe. I have long used virtual simulators, emulators and high volume test automation to experiment and learn about software systems. They are extremely powerful technology tools that allow you to explore and find out what happens to systems when they start to fail. You can then design and enhance your system to be much more robust, reliable and performant under real world use.

One of the first things I worked on to reduce risk in math work was to use technology to help, and make the activity virtual. I opened a slide deck, added in a plus and equal sign, and a bunch of small images at the top. I then asked him to create equations. I made text boxes where he could type in each addend and the sum, and he could add them up above the equation to experiment or check his work. He had a lot of fun with it, and would often ask to be alone to play around. Once he had written down some math facts, he would proudly show me his work on each slide he had created. When he made a mistake, I was very careful to ask him to review his work with me, and we would try to find a learning lesson if there was something to work on, or I would brush it off as a typo. After all, we all make typos!

Next, I used high volume automation using the programming language Ruby. Together, we wrote a function to add two numbers together. He came up with variable and function names, and the function would add the numbers and return the sum. Next, I added in a function that would loop from 0 to a number of his choosing and demonstrate the sum. Each addend would increase by 1, and with a bit of a delay added, he could watch the sums increase as the addends increased. We then repeated this with a subtraction example that would iterate down from a large number to 0.

Experimenting with toys and math manipulatives are all well and good, but technology makes experimentation, failing fast and FAFO even more psychologically safe. I have long used virtual simulators, emulators and high volume test automation to experiment and learn about software systems. They are extremely powerful technology tools that allow you to explore and find out what happens to systems when they start to fail. You can then design and enhance your system to be much more robust, reliable and performant under real world use.

If it works for adults who are solving incredible problems, then it is surely going to work for kiddos who need a safety net to fail fast, to FAFO and feel safe in making lots of mistakes and learning from them.

I found that our virtual work provided a lot of opportunity to fail fast, adjust quickly, and reduce the perceived risk of school work. Beyond that, we could use the tech to FAFO. What happens if you add in a character instead of a number? Well you get a type error. Ok, so what does that mean? We have to be explicit with the computer when programming and give it what it expects. But can a letter be a number? Well, sure.Then we talked about algebra and ended up working on one step algebra. We moved seamlessly from having trouble with simple arithmetic to basic algebra, all because kiddo felt safe to experiment and once his brain wasn’t processing anxiety and fear, we could move in whatever direction his curiousity took him. Technology is a wonderful place to safely play with exploration, but sadly, we seem to mostly try to replicate classroom experiments with virtual worksheets rather than tap into its power to enable and provide safety for judgment free failures and productive FAFO.