"Fear makes the wolf bigger than he is."---- German Proverb "
“Each time we face our fear, we gain strength, courage, and confidence in the doing.”
The above quotes just talk about fear factor in general, but I will go and talk about fear factor in software development.
You fear => You Fail,
This is an observation that I have made consistently in my career, if you fear then you will fail, and recently I have observed the same again, making me write this blog. Doesn' t matter whatever technical skills we have got but too much fear of uncertainty can spoil our hard work and progress.
By nature we tend to avoid taking risks, we attempt to follow a path with higher level of certainty and when it comes to software development then we translate this in having well defined requirements, using tested and proven technology, following well practised and adopted development life cycles etc. Particularly if we have spent working years and years in an environment following typical water fall life cycle models. So when we move from such an environment to a dynamic environment where all variables 'requirements', 'technology', 'timelines' and 'resources' continuously changing, we start fearing
- I can't suggest this technology, what if we fail?
- I can't develop this feature, what if doesn't provide value to business
- I have to commit to the deadline provided by my manager, otherwise....
- I have to provide all what my users/business ask, otherwise....
- I have to follow the current practices and procedures religiously and rigorously, otherwise...
- I have to do all documentation
- I am uncertain about requirements, I have to wait and get all clarifications
- I have to save my back
- I could be kicked out if I fail
the list goes on
Agilists don't fear,
One of the core characteristic of some agile development life cycle is that we try to get rid of the fear factor i.e. Agilisits don't fear (but they are not stupid too!). They take the decision early on, they believe that the total cost of pending your decisions too long will be higher than making a wrong decision (among other correct decisions) and rectifying it later. To illustrate this just read this fictitious challenge
A fictitious challenge,
Task: You have to reach your destination 'City A' as soon as possible. You have got two options.
1. Take the safe road that will take 24 hours to get you there.
2. Take a short off road trip, that will take you there in 4 hours.
What would you do?
A risk avoiding person will take the first option. Spending more time and money in reaching the destination, fearing the second option will have unforeseen risks and he will face a lot of trouble
An agilist will take the option 2. BUT as I said Agilists (supposedly and should be) not stupid. He will get a 4WD, with spare tyres, GPS device and a satellite phone, other tools and equipment necessary to rescue himself if something goes wrong and then begin the journey.
well, hmmm...,
You don't agree?? What if this and what if that...? Well it just a fictitious scenario and yes if reaching the destination is a 'do or die' sort of thing I myself will take option 1. But in general I should go for option 2.
The agilist might fail reaching the destination but if he takes such decision 10 times (and are used to taking such challenges and well trained on using his tools) he will probably reach the destination 8-9 times and when he fails to reach the destination he might have to come back and take the safe route, 1-2 times. The point is that the overall cost of failures would be less than the cost of late decisions and lengthy processing times.
So how we map it to software development?
In typical agile development we train ourselves
on techniques like
- User stories
- Automated unit testing
- Continuous integration
- Refactoring
- Iterative development
- Just enough documentation
- Strong communication
-etc etc
using tools
- Nunit/Junit
- Cruise control
- Codegenerators like Codesmith
- Resharper
- Task management tools that support iterative development (JIRA, Gemini, MS TFS)
- communication tools
- etc etc
The message,
The message I want to convey is that when you develop software in today's world, accept challenges and prepare yourself, take initiatives and get ready to mitigate the risks. Take stand on technical and quality grounds. Ask why this way and not that way. don't accept something in the environment just because it was defined in the past.
Challenge yours and others decisions. If you BELIEVE in something then stick to it and make other people change their course of action.
It is better to be kicked out of you organisation on taking stand on quality rather than being kicked out because of not taking initiative and appearing as a dumb person.
