Blog post series
This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games. Solution Seeker is one of them.
Start programming only when you have at least three solutions.
I heard about this concept when I started being a programmer. It made some sense then, and now it has even more sense. Especially for problems when we care about: scalability, performance, speed, security, etc.
- You need to find a very good solution for a problem. But the “good” part here needs to be very well defined in advance. What do you seek for: security, speed, scalability, etc.
- The domain of the problem might be known or not to you. If it is known, you just want to expand you knowledge and find lateral solutions.
The two pairs sit down at the table and are not allowed to write any code until:
- they think about at least three possible ways of solving the problem
- they note on paper or in a text file the solutions
- every solution has a clear definition of how the goals (security, speed, etc.) are going to be measured in order to make sure the solution is right
- the solutions are prioritized: the simplest and with best estimated results will be the first one
- they start prototyping the first solution and measure its performance
- only if the first solution does not fit the criteria, the second solution is prototyped
- go on until one good solution is found.
This idea is extremely useful for finding solutions on hard problems or in areas like startups and research&development.
People who think there is only one solution, usually the first they think about, will be forced to expand their horizons. Also they will understand that seeking more for solutions would benefit their work quality.
Working in pairs for finding solutions might generate a lot of learning on how others seek for solutions. One could steal from another their mental ways of finding solutions. This would increase the team’s efficiency on the long run.
This is a structured way of finding solutions. It is extremely efficient when the pairs will focus on the problem and try to really brainstorm in the first stage.
In some cases this might not work. But then you might have a collaboration issue, and you should find solutions when doing your retrospective.
There is this idea in software development: I found the solution. I think, especially in programming, you can have too many solutions that are fit for the problem. So I thought about this game to structure the way one seeks for solutions.
Following this idea I wanted to structure a game to force developers, testers, system administrators, etc to find better solutions and not cling on the first idea that comes to their mind.
When will you try to seek out for innovative solutions?
Image credit: http://upload.wikimedia.org/wikipedia/commons/9/9a/Rubik%27s_Cube_variants.jpg