It's been over a month since I last blogged. Yesterday was the eight week anniversary of my open heart surgery and although my incisions have healed, my body and spirit are not yet operating at 100%. I was able to start driving a couple of weeks ago (a most welcome increase in my level of independence) and can now start lifting items heavier than a gallon of milk. While it no longer hurts to cough or sneeze (indicating that my sternum has healed), it's clear that my body chemistry is still wacky. Most days my blood pressure runs around 100/60, but some days it drops to 80/50 and on those days I feel like a lump of protoplasm. Most days I'm emotionally up, but as all the physicians and literature warned me, some days I just have to crawl into my cave where I sit inconsolable.
I'm not yet back on my work email and thus I expect I've got a backlog of messages numbering in the tens of thousands. Please pardon me if i've been ignoring you, but slogging through my email is not my highest priority right now. This week, I've begun to return to research for the Handbook. As August rolls around, I'll start planning - but not yet doing - any other work activities. I hope to resume some level of travel in September.
So much has gone on in the software biz these past eight weeks: BillG has announced his retirement; Myspace.com has gained critical mass; Google continues to innovate with elements such as their windowing toolkit; IBM posted a solid quarter; Apple posted an incredible quarter; software mashups al la Web 2.0 technologies have gained traction. Still, so much is the same: developing, deploying, and operating complex software-intensive systems is still fundamentally hard; the world's current economic conditions still means doing even more with even less.
Thanks again to the people who have emailed me and snail-mailed me their greetings. I do look forward to jumping back into the fray and fighting the good fight as soon as I can.
Software architecture, software engineering, and Renaissance Jazz
First, a great big thank you to the many people who have sent me email and/or posted comments to my blog, wishing me well. Having the love of family and so many friends and colleagues is very comforting.
My surgery has been scheduled for Tuesday, May 30th at the Mayo Clinic in Rochester. I'll travel to the Clinic late next week for my pre op tests, home again over the weekend, then back out the day before surgery. Surgery will take approximately 4-5 hours after which I'll go to ICU and - amazingly - be sitting up and talking that evening. The next day I'll be taken to the step down unit, then after that 3-4 more days in the hospital, then 4 or so days in the area after my release from the hospital to ensure that there are no complications. Once I return home, it will take about 4-6 more weeks until I'll be back to normal.
Well, whatever normal means for me.
This week, I'm in in the process of shutting down work and otherwise preparing for surgery and a month and a half of recovery. I'm in the process of working out a mechanism to have someone blog my condition, so that we aren't flooded with calls.
Yesterday, two things happened that demonstrated a lovely synchronicity. First, I had lunch with Phillip Wogman, interim president of the Iliff School of Theology. Dr. Wogman is a noted author and Christian ethicist, and was also the spiritual advisor to President Bill Clinton. The main purpose of our meeting was to discuss opportunities for leveraging Iliff on the the Web, but then our conversation turned to my surgery. President Clinton had open heart surgery not too long ago, and so Phillp was able to tell me about how Bill coped. Hey, if Bill can do it, so can I!
Second, later in the day, I was burning and pillaging through my masses of email, and noted one from IBM's Mayo Clinic team, asking if I'd meet with Mayo's IT committee. IBM has already carried out some important collaborations with Mayo, including medical imaging and clinical genomics, both of which I have personally benefited by. I off-handedly suggested we could conduct a meeting in the ICU. Actually, I've told them I'll be happy to work with this team after I've recovered. It will be sort of a payback for me.
It appears that my days as a body double for Tom Cruise are slowly coming to an end.
I blogged about this matter in late 2005/early 2005 but to recap, in December of 2004 I was diagnosed with an aneurysm of the ascending aorta. This is the very thing that killed my father and his brother (both while in their late 70s) and my nephew (just before he turned 21). My sister (6 years older than I am) was diagnosed with it as well. Needless to say, there's a strong familial relationship at play here (and for that reason I'm now engaged in some genetic studies). There are no overt symptoms of an aneurysm except when it dissects, at which time the primary symptom is death which is not very predictive. Happily, there are non-intrusive means of monitoring my condition using computed tomography (CT). Evidence indicates that when the absolute size of the aortic deformation reaches a certain point or when the rate of change of the deformation is sufficiently high, the risk of surgery becomes less than the risk of the aneurysm rupturing. From an engineering perspective, it's all wrapped up in Laplace's Law.
When I was first diagnosed with this aneurysm, we set out to located the best surgeon for my case, and selected Dr. Sundt at the Mayo Clinic. 2005 was a bit of an emotional roller coaster, but in the four visits I took there last year, my aneurysm was stable. As such, this necessitated no fundamental lifestyle changes. I'm a healthy guy otherwise, although given that I've likely been living with this condition my entire life, it's amazing that USAFA didn't' kill me. I did cut off my international travel for the year, and I only had to stop weightlifting and other vigorous exercise and take on a beta blocker to radically lower my blood pressure. I decided to stay away from all mean people, too. Life is too short for that crap.
Earlier this week, I went back to the Mayo Clinic for an 8 month check up. While the absolute size of my aneurysm has not hit the critical point, the rate of change of the deformation has. Indeed, in examining the CT scans with the doctor, even to my untrained eye you can see that the aneurysm is now irregularly deformed which raises red flags in my engineering mind: you can just see the stress points in the aorta. Now, the other very good news is that this condition is treatable. Sometime in the next month or two, I'll undergo open heart surgery at which time the deformed bits of my aorta will be replaced. Open heart surgery is a common thing these days, but what makes this surgery a bit more risky is that I'll likely have to undergo circulatory arrest, which means that my body will be shut down for a while (the bit of the aorta in question is just above the heart and just below where the blood supply splits off to the brain). There is also a slight risk of cognitive loss, and being a guy who lives in his head, this is something my doctor and I don't take lightly. Nonetheless, the alternative is certain death, and that's no option for I have a long list of things I'd like to do before I shuffle off this mortal coil.
I'm not fearful of death or of the operation. My faith tells me that, in the grand scheme of things, this is but an instant in eternity. I approach the situation with confidence in the medical staff who will treat me and in the love of my family and friends who surround me.
In the coming days, I'll be shutting down all the activities in my life, with the expectation that after my body has been rebooted, I'll be able to return to normalcy sometime the second half of this summer.
Today's news reports that Microsoft has set the release date for Longhorn in the second half of 2006, with a more modest collection of features relative to its initial announcement. I've yet to install Windows XP SP2 as I'm waiting for a few more pioneers to blaze the trail, letting them fall into the dark shadows first.
It may be the case, however, that I'll never bother installing SP2. I've decided to make the move to a Microsoft-free computing environment, having tired of the time I spend on the care and feeding of XP as compared to my relatively worry-free network of Linux appliances and Macs. My latest acquisition is a 17" Apple Powerbook powered by the IBM G4 processor which I'll use to replace my XP laptop and an older G4 tower. In addition to a breathtakingly beautiful form factor, this machine has every feature I need, from DVD-R to Airport and Bluetooth connections. More importantly, there's no essential application I need that doesn't run on this platform. In this manner, I'll avoid the Microsoft operating system tax, although I will break down and install the Microsoft Office suite (which actually is nicer on the Mac than it is on XP). Eclipse runs quite handily on the Mac already, thank you: I've been developing beans with it for over a year now.
Is it therefore curious for me, an IBMer, to be carrying around a non-IBM laptop? There's no doubt that IBM makes some wonderful personal computing devices (and I'm not quite to the point where I need a zSeries machine), but to paraphase James Carville, "it's the software, stupid." In short, hardware comes and goes - and I'm very happy that dedicated hardware engineers keep coming up with better machines - but software lingers forever. Indeed, pretty much the only way to get rid of old software is to kill it. I've had data and applications in my modest environment that have persisted for almost two decades, but during that time I've blown through a number of generations of machines, each faster and with more capacity than the previous. When Longhorn comes out in a few years, I might take another look, but in the meantime, I have some real work to do and would rather not be distracted by the whinings of a needy operating system that seems to come down with a cold every time I take it out into the world.[Read More]
The past couple of months, Microsoft has unleashed a torrent of words detailing their marketecture for software factories. Alan Brown and Simon Johnston of IBM Rational have previously and very ably commented on this work, but Steve Cook of Microsoft has drawn me into the fray in his blog, so I feel compelled to reply: Steve wrote "I hope Grady Booch reads this"; well, I did :-).
I know many of the folks involved in Microsoft's software factory effort, and I very much respect what they are trying to do. We have differences of opinion, as you'll see in this blog, but it's good to watch Microsoft putting some energy into improving the development experience. As I've said many times here and elsewhere, software development has been, is, and will remain fundamentally hard, and whatever can be done to improve the profession of developing software is a Good Thing.
That being said, I'm disappointed that Microsoft choose the term "software factory," because it's an emotionally-laden phrase that harkens to extremely mature manufacturing methods that focus on stamping out endless copies of the same thing, although perhaps with slight variants therein. There's no doubt that reuse at the level of design patterns or, even better, vertically-oriented architectural patterns is a Good Thing, but what Microsoft is proposing to do is not exactly like the manufacturing metaphor, and so their use of the term is a bit misleading (although Steve has curiously used the image of a conveyor belt when describing the Microsoft factory process). Tom Demarco in his book Why Does Software Cost So Much? sets aside a chapter on software factories in which he notes - and I agree with him - that "I think factory methods for software are dead wrong, witless, and counter-effective. Organizations that build good software know that software is an R&D activity, not a production activity. Organizations that try to make it into a production activity produce bad software (though potentially lots of it)."
At OOPSLA, Rick Rishad of Microsoft publically spoke of their strategy (in a somewhat controversial way, as reported by Spencer F. Katt, which was a bit surprising given the typically-frictionless Microsoft marketing machine). That strategy was subsequently reviewed in ADT Magazine. While I agree with much of that article, they too fell into the pit of taking the software factory term a bit too literally. Perhaps the best source of Microsoft's deep thinking in this space, in addition to their site, is the book by Jack Greenfield and others, titled Software Factories: Assembling Applications with Patterns, Models, and Tools. Therein you'll see Microsoft's emphasis upon resuable assets and tooling to support them.
To that end, there's considerable common ground between IBM and Microsoft's approaches to the problem: we both agree that resuable components, as manifest both in code as well as in patterns, are the right next stage in cutting the Gordian knot of software. Indeed, IBM's been in the pattern space for sometime, starting with many of the authors of the seminal book Design Patterns to the current work led by Grant Larsen and as manifest in the open standard we pioneered through the Object Management Group, the Reusable Asset Specification.
However, we do disagree with Microsoft's rejection of the UML in favor of proprietary domain-specific languages, as noted not only in Jack's book but also in Alan Will's blog. To be clear, as Jim Rumbaugh has commented back to me, our observation - and that of our customers - is that the UML has proven itself useful much of the time, yet there are a few purposes for which it may be less appropriate. In many cases, the semantics of the UML are pretty close to what you need, although they are deeper than necessary; in such cases, a suitable UML profile is sufficient to focus the language, which allows you to leverage standard UML tools and training and yet eliminate the bloat. In those cases where the business concepts are more naturally expressed in a specialized syntax, then inventing a suitable DSL is reasonable. At the extreme, this is essentially the path that Charles Simonyi has been trodding for some years, a path that requires a very very deep and integrated underlying semantic model. Indeed, as I've pointed out in one of my earlier blogs, the root problem is not simply making one set of stakeholders more expressive, but rather weaving their work into that of all the other stakeholders. This requires common semantics for common tooling and training, so even if you start with a set of pure DSLs, you'll most often end up covering the same semantic ground as the UML.
Will's blog had a number of errors of fact, which Bran Selic has pointed out to me and so which I'll paraphrase here. Alan wrote "So here's why we don't want to limit ourselves to the UML as a basis for our users' domain-specific language" and then went on to say:
"A careful look at the specialization mechanisms for UML reveals their limitations. Stereotypes and tagged values allow you to change icons etc, although even simple alterations like decorating a box to show the state of some property isn't within range. You can't change the semantic constraints, or invent new sorts of diagram or new categories of element." This is incorrect: a stereotype allows you to define a set of associated constraints (in OCL, for example) that can capture the characteristics of your domain-specific context. While it is true that you cannot violate the semantics of the metaclass that you have stereotyped, this is actually an advantage of the stereotypeing mechanism. A stereotype is a type-compatible specialization of an existing UML concept. Consequently, you can reuse standard UML tools and expertise even though you are using a domain-specific language. Of course, if you want a language that is incompatible with UML, that is OK as well (specifically, you can define it using MOF), but you will be losing some of those benefits.
"You can't take stuff away, so your users are always distracted by other options and elements and diagrams that aren't relevant to your language. Tools that use a UML editor as a front-end have to have a (very annoying) validation step before they generate their DB schema or whatever it is." Also incorrect: as Jim noted above, a UML profile can remove any metaclasses it chooses.
"UML only includes certain types of graphical format. If you want your language to include tree-structured diagrams, or tables, or math formulae, or block-structured text, or prose, or if you want hyperlinks - well, I think you'd have a hard time. While our initial offering won't include all those styles, we'd certainly like to support them at some stage in the future." Actually, the current UML spec really does not restrict graphical formats in any way -- it simply provides a standard set of notations, but not at the exclusion of other notations. In other words, there really is no "illegal" UML graphical syntax. The formal definition of a UML graphical syntax is an outstanding item before the OMG. While this is not good, it also means that Alan's criticisms about its graphical restrictions are misguided - and Microsoft too acknowledges that these different graphical representations are a future desire for them, not a present reality.
"An important aspect of the definition of a modern language includes how you interact with it: how you navigate and elide or elaborate and edit etc - think of your favorite GUI composing tool, in which the GUI-defining language is scarcely separable from its editor. You can't do anything about these aspects in UML." We agree - but this has nothing to do with the UML but rather is all about the tool environment. IBM's tooling approach is to build upon the open standard of Eclipse, not a proprietary IDE.
"What you get out the back of one of our tools says things like CheckinDesk and ConveyorBelt. What you get out the back of a UML tool says things like Class and Stereotype - much more difficult to read. (Yes, of course you could write translators, but it's an extra layer of hassle.)" This is also incorrect: using the UML, at the model level you get back stereotypes called CheckinDesk and ConveyorBelt. At any rate, why would anyone want to look at things at the XMI or metamodel level? XML is not really for human consumption, and ultimately, MDD is all about raising the level of abstraction for the developer.
"You have to understand all of UML (stereotypes etc) before you can create your language on top of it." Not true: you just need to know the subset that you are specializing (mostly it has to do with things such as classes and associations which is what most profiles specialize). Of course, if you want to specialize state machines, you need to know the metamodel. But, if you don't care about state machines, you can ignore them safely.
"Your users have to understand an editor that's intended for something far more complex than they probably have in hand - or at least whose complexities are in a different direction." Again, this is a issue that confuses tooling with language definition.
I hope that Steve and Alan read this :-)[Read More]
That is, if you define "vacation" to include intense, non-monotonically decreasing pain, episodes of debilitating depression, and some cognitive and physical hiccups.
The good news, of course, is that which was surely going to kill me (namely, an aneurysm of the ascending aorta) has been expunged from my life. Thanks to the incredible care I received at the Mayo Clinic in Rochester, Minnesota, my demise is now more likely to come from being hit by a bus or via a tragic paper cut. As the only surviving male of the Booch lineage, since those immediately before me and after me have all died of the same condition, I owe my survival to early detection and the skill of the surgeons, physicians, nurses, and staff of the Mayo. The death of my nephew at age 20 was a gift of life to me, for it led to my being tested and that CT scan revealed I had the same condition. We were able to monitor the state of my aneurysm through 2005 and early 2006, and made the decision for elective open heart surgery at the end of May this year. This summer, as readers of this blog will know, I've been largely offline, recovering from surgery. Earlier this week, I returned to the Mayo Clinic for some follow up tests, which mark the beginning of the end of my recovery.
I had hoped for a bit more closure from those tests, but alas, that was not to be (and in that context I recall a speech by the mayor of Colorado Springs some years ago, in which he noted that, in this life, there is no closure). Physically, my surgical scars have pretty much healed although they'll never go away completely. The replacement of my aortic root took well, with no leakage or other such complications. There are unknowns with regard to my aortic valve. Technically, I underwent a modified Davis procedure, a valve-sparing replacement of the aortic root. This technique is still sufficiently new that the long term implications for my valve are unknown: will the tips of the valve wear out faster because they might rub against the Dacron graft? My left ventricle had begun to enlarge to compensate for the abnormal fluid dynamics inside my heart resulting from the aneurysm, but an echocardiogram earlier this week revealed that my left ventricle has shrunk (that's a good thing) and that my heart is actually operating more efficiently than before the surgery. I do still have some fluid around my heart that should have been absorbed by now, and that's a little concerning as it is indicative of some continuing inflammation of the heart, so I'm under yet another drug regimen to attack that issue. My endurance and upper body strength are not back to pre-surgery levels, which is not surprising given that for most of the summer as my sternum healed, I couldn't lift more than 10 pounds. Also, during this recovery, I lost over 20 pounds, mainly because I've lost much desire to eat.
Mentally, I'm pretty much back to normal, whatever that means for me. Being a person who lives in his head, the risk of cognitive decline was a very real concern, and the various studies from Duke University that I read before surgery gave me pause. During my recovery, I did have problems with concentration, the so-called pump head syndrome from being on a heart/lung machine for an extended period, but now I find that those problems are largely gone, and I'm pretty much back to where I was.
The emotional issues were the hardest. Although I knew in my head that depression after such major surgery is not uncommon, knowing it and experience it are very different things. If you are interested, the book Coping With Heart Surgery And Bypassing Depression by Carol Cohan, June Pimm, and James Jude provides the most honest discussion I've read about that element of the recovery process. Although I am an intellectual person, I'm also a whole emotional person as well. I have a propensity to melancholy as it is, and surgery then recovery greatly amplified those emotions. Happily, I am in a happier place again. Spiritually, this was period of growth and grace for me, having been surrounded by the love and care of family and friends, and - as Philippe Kruchten noted to me as as I blogged about before - having had many people in many parts of the worlds in many languages and in various systems of belief pulling for me.
It's been three months since my surgery, and I'm now starting to return to a rhythm of work. I'm back on my IBM email, and I'm starting to take on some work tasks. Most importantly, I'm using this reboot to be intentional about what I will take on and what I will shed: as I look at the long list of things I was doing before surgery, I'm stunned by how many of them just accumulated over time and really were not essential to helping me advance the practice. To that end, that I'll be returning my primary attention to the goals of the Handbook and following the evidence of existing architectures where it leads me.
I'm also starting to resume my travel. My first business trip will be to Oregon, where I'll be interviewing John Backus on behalf of the Computer History Museum, and from there I'll travel on to Ottawa to continue work with IBM Rational's Jazz project.
It's really good to be back.
Snake oil, in its uncomplimentary form, denotes a miracle drug guaranteed to cure all that ails you, yet whose mechanisms are shrouded in inscrutable details that wither in the uncompromising light of science. As nations expanded their empires - most notably the United States in a rush to fulfill its Manifest Destiny in the 1800's - grifters would rumble into frontier towns in order to extract precious dollars from unsuspecting and ill-informed citizens, selling them secret elixirs of amazing potency. These medicine men would put on a great show for a town typically lacking in entertainment, short of the local saloon which was already so mundane to the locals. These people were looking for a release, a cure that required no effort, a turn to "modern science" that would relieve them of their sufferings and perhaps more importantly, their fear of the unknown which was vast in this unscientific age.
Alas, there continue to be snake oil salesmen (and now saleswoman), but their elixirs often take a form that's far more illusive than liquid medicine. Most modern day grifters no longer ride into town on a wagon, but rather use late night TV, well-placed "scientific" advertisements, or the Internet to ply their wares. The better-capitalized ones will fly in to town with their entourage, set up a meeting at a high-class hotel, dazzle an unsuspecting and ill-informed audience with their PowerPoint wizardry, then fly away, leaving their local representatives to rake up the cash that's been thrown on the floor. Almost immediately, these local citizens will feel wiser and stronger, simply having been exposed to these confident, polished, and well-fed men and women and their shiny brochures - why, even the articles in trade magazines proclaim that It Is Good! - but once back at work and faced with the real world, they quickly find that instituting some of these new-fangled ideas is not as easy as they were led to believe and that these elixirs are not so far-reaching as promised them. A little later, some of them will get an uneasy feeling that maybe - just maybe - there are some simple fundamentals on which their organization is not executing well, and that the whole elixir exercise was worse than useless, because it actually diverted them from their real problems while creating new ones. Far too many of those people will get over their discomfort just as soon as the next medicine show rolls into town: a little distraction now and then is always a nice way to avoid reality and give your bosses the illusion of progress.
Now, let me make something excruciatingly clear, lest you misunderstand me and thus send incendiary emails and/or impel my IBM management to take me behind the woodshed for a good thrashing: I am a strong proponent of Service-Oriented Architectures (SOA).
However, I tremble at the realization that the fundamental technical benefits as well as the costs and trade-offs of SOA are sometimes lost in the guise of Snake Oil-oriented Architecture.
IMHO, SOA's value proposition begins with the A in its acronym: architecture. There is sound, proven value in governing and growing a system's architecture; there are also hard decisions that must be made, many decisions of which cannot be known a priori (which is why a process shaped around the rhythmic incremental and iterative release of executables is so important). There are many things we already know about what constitutes a good architecture and what does not. Stripped away of all the hype, a Service-Oriented Architecture is essentially a variant of well-proven message-passing architectural patterns. The variance comes in the form that services are cleverly designed to take advantage of the Web-centric infrastructure that pervades many organizations: services allow you to send and receive semantically rich messages through firewalls.
Having said that, there follow a multitude of hard technical and process decisions that must be made, which the Snake Oil-oriented Architecture showmen often neglect to tell you about: what distinguishes a good service from a bad one? what should the granularity of a service be? when should I offer up a stateless service versus a stateful one? as for the stateful ones, how to I express their semantics, and how do I ensure their their misuse doesn't corrupt my system? how do I express the semantics of a society of services (only the most trivial services work in isolation)? how do I decide upon the semantics of the information transmitted by these services so that locally they are efficient and useful but that also globally they are consistent? how do I expose some services to some clients and hide them from others? how do I offer up variants on a service, so that different clients see a different face to that service? how do I ensure the security of critical services, such that I am confident I'm not opening up holes in my enterprise that will let the bad guys in? what services should I expose to the world, and what services should I keep hidden? where are services appropriate, and where are they not? how do I best expose services in a legacy system? who should own/maintain these services? are there alternative architectural patterns I should employ instead of services, and where, and why?
These are all architectural and process decisions, which is why I tend to emphasize the A in SOA. If you ignore the S in SOA for a moment and shine an uncompromising light on your organization's software development practices, you may come to realize that there perhaps are some simple fundamentals you need to work on first, so that you can then approach the S in SOA in an appropriate, confident manner, and derive the true value from this technology.
If you do otherwise and accept the unprovable proclamations of the Snake Oil-oriented Architecture salesmen by pouring their elixir on the aching muscles and oozing wounds of your organization's people and software assets and doing nothing else, than all I can say is that you will probably get the results that you deserve.
I'm finally back home. The mile high air smells sweeter, the sunsets appear brighter, and it feels sooooo good to be back in my own bed, unencumbered by the assorted wires and tubes that had been attached to various parts of my body.
As Bill had mentioned in an earlier blog, there were some complications that kept me at the Mayo Clinic longer than I'd first expected. Specifically, my body had stopped producing red blood cells and I had a couple of episodes of irregular heartbeats.
I have such a deep respect for the medical staff at the Mayo Clinic. Dr. Thoralf Sundt was my surgeon, and his team was augmented by Dr. Enrique Gongora (his resident), Dr. Naser Ammash (a cardiologist specializing in congenital heart disease), Dr. Rajiv Purithi (a hematologist), and an incredibly competent, professional, and caring nursing staff, into whose hands I placed my life. The Mayo Clinic is so well organized that as issues arose, world-class experts were brought in immediately for consultation. It is wonderful that such an institution exists, and its reputation is well-deserved.
I continue to be amazed by the ability of the human body to heal. I still have minor aches and pains and my endurance is far from where it was before the surgery, but every day I get just a little bit stronger. My doctors advise that my recovery will take around eight weeks. I can't drive, I can't lift more than five pounds, I don't yet have the focus to sit in front of a computer, and the simple act of sneezing is a painful event. Therefore I'm doing something I've not done for about thirty years, namely, taking a summer vacation. So that my body and spirit have time to heal properly, don't expect to see me reengage in work until late summer.
I want to offer my thanks to the many people - some of whom I know, many of whom I don't - who held me and continue to hold me in their thoughts and prayers.
(Bill Higgins posting on behalf of Grady)
Grady has moved out of the hospital and is in good spirits. He must remain in the area near the hospital due to continuing medical concerns and testing.
Grady would like to thank the people who wrote the software for the machines that kept him alive.
Everyone's prayers and well wishes are appreciated.
This has to be a first. I am inside the ICU at Mayo clinic, just a few hours after my open heart surgery. Steve, my ICU registered nurse, is my eyes and fingers typing this blog. As you can tell by the very fact that I am blogging I am not dead yet.
Thanks to all of the prayers and good thoughts people have sent me around the world