Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Archive for the ‘Experiment’ Category

Action Precedes Clarity

Thursday, June 19th, 2014

Remember the dot-com days of Webvan and Pets.com? We took traditional businesses and gave then an online presence. Rapidly acquiring a large customer base was the sole goal of many dot-coms. “If we can get enough users, we can easily figure out how to monetize it.” And all of this made perfect sense expressed in dollars and cents. I know people who melted down Yahoo Finance’s servers by checking for their favourite stocks prices throughout the day, calculating their (paper) net worth in real time. If you were not part of this madness, you were certainly considered stupid.

But then on March 10, 2000, the perspective changed. Suddenly it became clear that this was really a bubble. Without having real profits (or even revenue/cash-flow), it was really just a house of cards. In hindsight, the entire dot-com burst made perfect sense. But why wasn’t this obvious to everyone (including me) to start with?

In complex adaptive system, the causality is retrospectively coherent. .i.e. hindsight does not lead to foresight. When we look back at the events, we can (relatively) easily construct a theory to explain the rationale behind the occurrence of these events. In fact, when we look back, the reasons are so obvious that one can easily be fooled into believing that “Only if we spend more time, carefully analysing and thinking through the situation at hand, we can completely avoid unwanted events in future.” Yet, time and again, we’ve always been caught by surprise and it almost appears to be impossible to predict such events ahead of time. Call it the Black Swan effect or whatever name you fancy.

This effect gives rise to a classic management dilemma – Predictability Paradox(pdf). In the zeal to improve the effectiveness and reliability of software development, managers institutionalise practices that unfortunately decrease, rather than increase, the predictability of the product’s success. Most companies spend an awful lot of effort and money to analyse the past, derive patterns and best practices, set targets and create processes to prevent past failure and produce ideal future goals. If software development was highly structured, if we had a stable environment and we had a good data points from million other projects, this approach might work. But for software development, which is a creative-problem solving domain, with high levels of uncertainty and each project having an unique context, these techniques (best practices) are rather dangerous.

In our domain,

  • We need to break the vague problem down into small safe-fail experiments.
  • Then execute each experiment in short iterative and incremental cycles.
  • We need to focus on tight feedback loops, which will help us adapt & co-evolve the system. (We cannot be stuck with analysis paralysis.)
  • We need to probe the system with experiments and find emergent practices.
  • And then apply these practices in a given context, for a short duration.
  • Speed and Sustainability are extremely important factors.

This is what I mean when I say “Action Precedes Clarity”.

MVP to Test the effectiveness of using Simulations or Inline Instructions to Teach Kids

Saturday, October 12th, 2013

At EdventureLabs, we were trying to teach kids age (5-7,) to represent numbers on the Abacus. First we created a small animation video with a little story line. We took help of a professional animation expert. However, we quickly realized that kids have very little attention span and if they are not able to interact with what they are seeing on the screen, they quickly (in less then 30 secs) zone-out. Also animation was expensive and had a huge turn-around time even if we wanted to make a small change. Clearly a bad strategy.

Inspired by lot of mobile games, we came up with a hypothesis that if we created inline instructions and used micro-simulations, then the kids would have a better retention power and hence be able to learn much better. We wanted to quickly test this hypothesis.

However we had not yet built an app, so building an app and creating a simulation would take us a few days. But we wanted to quickly test the simulation hypothesis to see its effectiveness. So we took a short-cut.

We quickly (in less than 10 mins) found a bunch of images on the net, created a presentation and added a bunch of transition to create an animation effect. Then we exported this presentation out as a movie.

Now the kids were able to watch this 10 second movie, like they would see a simulation/inline instruction in our app. Once the simulation showed how to represent a number, we would ask the kid to move the right beads on the abacus. Of course the beads would not move, but we would be able to test whether the kids tried to move the right beads and hence assert if they remembered how to represent number. If they could, we would ask them to represent other numbers which were not shown in the simulation to see if they can extrapolate what they just learned and apply the logic for other numbers. Most kids could do simple numbers, but were not able to do all the numbers. Another good learning from this experiment.

Anyway, here is the very first video we created to test our simulation hypothesis.

What’s Inside MacBook’s Battery?

Monday, September 30th, 2013

Today, my six year old and I did a little experiment to figure-out what is actually inside a laptop’s battery.

1028927

We took a dead battery from one of my Mac Book Pro and cracked it open.

IMG_1772

IMG_1773

IMG_1774

IMG_1775

IMG_1777

    Licensed under
Creative Commons License