April 2, 2007
If you accept the premise that software development is a cooperative game, then you might wonder: what kind of game is it?
Alistair Cockburn believes the closest analog to a software project is the cooperative game of rock climbing:
- Technical. The novice can only approach simple climbs. With practice, the climber can attack more and more difficult climbs. The more technically proficient rock climber can do things that the others cannot. Similarly, software development is technical and requires technical proficiency, and there is a frank difference in what a more skilled person can do compared with a less skilled person.
- Individual and Team. Some people naturally climb better than others. Some people will never handle certain climbs. At each moment of the climb, each person is drawing on their own capabilities. They have to hold their own weight. And yet climbing is usually done in teams. There are solo climbers, but they are in the minority. Under normal circumstances, climbers form a team and the team has to work together to complete the climb. Similarly, software developers, while working on their individual assignments, must function as a team to get the software out.
- Tools. Tools are a requirement for serious rock-climbing: chalk, chucks, harness, rope, carabiner, and so on. It is important to be able to reach for the right tool for the right moment. It is possible to climb very small distances with no tools. The longer the climb, the more critical the tool selection is. Software developers will recognize this. When you need a performance profiler, you really need it. You can't function without the compiler. The team gets stuck without the version control system. And so on.
- Planning and Improvising. Whether bouldering, doing a single-rope climb, or a multi-day climb, the climbers always make a plan. The longer the climb, the more extensive the plan must be, even though the team knows that the plan will be insufficient, and wrong in places. Unforeseen, unforeseeable and purely chance obstacles are certain to show up on even the most meticulously planned climbing expeditions, unless the climb is short and the climbers have completed it several times before. Therefore, the climbers must be prepared to change their plans, to improvise, at a moment's notice. This dichotomy is part of what makes software development manages gnash their teeth. They want a plan, but have to deal with unforeseen difficulties. It is one of the reasons why incremental development is so critical to project success. It is why climbers climb in stages, and set various base camps.
- Fun. Climbers climb because it is fun. Climbers experience a sense of flow while climbing, and this total occupation is part of what makes it fun. Similarly, programmers typically enjoy their work, and part of that enjoyment is getting into the flow of designing or programming.
- Challenging. Climbers climb because there is a challenge. Can they really make it to the top? Most programmers crave this challenge, too. If programmers do not find their assignment challenging, they may quit, or start embellishing the system with design elements they find challenging.
- Resource-limited. Rock climbing works against a time and energy budget. The climb needs to be completed before the team is too tired, before the food runs out, by nightfall or before the snows come.
- Dangerous. If you fall wrong on a rock climb, you can be killed or maimed. This is probably the one aspect of rock climbing that does not transfer to software development. Rock climbers are fond of saying that climbing, done properly, is less dangerous than driving a car. However, I have never heard programmers compare the danger of programming with the danger of driving a car or even crossing the street.
I'll admit I had never quite thought of software development in this way, but Alistair's rock climbing metaphor holds. It's certainly a far better metaphor than the tired old bridge building chestnut. I see further analogs in the way the natural environment itself-- and the difficult to predict, uncontrollable weather conditions-- can make or break a project.
The one unsatisfying aspect of the rock climbing metaphor is that software tends to build upon itself in a way that rock climbing doesn't. Each subsequent version of the software expands on the capabilities and the platform established in the previous version. So there are really two goals:
- to reach the summit.
- to make it easier for subsequent teams to reach the summit.
But these goals can be mutually exclusive. In a followup article, Alistair illustrates with an example he calls "The Swamp Game".
Consider a race across an uncharted swampland in which some particular (unknown) artifact must be produced at some particular (unknown) place in the swamp. A team in this race would employ scouts and specialists of various sorts, and would create maps, route markings, bridges and so on. The racers would not, however, construct commercial quality maps, roads or bridges, since doing so would waste precious resources. Instead, they would estimate how much or little of a path must be cleared for themselves, how strong to build the bridge, how fancy of markings to make, how simple a map, in order to reach their goal in the shortest time.
If the race is run as part of a series, there will be new teammates coming after them to pick up the artifact and move it to a new place. The first team will therefore be well served to make slightly better paths, maps and bridges, always keeping in mind that doing this work competes with completing the current stage of the race. They also will be well served if they leave some people who understand the territory to be part of the next team. Thus, the optimal strategies for a series of races are different than for a single race.
There is no closed-form formula for winning the game. There are only strategies that are more useful in particular situations. That realization alone may be the strongest return for using the economic-cooperative game language: people on live projects see that they must constantly observe the characteristics of the changing situation, to collect known strategies, to invent new strategies on the fly; and that since a perfect outcome is not possible in an overconstrained situation, they much choose which outcome to prioritize at the expense of which others.
I find Alistair's game theories fascinating and illuminating. Based on the strength of these two essays, I just picked up a copy of Alistair's book, Crystal Clear: A Human-Powered Methodology for Small Teams. It's based on the same cooperative game manifesto I've covered in my last two entries.
I've already run into one team using the Crystal method (no, not that crystal method) at a customer site. I'll have to check in with them next week and see how close they are to the summit.
And the next time someone asks you why software projects are so challenging, invite them to go rock climbing with you.
Posted by Jeff Atwood
The big thing missing from your metaphor is everybody other than the programmers. If rock climbing were like programming, you would have management to change the course and destination periodically through the climb and marketers announcing to the world you will soon reach the top of Everest.
Also, as someone who has been both a developer and a sysadmin responsible for managing deployed code, this comparison reinforces the all-too common developer mindset that coding a given app is something you do once for a thrill, then leave behind to find the next challenge.
Sorry Jeff, I see the metaphor was Alistair's, not yours!
As a climber the metaphor is both good and bad.
On the one hand when you climb to the summit of a mountain you will probably never climb that mountain again.
On the other hand when you climb to the summit of a software project you may or may not climb that mountain again...
You can say all you want about the similarities between the two however there is one more striking difference between them.
You can die on a mountain. The stakes are for real and very high...
Waterfall, RUP, XP, Agile and now Crystal. You know, Jeff, you have done quite an 180 degree turn away from what you said previously:
"the value of big-Em methodology decreases very sharply as you
climb the skill ladder"
What caused the turn?
When you climb a wall for the first time, you need to document, grade and depending the place also to bolt the protection on the wall, making it easier for other people to do what you have done. As more people climb it, more protection would be added, it will be better cleaned of loose rocks, new variants can be made, the documentation updated, the grade refined, etc.
So usually it builds on top of what its being build.
That's the great thing about the human mind. You can compare anything to anything else and your mind will find similarities. For example, I will compare software development to an orange.
1. At first, sometimes development of a piece of software looks simple, just like an orange will at first look like an orange-colored sphere. However, upon further inspection, we notice complexities. In the case of the orange, we notice the dimples on the surface and the stem. In the case of software, we notice the restrictions on input and output and target execution environment.
2. When software works correctly, it appears simple. However, there is always a lot going on underneath the surface, hidden from the user. Similarly, an orange has a skin on the outside. All the meat of the orange is hidden underneath this skin.
3. Software development can be modular, splitting development between different teams. However, there is always a single construct that needs to bind all the pieces together for the system to function correctly. Similarly, in an orange, the slices of the internal meat seem disconnected and independent, but they are actually bound together by a thread running through the center of the orange.
That's all I can come up with now. I think I've made my point, you can compare anything complex to anything else complex and your brain will fill in the details.
So this is from memory and no coffee, just woke up.
I like Alistar's work because he is not one of us. He has approached this as an anthropologist. He is not trying to invent a new way. He has tried to take what he has observed to work well.
So if this a reason that you too like his work you would probably like:
Organizational Patterns of Agile Software Development
by James O. Coplien, Neil B. Harrison
They too took the approach of an anthropologist. This book is very dense. Don't let its size fool you, 419 pages. There is so much information in this book.
It used to be available on the web on their wiki (the book is a print of the wiki). Now I cat only find dead links. Like I said I just woke up so you go and find the wiki yourself.
There are probably more metaphores for software development than for any other discipline.
Software development is like a game. No, it's like a race. Or maybe it's like building a building? Or maybe like building a bridge? Rock climbing? check. A battlefield? done this last week.
Metaphores can be very useful, but as we go down the list they seem to be less and less useful. The most useful one I know is the building metaphore, that is probably the most cited (for example, in Code Perfect, which also warns against useless metaphores).
Did you notice that these metaphores always tend to be "manly" ones? As if software developers suffer for some sort of infiriority complex, and are compensating by comparing them to military endeavors and exciting sports.
No one ever compares software development to synchronized swimming, or group ballet dance for some reason. I wonder why?
It also seems as likely as not that the person comparing development to X knows very little about X, and certainly is no expert about X.
This recent rock climbing metaphore is tenuous at best. I can make the same arguments for basically any professional endeavor. Let's go with ballet dancing (which I know nothing about, but at least I tell you that):
# Technical. The novice can only approach simple dances. With practice, the dancer can attack more and more difficult movements...
# Tools. Tools are a requirement for serious ballet dancing: shoes, appropriate stage, clothing, practice equipment, and so on...
# Planning and Improvising. Of course, each group performing Swan Lake approaches it with serious instructions, and yet every member contributes their own unique interpretation of things.
# Fun. Dancers dance because it is fun...
# Challenging. Dancers dance because there is a challenge. Can they really make it to the top (pun intended)?
# Resource-limited. Ballet dancing works against a time and energy budget. The performance must be ready and rehearsed it's time to perform, before the money runs out.
I'll stop here, though I could conjure up more similarities.
My point is that many things are a lot like other things. Let's stop making useless metaphores, and concentrate on those that seem unique, and actually contribute something to our understanding of ballet dancing. I mean, software development.
this is a rather boring (sorry jeff) topic.
software projects are like many other things in the world, like many other things in the world.
we know what software projects are about. so the only value i extracted from the text is, that rock climbing could be a hobby for software developers. o_O
to eat a bratwurst is very much like to eat a hamburger btw.
I used to work as an industrial automation programmer, using the same kind of tools and applications used in places like nuclear plants. Some jobs could be very stressful, as if you messed up your program a robot could potentially go haywire. Some jobs we turned down for the simple reason that if we made a mistake, someone could be seriously injured or killed.
So yes, programming can be very dangerous :)
(The vast majority of the work was a huge amount of fun though - it's immensley satisfying to execute your program and see a car plant assembly line or a wine bottling line start up :) )
Quote: "Thus, the optimal strategies for a series of races are different than for a single race."
This reminds me of Dawkin's ESS (http://en.wikipedia.org/wiki/Evolutionarily_stable_strategy) and an interesting observation. If you know the number of races in advance then your best strategy would be to not cooperate in the last race as you have nothing to fear from retaliation in the next race. Considering this fact - you can be reasonably sure everyone else will do the same so your best strategy would be to not cooperate in the next to last race, etc...
So knowing the number of races naturally changes the nature of the game considerably.
I think a better analogy would be that of a painter.
Some believe that painting requires real talent, yet even the talented study, learn and practice the art.
Others do not want to employ great artists, so they come up with a plan and reduce the project to painting by numbers.
You asked who's using Crystal. I use a "Crystal-like" process. I.e. based on Crystal with ideas borrowed from a few other agile processes too.
But, that's not the real answer to your question. The real answer is that people were using Crystal long before it was written down. That's because, as noted above, it was developed with an "anthropololgists" mindset. Alistair studied lots of teams, then distilled the common ingredients of their success into Crystal. His work is documented in his PhD Dissertation, which is available on his site.
Many experienced developers will read the book and think, "Hey, that's what I'm doing already." They may find it reassuring to know that so many other teams are succeeding in similar ways. They may also find useful ideas to add to their "bag of tricks".
For those who may be interested, I've posted links to a couple of sample chapters from the book here: http://www.agilekiwi.com/crystal_clear.htm
If you liked the Crystal Clear book, you'll probably also like the new second edition release of his "Agile Software Development" book. It includes almost a book's-worth of brand new material.
Did you notice that these metaphores always tend to be "manly" ones?
As if software developers suffer for some sort of infiriority complex,
and are compensating by comparing them to military endeavors and
If this blog had a moderation / rating system, that would be "+1 Embarrassingly True".
I personally think software is akin to War. There's a lot of screaming and confusion, you seem to tackle the same problems again and again, and at the end of the day you've accomplished something... but you're usually not exactly sure what.
Geez, if you like Alistair so much, you should have been in my Software Engineering class. The class wasn't taught by Alistair but was designed by him and he gave several guest lectures. I wasn't aware we were being taught by such a celebrity.
Personally, I find his insights to be mostly useless in the real world. Sure, it's good to try to do some of the things that he lays out but in my experience, it just doesn't fit too well when you're actually in the trenches.
I'd also make the point that climbers don't tend to have waistlines like programmers
I have used the climbing metaphor before, particuarly with regard to configuration management (version control):
as you go up you make frequent check-ins (or thread your rope through anchor points), so that if you fall it isn't very far...
Most "theory" doesn't fit well in the real world. But it's the ability to take something theoretical and apply it to the real world that marks your ability to leap logical gaps. It can't all be laid out for you. If it were, well, we'd never breed another generation of thinkers, would we?
This recent rock climbing metaphore is tenuous at best. I can make the same arguments for basically any professional endeavor.
Are you saying software projects are like a peanut butter sandwich?
Personally, I find his insights to be mostly useless in the real world.
The value of the metaphor is only useful insofar as it results in actionable things you can do in the real world, on your own project, that result in practical benefit. That's why I linked to his book on the Crystal Clear method. I'm curious, has anyone reading this tried it?
You know, Jeff, you have done quite an 180 degree turn away from what you said previously: http://www.codinghorror.com/blog/archives/000203.html
I think you should be familiar with common methodologies, but that doesn't mean you have to be a slave to them.
You know, Jeff, you have done quite an 180 degree turn away from
what you said previously:
I think you should be familiar with common methodologies, but that
doesn't mean you have to be a slave to them.
Right then, what is the Crystal Clear Method? So far we've heard about war, rock climbing, games and swamp races. But nothing at all about what this wonderful method really is.
Or do I have to buy the book to find out just what I'm getting? Come on, if you're going to bag a referral bonus from Amazon, the least you can do is to be an honest salesman and show us the real product we're supposed to buy. Or is the whole book a series of analogies with extreme sports?
Huh: only wimp-ass programmers sink bolt into natural rock: real programmers perserve their jobs with no comments, odd techniques, and as much assembly as possible!
What exactly is a 'chuck' when applied to rock climbing? ;-)
I happen to be a programmer, and am also a rock climber. I would say there is no comparison between the two, at least in my case. I climb for recreation, I might get to the top of something, but I just come back down.
When I am coding, I will create a feature, but I won't delete it (unless it really really sucks!) I create the feature so that other's can do that feature. I do not climb so that other people can benefit from it.
Refering to tools...I find several similarities between climbing and coding. Both of them have tools, and the tools can be used in more than one way. I beleive that there is no 'wrong' way to use any tools, but there are usually several 'better' ways to use a tool.
Anybody can climb to some point, as can anyone code. It does not just require having the knowledge, it depends on being able to implement your knowledge in the correct way to acheive your goal. Rock climbing requires enough strength to implement your teqnique, and coding requires enough knowledge to implement.
I would say they are probably about as similar as two different things can be, but that could be said about almost anything, as was mentioned above regarding ballet.
public class ClimbingOutOfCubicle
public static void main[String args]
if((waistline MaximumWaistline) !(carpeltunneltest))
public static void ClimbOverWall()
while(you.location != top)
Let's stop making useless metaphores, and concentrate on those that
seem unique, and actually contribute something to our understanding of
ballet dancing. I mean, software development.
Well, it's always dangerous to take a metaphor too far. But, they *can* be useful to highlight aspects of a topic that might otherwise be hard to see (either because they're too abstract, or _because we're too familiar with them to actually think about them_).
Personally, i can't dance. I've never taken ballet, and the only experience i've had dancing in any form have involved massive quantities of alcohol. I'm not a rock climber either, but i have climbed rocks and can appreciate the value of skill, experience, and proper equipment. I've also spent a fair bit of time hiking through marshes, and making maps, and cutting trails...
Point is, as with any metaphor, YMMV. Gosh knows how many *football* metaphors have been wasted on me - but considering the popularity of the sport(s), i'm sure they have meaning to a fair number of other readers. Ya gotta just take what you can find...
I thought this thing was witty and sensible.
I am a former member of the Japan Expert Climbers' Club (which, despite its ridiculous name is a group of the best climbers on the face of the planet) and of the Groupe Alpine Internationale of Tokyo.
In the first I am one of the two or three least competent members. In the latter I and the excellent Wendy Holdenson, from Sweden, are the teachers, and we keep all the other members from accidentally killing themselves and each other.
The parallel with computer programming is as follows: some people are a thousand times as good as others -- in terms of lines of good code that they can produce before breakfast.
I find it ridiculous that Rock climbing is a manly sport, my 6 year old daughter outclimbs most adult males who act all macho and have little experience and some of the greatest achievements in climbing have been accomplished by women.(See Lynn Hill and her first free ascent of the nose El Capitan and then her follow up first free ascent of the nose in a day). I dont know much about programming but I assume the point of a metaphor is to draw similarities so that people can understand them on their own terms. If not many programmers are rock climbers this may not be a good example.
P.S. A chock is a form of protection wedged into the rock that a sling and carabiner are attached to that the climbers rope is clipped through for protection.
I think I just figured this whole rock climbing thing out.
It's not a methodology. Because it doesn't really tell you anything unique.
It's a motivational speech.
Which explains why so many "manly" activities are used. If you can get your team to walk away thinking they're cool extreme dudes for writing that SQL then hey, motivation! Making them think they're "sissies" will probably not have the same productivity-boosting effect.
I only wish there were more women programmers.....smokin hot women progammers.
Today on the 'Metaphors Are Fun' channel:
Software Development is like ...
- A low barrier of entry means anyone can do it, leading to high variability of quality that can't be analysed until you try it.
- Methodologies are an aid, but in no way guarantee anything.
- The end result is not guaranteed in any way to be of any benefit to you.
- Sometimes, no matter how good you are, you will burn the souffle.
Hmm... peanuts. I mean, souffle.
The point of metaphor is to take a process that is complex and bring it to a common, more understood level that is not-so complex. Perhaps, even to gain more understanding of the complex subject by extending the metaphor. The problem comes with bad metaphors that are extended and don't lend additional insight into what the author is comparing against.
The biggest problem I have with a rock climbing metaphor is that it isn't really a 'common' thing. How does a rock climbing metaphor help me understand the process of software development? Really, all that has happened is that you (Allistar, I suppose) has transferred things he knows about development to a sport he enjoys.
The building metaphor, tried and true, still goes a lot further. You can put together a dog house without a plan and even if you mess it up, it isn't a big deal to tear it apart and redo the whole thing. You really need a blueprint for a house, though. Moving an interior wall can be difficult after the house is built. That kind of thing is easy to translate to our daily jobs, in my opinion.
In my opinion the most realistic metaphor is Sport Climbing == Programming:
It's fun, it's not dangerous, it's technical but you only need strictly technical skills, you have to know your tools, but you need to know only the ones you really need, you don't need to plan a lot because the route has already been setup by someone else, and it's not very team oriented.
Oh..K. How does this rock climbing analogy hold for software testing phase?
what is it called when you get stuck and you cant climb down or up?
Being a rock climber and a programmer. I found the analogy to be very true due to the trials encountered while performing each activity.
One day while climbing with a buddy of mine we decided to follow this beautiful dihedral to the summit of a 400ft granite wall. Now don't let me fool you this was not the hardest 400ft climb you could do. That is until we were about 100ft from the summit, we hit a large overhang that provided very little in terms of protection. So here was our dilemma we were to far up to go back and reevaluate our plan, so we had to adjust it. We ended up finding a line to the right that provided safety to navigate around the overhang.
So In Comparison to Software Engineering:
There have been times as a developer that I approach a particular situation with a plan in mind. Then I come to a point where that plan is no longer 100% effective, so I must adjust.
Software projects are more like piece of art than adventure sport.
I think the reason some people are bored of analogies like this is that they are already software developers. One of our strengths, even if we do not realize it, it analogies. We really are writing an analogy every time we make code match a business requirement. We are good at it. Therefore, we do not find them to be very clever.
Likewise, one of our common faults is a lack of seeing things from a different perspective. So while articles like this could inspire epiphanies from our management, some of us tend to just be bored, instead of saying, "Yes, this is correct. Let me forward it to my boss to help enlighten the fool... erm, I mean... the guy."
Man love your idea
i m also software eng, and at same time ilove rock climbing well i m really loving your idea...
saya suka pnjat tebing...
Could you tell me who owns the copyright to the photo of the man in yellow climbing with the bridge in the background?
Could you tell me what country the bridge is in?
Thanks for any help.
The copywrite for the image is owned by me. I have not given any permission for the use or reproduction of this image and require you to remove it from this page immediately
To FEAR Love is to Fear Life Itself
It is said that when one loves another the joining of hearts form an embrace
to last an eternity. Love, which plays a vital role in couples lives form the
foundation to keep things simple and beautiful.
As Parents, as children, as
mothers and as fathers we always have that "Special" feeling for our loved ones.
--FF News Advert--
The relationships that we encountered yesterday, today, tomorrow and the future
leave footprints in our lives that perhaps changes our thoughts, our ideas, our
perceptions and our viewpoints about the people we love.
Footprints Filmworks your favorite community paper always
puts that little extra effort when we release our "Champ of the month"
Stories from all over South Africa flooded our mailboxes, email
addresses, telephone lines and post boxes telling us to post their "I love you"
messages on our forums.
The story that was well written and well told becomes
As the Month of May is our Footprints Filmworks Couple of the
this is a tale that tells of perpetual bliss, never-ending passion, bubbly
personalities and buzzing heart moments. Time, Space, Matter and Energy WILL
ALWAYS play a vital role in showing ones affection to ones loved one.
The F O U R
variables mentioned could perhaps be a blueprint to follow in leading an
awesome lifestyle with good children, passionate lovemaking, fancy Ferrari's and
I would know what I'm taking about as I have been married for thirty years.
In this thirty years I have grown up Eight Children, Survived with my husbands
bad habits, lead my own personal business and well lets just say I'm still
surviving. The day he proposed to me perhaps changed my life in many respects. I
was a dropout from the University of Wits studying my Law Degree, and here came
Prince Charming on his white horse who swept we away.
I am from a humble Indian
community and my husband is from a wealthy cocoa merchant family. We had dreams
and desires that we went through and challenges that we faced.In
Todays Times the Barbie doll wives have no clue of what it means to be
a wife. All they interested in is quick meals with no love, slap dash
lovemaking, untrained lectures to their children and moaning and groaning to get
the latest clothes in the market.
--Footprints Chrome Advert--
Although I have been married for 30 years my husband is quite the Romeo who
flirts with his office staff, plays stupid games with me to win my attention,
prank call me during my busy day at home and sometimes he even tries to bully me
into doing things I would normally never do. Indian wives perhaps have
some waking up to do when it comes to showing their love to their loved ones. I
have many of my friends who complain to me how bad their husbands are, and even
worse they try to compare their husbands to my husband.
My husband would
probably drown them when it comes to love.
It took me almost one year to make my decision to marry him. I received many
proposals from people showing interest in me, but hey, why should I complain, I
am happy, I am smiling, I am enthusiastic and and I am successful.
our eight children was a mission on its own as the bunch of brats always needed
my attention for small things which perhaps limited my growth as a person.
Glancing through the list of Champs on the Footprints Filmworks
website I was thrilled by the fact that famous faces including Nazeer
Noormohamed, Yusuf Abramjee, Afsana Gani and Sakeena Joosub were mentioned. The
story about the Imaam impressed me as I always send my husband to this Imaam to
check him up if he is cheating or doing things that I would normally never
I took my husband, lets call him Mr. X to this Imaam who handed my
husband a "Thavis" which is a religious necklace that watches over him twenty
four hours per day. This was because I would know what he is up to as well
as keeping a "watchful eye" on him.
I don't mean to bully my husband but s o m e t i m e s I have to take matters
in my own hand. This fancy new era of love is long lost. My secrets of loving my
husband include saying "I Love You" everyday, putting that extra effort into his
wellbeing and health, making sure that the children do their homework before
bed, and OH YEAH looking desirable for him even though I am 50 years.
When I spoke to Managing Director for Footprints Filmworks Omar
Abdulla he was amazed by the mere fact that one woman can bear eight
children. He laughed and joked with me asking me secrets that I would never
Perhaps the Ubuntu teaching of South Africa he should read to get a better idea of
I'm talking about.
What I learnt in my thirty years of marriage is always stick with your
partner, through the dark days, through the sunny days, through the rainy days
and even through the tough times.
We have always had money in our bank accounts
and sometimes we feel that we should spoil ourselves as well. We got so caught
up bringing our children up, we sometimes lost focus on our love. Our love,
which is our foundation for our marriage is practiced everyday to ensure
appreciation of our love.
At one stage I walked out on my husband, just to teach
him a lesson if he can survive without me. You wont believe how fast the
puppydog came running to me.
As my duty as a community person, I feel that it is my duty to empower the
youth of tomorrow with my wisdom, ideologies, weird remarks and writing to try
to influence the community in a positive direction.
Perhaps not all mothers,
wives, husbands and fathers will agree with the way I lead my family, my home,
my community and my friends, but what I can say is I have done my best.