Monday, March 27, 2006
Stories
It's not rocket science really... It's just about telling someone how your product works. And what better way to do it than with a story?
It's a simple game really of making something (a unit of functionality) sound simple so that the requirement sounds really simple to understand. When it's been understood correctly, it now involves action and careful planning to actually fulfill the requirement.
But what if you're talking to people who do rocket science for a living? What if they already go about it like it's astrophysics or string theory? How do you tell someone who's been doing it for a certain way already to simplify things?
It's actually hard (though it may sound really simple) to get someone to simplify a solution when they're so used to thinking complex terms. It's not really just about simplifying a solution -- simplifying the thinking process and solution formulation process is like trying to unlearn a lot of habits.
I just found out how really complex experienced programmers who have been so used to 'architecture' and 'hack-up' and even 'design-centric' approaches can think. And with the focus on flexibility, speed, and adaptability, the agile methodologies (like XP and TDD) might have to require the rocket scientist to go back to the good old simple arithmetic days. And in this regard, you might (and would most probably) encounter resistance.
Listen to a child when you ask one "how do you think a rocket will get to the moon?" You might get answers like "of course, it will fly!" or "someone in the rocket will push a button and it blasts off into orbit" or even "I dunno, maybe my dad knows...". Okay, the last response is the worst kind of response because it shows a lack of curiosity and a dependency to some "higher power" or "authority" hampering the creative process.
The first response is that of simplicity -- there's an assumption on the functional requirement to reach an end, no matter how that happens. This kind shows the abstract and simplistic reasoning behind problem solving, which sadly gets lost when we start amassing knowledge. People who respond this way are usually people who simplify things as a matter of functional units -- and that's what you want when solving problems. Notice that the response lacked detail, but contained enough information to count as an explanation?
The second response is what you usually get from people who already have a preconceived notion on the solution -- usually these responses come from people who have seen something about the topic, or have read about the topic, or maybe even know a lot about the topic and try to simplify. Usually, children who respond this way already have some idea how a rocket works -- and thus will be more or less boxed in when a new rocket design deviates from his already preconceived notion.
In the next few days, I will be outlining some of the general methods I employ to get people (especially software developers) to simplify the solution to a problem. However, I borrow a lot from the experiences and writings of other authors and colleagues in the field. Some may be new, and others might be prviously proposed/done.
Remember someone telling you a story that dragged on and on that you lose the point?
The simple solution is usually the most elegant solution. Elegance comes at a cost, and usually this elegance leads to considerable value.
It's a simple game really of making something (a unit of functionality) sound simple so that the requirement sounds really simple to understand. When it's been understood correctly, it now involves action and careful planning to actually fulfill the requirement.
But what if you're talking to people who do rocket science for a living? What if they already go about it like it's astrophysics or string theory? How do you tell someone who's been doing it for a certain way already to simplify things?
It's actually hard (though it may sound really simple) to get someone to simplify a solution when they're so used to thinking complex terms. It's not really just about simplifying a solution -- simplifying the thinking process and solution formulation process is like trying to unlearn a lot of habits.
I just found out how really complex experienced programmers who have been so used to 'architecture' and 'hack-up' and even 'design-centric' approaches can think. And with the focus on flexibility, speed, and adaptability, the agile methodologies (like XP and TDD) might have to require the rocket scientist to go back to the good old simple arithmetic days. And in this regard, you might (and would most probably) encounter resistance.
Listen to a child when you ask one "how do you think a rocket will get to the moon?" You might get answers like "of course, it will fly!" or "someone in the rocket will push a button and it blasts off into orbit" or even "I dunno, maybe my dad knows...". Okay, the last response is the worst kind of response because it shows a lack of curiosity and a dependency to some "higher power" or "authority" hampering the creative process.
The first response is that of simplicity -- there's an assumption on the functional requirement to reach an end, no matter how that happens. This kind shows the abstract and simplistic reasoning behind problem solving, which sadly gets lost when we start amassing knowledge. People who respond this way are usually people who simplify things as a matter of functional units -- and that's what you want when solving problems. Notice that the response lacked detail, but contained enough information to count as an explanation?
The second response is what you usually get from people who already have a preconceived notion on the solution -- usually these responses come from people who have seen something about the topic, or have read about the topic, or maybe even know a lot about the topic and try to simplify. Usually, children who respond this way already have some idea how a rocket works -- and thus will be more or less boxed in when a new rocket design deviates from his already preconceived notion.
In the next few days, I will be outlining some of the general methods I employ to get people (especially software developers) to simplify the solution to a problem. However, I borrow a lot from the experiences and writings of other authors and colleagues in the field. Some may be new, and others might be prviously proposed/done.
Remember someone telling you a story that dragged on and on that you lose the point?
The simple solution is usually the most elegant solution. Elegance comes at a cost, and usually this elegance leads to considerable value.
