CWJ: Day -3
Dear Reader,
CodeWorks 09 Vital Stats
CodeWorks 09 day #: -3
Days till I see the Lovely and Talented Kathy:10
Cities left: 7
Miles Traveled: 0
Cups of Coffee: 0
Current Current City: London
Random Statistic of the day
Number of “Random Statistics” that I have waiting to be published: 0
Prep Work
I did no prep work directly last night as I spent the evening with Yair Spitzer and Paul Wander, the heads of Ibuildings UK. On top of a great meal, we had one of the most interesting conversations I’ve had in a long time. I am however, starting to “get my head in the game” so to speak. My downtime these days is spent refining my presentations and practicing them in snippets instead of all at once.
Random Thought: Failure is ALWAYS an option
My good friend Marco Tabini recently wrote an excellent blog post titled “The Importance of Failure“, if you’ve not read it, you should.
Failure is the Sword of Damocles hanging over the head of every software development department. We worry about the consequences of failure so much that in some teams, the mitigation of the risk of failure is the primary activity of the team and not software development. Developers, Managers, Directors, and on up the line need to embrace the fact that developers are human and will fail.
What sets successful development teams and projects apart from the pack is the fact that they learn from their failures. The lesson is not always “don’t do that”. Sometimes the lesson learned is just that you are going to fail sometimes. Successful team don’t hunker down into blame mode, successful managers don’t fire people because of failure. (well, not if they are failing in different ways each time) Successful projects fail until they succeed.
Overcoming failures is a three step process.
- Own the failure.
If the project can be salvaged, the team lead and the developers need to own the failure and find a path to get the project delivered. In the extreme cases, they need to have the wisdom to throw in the towel and cut the company or project’s losses. Sometimes, you cannot wrench success from the jaws of defeat. - Learn from the failure.
Once whatever the failure is is over, take time to celebrate the failure. gather the team together and talk it out. Why did it fail? What could have been done (regardless of practicality) to prevent the failure? Let everyone have their say. Once the team understands the lesson learned, write it down. Make a historical record of the failure, what went wrong and the lessons learned and publish it company wide. Be transparent, let everyone interested learn from the failure. - Move on from the failure
You’ve failed, you know why and you know the lesson. Once it’s published, move on and never bring it up again. A failure is a personal motivational tool if a developer decides to remind him/her-self about it every day so that they don’t repeat it. It is a demotivational tool if management brings it up regularly.
If you are a developer, seek out companies and projects that celebrate failure. If you are a manager, realize that teams will fail and plan for it.
- Mitigate risks whenever possible
- Re-evaluate team members that regularly fail in the same way each time. (Possibly lessons are not being learned)
- Most importantly though, let your teams know that it is ok to fail.
Taking these steps, especially the last one will give your teams the confidence to be productive and creative without fear.
Until next time,
Ég elska þig Matvara dýrust minn Kathy
=C=
Related posts
About Cal Evans
Many moons ago, at the tender age of 14, Cal touched his first computer. (We're using the term "computer" loosely here, it was a TRS-80 Model 1) Since then his life has never been the same. He graduated from TRS-80s to Commodores and eventually to IBM PC's.
For the past 8 years Cal has worked with PHP and MySQL on Linux OSX, and when necessary, Windows. He has built on a variety of projects ranging in size from simple web pages to multi-million dollar web applications. When not banging his head on his monitor, attempting a blood sacrifice to get a particular piece of code working, he enjoys building and managing development teams using his widely imitated but never patented management style of "management by wandering around".
These days, Cal's hobby is photography. As a photographer, Cal is a pretty good programmer. He continually tries, none-the-less, to improve his skills.
Cal is currently based in Nashville, TN where is the full-time father of two and fills the rest of his day as the Editor of DevZone, for Zend Technologies.
Cal is happily married to wife 1.23, the lovely and talented Kathy. Together they have 2 kids who are infinitely more intelligent but not nearly as entertaining as his two dogs, Sparky and Linus.
Cal blogs at http://blog.calevans.com.
More About Cal »Why Attend the NFJS Tour?
- » Cutting-Edge Technologies
- » Agile Practices
- » Peer Exchange
Current Topics:
- Languages on the JVM: Scala, Groovy, Clojure
- Enterprise Java
- Core Java, Java 7
- Agility
- Testing: Geb, Spock, Easyb
- REST
- NoSQL: MongoDB, Cassandra
- Hadoop
- Spring 3
- Automation Tools: Git, Hudson, Sonar
- HTML5, Ajax, jQuery, Usability
- Mobile Applications - iPhone and Android
- More...
NFJS, the Magazine
May Issue Now AvailableClient-Side MVC with Spine.js, Part 1
by Craig WallsOn Prototypal Inheritance, Part 2
by Raju GandhiMaking use of Scala Lazy Collections
by Venkat SubramaniamIntegration Testing Web Applications Using Gradle
by Kenneth Kousen


