Blog

Post 2 – Describe your dream bicycle…

By Nic on June 17, 2020 0 Comments

The human brain is a marvelous creator, with infinite design capacity. In most cases the only limitations imposed on our creativity are also just imaginary limitations and while they may be powerful perceptions, they are ultimately influenced by our experiences, which develop into assumptions and beliefs. This piece is not aimed at discussing the power of the human brain and all the wondrous potential we each have.  This post is merely about acknowledging how our brains use the imagination as a tool to envision most things.  In particular this post aims at pointing out exactly how we tend to imagine and describe designs, systems and scenarios. It is widely agreed that people use their imagination to picture a visual representation of things as opposed to picturing the words used to describe them. The tiny minority of people who are unable to do this are said to suffer from congenital aphantasia. Try it out yourself. Picture a red bicycle. You may be able to picture both the text for “red bicycle” as well as the image of a red bicycle. You can probably even picture it being ridden by someone or leaning up against a white picket fence.  If not, then perhaps you have congenital aphantasia in which case the rest of this piece might be a little difficult for you.

Back to the point, imagine the following: You are 10 years old, and your parents say they will buy you a bicycle for your birthday.  The condition is you need to describe the exact bike you want so they get it right. Before we continue, try this little example. Put yourself in your 10 year old self’s shoes now. Take 5 minutes and go ahead with pen and paper and provide your parents with the description of the bike you’d like…

For some reason, adults generally have been conditioned to react to this scenario by describing the bike in the format of a list. Perhaps you’ve listed items such as the colour, the size, the bell and basket, maybe even some rocket boosters, the type, mountain bike, BMX or road and maybe even how many gears you want. Items left off your list might include the chassis, the brakes, the wheels and tyres and the seat. These are assumed to be part of all bikes and so probably were not listed. It’s fair to say that if you give your parents the list, they will probably get you something inline with what you had in mind but there is certainly potential for some deviation from your idea. 

The child version of yourself will more likely have described the desired bike with a drawing and probably just a crayon drawing at that, however, your parents would have known exactly what you had in mind. Further to that, it is very unlikely that key components such as a chassis will be left out of the drawing as they were in the list. Imagine the disappointment you’d have felt if your parents presented you with a bell, a basket and the rest of the listed features but no complete bike on your 11th birthday! This is just a silly and simple example to make the point. But apply the two description methods (listing vs drawing) to something slightly more variable and ambiguous than a bicycle for example a house. The exact same list of features describing a house could be interpreted by two different imaginations drastically differently, and so it’s no surprise that houses are built with super detailed blueprints in order to avoid any potential for misinterpretation.

If you had drawn the bike without a chassis, or without wheels, this would have been very obvious to your parents and they would have without doubt asked you where the chassis or wheels were, and why you didn’t want them. When reviewing the list features provided it’s unlikely that they would have raised any concerns or questions and relied on the assumption that you must obviously want these as well. I think it’s universally accepted that in software design we always want to avoid relying on assumptions.

When it comes to delivering software the complexity tends to even exceed that of building a house or skyscraper from spec due to the intangible, virtual nature of software and the fact that software systems are used to solve so many different types of problems. In contrast building a house typically provides only a few simple, standard solutions such as providing shelter, comfort, convenience, and maybe entertainment. A simple example to portray this is if you are asked once again to pick up the pen and draw a house, it will likely look similar to everyone else’s drawing and would be easily recognisable as a house, while if you are asked to draw a software system each person’s drawing will vary far more, and it will be unfamiliar to people guessing what the drawing is.

The point here is that our imaginations are extremely useful in designing anything but if we wish to describe these designs to one another it is risky to do this without drawing what you are picturing because a list simply won’t cut it.

Please give the 2 min video a watch and if you use Jira, give Floodlight a whirl and tell us what you think. Thanks

Leave a comment

Your email address will not be published. Required fields are marked *