Quardev Monthly, April 2010
In this issue:
What Is Complexity?
By Jon Bach, Manager for Corporate Intellect, Quardev, Inc.
No kidding, here is Webster's definition:
"Something complex" or "The quality or state of being complex."
Thanks for the simplicity, Webster. We were looking for something more, well, complex.
Look up "complex" and you get "hard to separate, analyze or solve." This defines a lot of what software testing sometimes feels like to us here at Quardev, and after some research with our colleagues, we find we are not alone.
Sometimes complexity feels like trying to understand how to use this:
This is the cockpit of an MD-80 - the kind of commuter airliner you get into when flying from Little Rock to Las Vegas.
We talked to a pilot of such an airplane who, when asked how he deals with its complexity, told us this: "I don't see it as complex. I only need a few of those switches and gauges at a time to do any one thing."
The pilot has a way of breaking down all of that stimulus, ignoring what he doesn't need and focusing on what he needs. Procedures and checklists are another way he battles the complexity of aircraft systems that need to work together to get people from one place to another.
To understand complexity, let's juxtapose it with something simple like an input text field for a search engine:
Not a whole lot of pieces to understand there. However, the query language that can be used in the text field (as this page explains) might be considered by some non-computer users to be complex when all they want to do is type in a simple string like "green beans" to learn more about it. If the result set returned from "green beans" is too overwhelming or has too much noise (irrelevant hits), understanding the query language can help simplify or reduce the result set in such a way that the data comes back more relevant, making it seem "simplified."
For another example, let's take something simple like Notepad.
Just 5 menus, the most complicated of which is Edit and even then it is straightforward in terms of what functions it implies it can do to your text.
In understanding notions of complexity, we participated in a real-time online collaboration of testers whose mission was to test what to us seemed like a complicated product. From that experience and ensuing debrief, we've discovered the following categories:
Complexity means too many factors to handle at once.
One tester said: "I stopped reading the manual because there was too much to read (too complex). I felt I had to try the product to get context then re-read the manual. It was only at that stage that I could read the manual in detail to find issues with the wording, etc. I found the manual was non-technical, and I needed some technical content to understand how to enter data in the fields - e.g. the limits of the fields, or field types, or basic date rules."
Another tester said, "Get it to a base state and build from there."
This reminded us of the Stone Soup fable about the traveler who comes to a village in search of food. Hearing that they have none, he asks for a pot and a fire to boil some water. He takes a rock and tells them it will magically make food for all to eat. He puts the rock in and invites all to taste it. Boiling water? says one, I have a carrot, at least it will have some flavor. Hot carrot water? Says another, I have a sweet potato. And one by one villagers begin to make a soup - more complex in substance and in flavor than hot water.
Complexity means being overwhelmed - having too little time to process information.
The manual was too complex, but not the wording. It was written in a very basic way. It was just too much too soon. My brain was not prepared to read all that information. I had to try to learn it quickly in increments. That meant doing about three passes over the manual, as I was learning the data entry form."
Another tester said, "I find that learning in waves works best for me. I learn the structure of a problem/content first, then I learn the major components, and finally I fill in the gaps. I require my learning materials to be presented in a similar way."
That's why for some projects at the lab, we break our testing into time-boxed mission called sessions. Instead of written test procedures or cases, we spend time exploring toward each mission we define for ourselves as a few minutes modeling the product.
Complexity is the inability (or desire) to distill or simplify information.
"If we model at each level or state, then we improve our level of understanding, and the depth of confidence with complexity. It's just like a baseball game, and you move from base to base, eventually scoring a run."
"Modeling helps us find a safe place when looking at complex pieces."
Change your perspective. Maybe the earth looks too complex with its weather systems and continents, maybe looking at a grain of sand under a microscope reveals too much data. Change the granularity, or focus in a different way. Diagrams or visual models are another way to simplify something's complexity.
The most common way to distill complexity happens every day on software projects - get more eyes on the problem than just yours. Each person on the team takes a piece (a feature, for example) and makes it their own. Try breaking up the product into two groups: Primary Features (a feature so important that if it was broken, it would render the feature unfit for the product's purpose) and Contributing Features - anything else.
Complexity depends on the emotional relationship with the object of study.
Whether it be confidence, safety, or familiarity, said a tester, "You have to acknowledge the level of detail you are at, and move between your 'safe zone' and the complex zone. There is always a level you are confident with. If you freak out, then go back to your 'safe place' and start again.
In his book "Secrets of a Buccaneer Scholar" James Bach calls this "Plunge in and Quit" - a way of attacking complexity that involves starting to understand something, anything, but allows you the freedom to retreat when it gets too complex, then revisiting it later after some rest.
Another way is to pair up, so one person isn't doing all the thinking and analyzing. Have someone brief you, or make a bold boast and agree to train someone else on a feature you're confused about - that service mindset may inspire you to learn in a new way - to see it through new eyes.
Einstein is quoted as saying, "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." So don't be afraid to start with a simple idea. You know from your project experience that simple things will get complex on its own.