While I normally blog about software development, today I'm going to blog about something much more personal, something that most of my friends probably don't know. The trigger is the debate on the right to assisted suicide in the UK and on the right to access even information about assisted suicide in Australia, which would be blocked by the proposed internet filter. While I won't be as articulate as Sir Terry Pratchett I want to present my personal experience.
I was in my mid-20s when my partner's mother, still in her 40s, was diagnosed with breast cancer. Even though she lived in Cairns, a rural centre, she received excellent care, including flights on the air ambulance to city hospitals when she needed them. That experience, and my own health issues growing up, cemented for me the importance of free national health care, but my brush with assisted suicide came towards the unfortunate end of the story.
Despite a radical masectomy and many other treatments the cancer spread to Margaret's bones, and eventually she deteroriated quite rapidly. One day we got a call that if we wanted to see Margaret alive we needed to come to Cairns, right away. My partner was in Melbourne, I was in Sydney, one of my partner's siblings was on a prawn trawler in the Gulf of Carpentaria, but we all dropped what we were doing and went to the airport. I remember walking out of the office, telling my boss that I was leaving right away and I didn't know when I would be back, and him simply replying "Ok, do what you need to do" (thanks for that Brian).
We all arrived in Cairns and started a vigil by Margaret's bedside. She was immobile - her bones were so weak and brittle that the nurses needed to be careful not to break them when they changed the bed - she had difficulty breathing, and she was very weak, but she lingered. She was pleased to see all her children, but it was obvious that she was unhappy and she was not going to get better. One morning she told us, in short breaths, that it was impossible to hold your breath until you died - she'd tried it the night before and it didn't work.
Margaret had been estranged from her husband before the cancer got very bad, but they had moved back in together to look after her and their youngest child, who was about 12. He was pretty rung out and wasn't really part of the decision-making around Margaret at the time. He was a diagnosed manic-depressive and we were concerned that he might commit suicide after Margaret died, so we talked about how to handle the care of the youngest child in those circumstances. We also needed to talk to Margaret about formalising her will (if you haven't, please do that now, as handling it on your deathbed is no fun for anyone). As the older partner of the oldest child, some of the responsibility for these things rested with me. Eventually the conversation also came around to Margaret's death. It was clear that she was ready to die, from both her actions and her words, and we could see that she might ask one of us to help her. What would we do? What would I do?
I don't know what everyone else thought. I think we talked about it without making any final decision as a family, but I also know that I made a decision in my own mind. If Margaret asked me to help end her life I would do whatever I could to help. I would do it with tears in my eyes (like the ones I have in my eyes now, writing about this more than 20 years later), but I would do it nonetheless. And it would be illegal, and I would bear the consequences - the legality or otherwise of the action made no difference to the decision and the act, though it might have made a considerable difference to my life.
Margaret peacefully and quietly passed away one night in her sleep, with her eldest daughter at her bedside.
Assisted suicide isn't a theoretical issue for me, it's a hard, practical one that I faced head-on, and having made that decision once I know that if the circumstances arose again I would make the same decision. I believe that as a caring and compassionate society we should be able to extend the right to die with dignity at the time (and if possible the place) of our own choosing to everyone. I believe that the benefits of providing that right outweighs the cost and effort of monitoring to make sure that the right is not abused.
Saturday, April 17, 2010
Wednesday, April 14, 2010
Quality - I wish we'd be a little more precise
Many years ago I worked at Bankers Trust Australia, building derivative product applications with VMS Cobol for the user interface and Fortran for the numerically intensive parts. I mention the technology so that you can understand that this was the early days of the derivatives markets when there were only a few players in Australia, using relatively unsophisticated technology. I remember how proud we were of the first release, particularly of the way we validated all the user input and provided field-by-field feedback to the traders. Then I was lead into a trap.
"Wow, that validation is really impressive. It must have taken you quite a while to do that", said a trader.
"Yeah, it probably took a few weeks to get it all right", we replied.
"So you could have delivered it a few weeks earlier if you hadn't done that?"
"Yes, but the application would have crashed each time you made a mistake and you'd have had to start again", we said.
"We're pretty smart, and we can learnt to deal with that. Next time we'd rather have the features two weeks earlier so we can make some money from them thanks".
The underlying problem was that we hadn't talked to them about what was important (my excuse is that it was a long time ago and I was young and naive), but the lesson has stuck with me. In that situation, an input function vomiting it's guts on the screen was a scope issue, not a quality issue. In the years since I've regularly heard people say "we cut quality to go faster" or "we cut quality to finish earlier", but when I dig deeper I invariably hear that they altered the behaviour from the end-user perspective, and to me, a developer on a software project, that's cutting scope. I appreciate that other people with different perspectives might consider these features to be the difference between a high-quality or low-quality application, so when we start talking about "quality" we probably need to clearly understand which perspective we're talking about.
I was reminded of that by a recent post by Uncle Bob that starts with "People often make the argument that time to market is more important that quality. I’m not sure just what they mean by that. Do they mean that it’s ok if 20% of the features don’t work so long as they deliver quickly? If so, that’s just stupid.". I think that would be stupid, but what I think people mean is that the internal quality of the code has been sacrificed to reduce initial time to market, which is a very different proposition.
"Wow, that validation is really impressive. It must have taken you quite a while to do that", said a trader.
"Yeah, it probably took a few weeks to get it all right", we replied.
"So you could have delivered it a few weeks earlier if you hadn't done that?"
"Yes, but the application would have crashed each time you made a mistake and you'd have had to start again", we said.
"We're pretty smart, and we can learnt to deal with that. Next time we'd rather have the features two weeks earlier so we can make some money from them thanks".
The underlying problem was that we hadn't talked to them about what was important (my excuse is that it was a long time ago and I was young and naive), but the lesson has stuck with me. In that situation, an input function vomiting it's guts on the screen was a scope issue, not a quality issue. In the years since I've regularly heard people say "we cut quality to go faster" or "we cut quality to finish earlier", but when I dig deeper I invariably hear that they altered the behaviour from the end-user perspective, and to me, a developer on a software project, that's cutting scope. I appreciate that other people with different perspectives might consider these features to be the difference between a high-quality or low-quality application, so when we start talking about "quality" we probably need to clearly understand which perspective we're talking about.
I was reminded of that by a recent post by Uncle Bob that starts with "People often make the argument that time to market is more important that quality. I’m not sure just what they mean by that. Do they mean that it’s ok if 20% of the features don’t work so long as they deliver quickly? If so, that’s just stupid.". I think that would be stupid, but what I think people mean is that the internal quality of the code has been sacrificed to reduce initial time to market, which is a very different proposition.
Subscribe to:
Posts (Atom)