My wife & I recently traveled to Calgary, Alberta to attend the wedding of my wife's niece. We stayed with my sister and brother-in-law, who are the parents of the bride, so I had a front row seat for what can only be described as the insanity of the final gyrations of the process of putting on a wedding. Being tasked with nothing more than carrying stuff, driving here & there and remembering how to tie a necktie, I had the opportunity to see the association between the staging of this event and the delivery of software to production in a less-than-agile way.
First an assumption - I'm referring to a standard, North American, Christian-based wedding with a church service and reception. For the families of both the bride and groom this was the first wedding of their respective children, so they wanted to make sure it was perfect.
Wait a second... perfect? That term came up repeatedly during the 3.5 days we were there? The bride wanted such and such to be perfect. The mother of the bride wanted such and such to be perfect. The father of the bride wanted such and such to be perfect. The groom wanted such and such to be perfect. The parents of the groom wanted such and such to be perfect. People were at the point of physical and mental illness over the stress of this event. Why? Because they were absolutely obsessed with ensuring that the whole event was perfect.
My father-in-law (the grandfather of the bride) and I opined about this while driving to the church. There had been an explosion of emotion (relatively small - perhaps a couple of kilotons) the day before the wedding when it was discovered that they couldn't find all of the proper holders for the table markers. Uh, what exactly is proper? Well, they were short two (out of 15) of matching holders and that just wouldn't do. Tears and bad feelings ensued, and eventually the father of the bride drove 45 minutes across the city (one way) to a place where matching holders were found (which may actually have been an excuse to escape the insanity! :). My father-in-law wondered aloud what difference it would make, and he was told that "every girl dreams about her wedding, and wants it to be perfect". I asked if anyone had ever been to a perfect wedding, which immediately prompted a sense of déjà vu (more about that in a second). Actually, the more correct question would have been, has anyone ever noticed that a wedding wasn't perfect, or if so, did they care? The response was silence, but I'm not entirely certain if it was because anyone other than my father-in-law agreed, or that they were quietly plotting my painful demise. :)
The déjà vu to which I referred came from many presentations on XP and Agile Software Development I've given over the past number of years. I almost always started by polling the audience on their experience level. "How many people have less than 5 years in software development? How many have 5 to 10?" etc. I then ask how many of them had been on a project where nothing had changed from start to finish. There's always a knowing chuckle from the audience and I launch into my presentation. That helped me to see that there are some lessons to be learned from this obsession with perfection at a wedding, and in the delivery of software to production.
First and foremost, nothing is ever perfect. Ever. It's that simple. Any non-trivial system will have defects, just as every wedding will have a hitch or two somewhere. Some will be larger than others and can't be ignored - not having a marriage license or a bug that corrupts data fall into that category. Others will reduce the quality of the overall experience - my wife wanted Gospel singers at our wedding and would have been quite disappointed if we hadn't been able to get them, while an application may have a memory leak that forces the user to close it and restart every so often - but the show can still carry on. Still other problems may have what seems to be a tremendously inflated impact - the table marker holders or perhaps a query that doesn't run as quickly as we would prefer - but once 'production' occurs the 'user's don't even know that there's a problem.
The bottom line is that we can reduce stress in very significant ways by determining what's good enough for your given circumstances. At a wedding reception, that may mean having a DJ play quiet music during the dinner rather than hiring a string quartet. In software, that means performing risk and reward assessments on all defects and enhancement requests. Some stuff can simply be ignored, while others may need to become the sole focus of the entire team until they're fixed.
Another way that weddings and software development are similar is that nothing ever goes completely according to plan, so you need to either have contingencies or simply be able to go with the flow. When my wife & I were married, halfway through the ceremony my son (from a previous marriage) leaned over to me and said that he had to go to the washroom!! Well, when he says that, what he really means is that he had to go about 5 minutes ago and now he really, really has to go! So, I looked at one of my groomsmen, and he nodded and took my son to the washroom. They were back in two minutes, and everything went along smoothly and everyone in attendance had a good chuckle. This happens in software too, and often we need to deviate from the plan in order to accommodate an unforeseen circumstance. We don't have time to perform an impact assessment or have the Change Control Board provide their blessing. We simply have to deal with the issue right there and then.
Finally, the industries surrounding both weddings and software development have a tremendous impact. We are inundated by information from the media, colleagues, friends, etc. about what are the best approaches and tools. This happens in software too! :) Seriously, though, our expectations are inflated by these external influences and we can come to ignore our own feelings and experience about to approach putting on a wedding or building software.
I could also draw parallels between how it requires a collaborative team to handle both a wedding and software, how children can result from both, and, most regrettably, that they both have a similar failure rate. I think you get the point though! Just for fun, try describing your last project or two and replace all software development terminology with that which would be used for a wedding. You may be surprised at just how similar they are!
First an assumption - I'm referring to a standard, North American, Christian-based wedding with a church service and reception. For the families of both the bride and groom this was the first wedding of their respective children, so they wanted to make sure it was perfect.
Wait a second... perfect? That term came up repeatedly during the 3.5 days we were there? The bride wanted such and such to be perfect. The mother of the bride wanted such and such to be perfect. The father of the bride wanted such and such to be perfect. The groom wanted such and such to be perfect. The parents of the groom wanted such and such to be perfect. People were at the point of physical and mental illness over the stress of this event. Why? Because they were absolutely obsessed with ensuring that the whole event was perfect.
My father-in-law (the grandfather of the bride) and I opined about this while driving to the church. There had been an explosion of emotion (relatively small - perhaps a couple of kilotons) the day before the wedding when it was discovered that they couldn't find all of the proper holders for the table markers. Uh, what exactly is proper? Well, they were short two (out of 15) of matching holders and that just wouldn't do. Tears and bad feelings ensued, and eventually the father of the bride drove 45 minutes across the city (one way) to a place where matching holders were found (which may actually have been an excuse to escape the insanity! :). My father-in-law wondered aloud what difference it would make, and he was told that "every girl dreams about her wedding, and wants it to be perfect". I asked if anyone had ever been to a perfect wedding, which immediately prompted a sense of déjà vu (more about that in a second). Actually, the more correct question would have been, has anyone ever noticed that a wedding wasn't perfect, or if so, did they care? The response was silence, but I'm not entirely certain if it was because anyone other than my father-in-law agreed, or that they were quietly plotting my painful demise. :)
The déjà vu to which I referred came from many presentations on XP and Agile Software Development I've given over the past number of years. I almost always started by polling the audience on their experience level. "How many people have less than 5 years in software development? How many have 5 to 10?" etc. I then ask how many of them had been on a project where nothing had changed from start to finish. There's always a knowing chuckle from the audience and I launch into my presentation. That helped me to see that there are some lessons to be learned from this obsession with perfection at a wedding, and in the delivery of software to production.
First and foremost, nothing is ever perfect. Ever. It's that simple. Any non-trivial system will have defects, just as every wedding will have a hitch or two somewhere. Some will be larger than others and can't be ignored - not having a marriage license or a bug that corrupts data fall into that category. Others will reduce the quality of the overall experience - my wife wanted Gospel singers at our wedding and would have been quite disappointed if we hadn't been able to get them, while an application may have a memory leak that forces the user to close it and restart every so often - but the show can still carry on. Still other problems may have what seems to be a tremendously inflated impact - the table marker holders or perhaps a query that doesn't run as quickly as we would prefer - but once 'production' occurs the 'user's don't even know that there's a problem.
The bottom line is that we can reduce stress in very significant ways by determining what's good enough for your given circumstances. At a wedding reception, that may mean having a DJ play quiet music during the dinner rather than hiring a string quartet. In software, that means performing risk and reward assessments on all defects and enhancement requests. Some stuff can simply be ignored, while others may need to become the sole focus of the entire team until they're fixed.
Another way that weddings and software development are similar is that nothing ever goes completely according to plan, so you need to either have contingencies or simply be able to go with the flow. When my wife & I were married, halfway through the ceremony my son (from a previous marriage) leaned over to me and said that he had to go to the washroom!! Well, when he says that, what he really means is that he had to go about 5 minutes ago and now he really, really has to go! So, I looked at one of my groomsmen, and he nodded and took my son to the washroom. They were back in two minutes, and everything went along smoothly and everyone in attendance had a good chuckle. This happens in software too, and often we need to deviate from the plan in order to accommodate an unforeseen circumstance. We don't have time to perform an impact assessment or have the Change Control Board provide their blessing. We simply have to deal with the issue right there and then.
Finally, the industries surrounding both weddings and software development have a tremendous impact. We are inundated by information from the media, colleagues, friends, etc. about what are the best approaches and tools. This happens in software too! :) Seriously, though, our expectations are inflated by these external influences and we can come to ignore our own feelings and experience about to approach putting on a wedding or building software.
I could also draw parallels between how it requires a collaborative team to handle both a wedding and software, how children can result from both, and, most regrettably, that they both have a similar failure rate. I think you get the point though! Just for fun, try describing your last project or two and replace all software development terminology with that which would be used for a wedding. You may be surprised at just how similar they are!
Comments