I appreciate this comment. I write code for a hospital. I'm curious how many other programmers here have had the experience of trying to adapt the logical constraints of programming with the ad hoc conditions of health care? I find that your comment about tidy algorithms existing only in books is apt. In the health care milieu, there are very few "tidy problems," precious few systems which lend themselves to discreetly quantifiable logic. There are always multiple exceptions. New decision loops continually intrude on any system so that you have to leave room for the end user to make spontaneous decisions. The same is often true in business programming (especially because of something like tax accounting), and health care combines both the often non-intuitive complexities of business accounting (esp. with regard to insurance claims) with its endless exceptions and special cases, with the impossibly human conditions of point-of-care decision making. I wrote a program to manage insulin therapy administration and the flow diagram looked like a plate of spaghetti. The program works quite well and has improved outcomes, but I always ask myself, how well does it accommodate the incredible complexity and the always threatening presence of the intuitive imperative in patient care? What about that looming black swan? Honestly, I'm not entirely comfortable with it. However, we continue to press for enveloping medicine with highly discreet logical structures. There's no proper accommodation for this even through fuzzy logic, that I can see anyway.
My personal experience is that healthcare requires continual expansion beyond present understanding. Any current logical framework is going to be inadequate as experience reveals deeper causation. But I digress. I just wanted to lend support from my own personal experience as a programmer to the idea that elegant code is at times a luxury of academia, an ideal, more than a quality of the practical application of programming methods. It is valuable as an ideal, though. That elegance isn't always possible doesn't mean you can't still structure and comment and plan carefully so that the code you write is intelligible to others, and to your future self when you have to make the inevitable modifications. And the ideals of elegant solutions can always be a useful guide. If that kind of coding is elegant, then elegance is still possible in any context. But I'm honestly not confident that some practical applications allow for elegant implementation of the logical constructs of code. It is too constraining for some applications, such as healthcare.
Another demonstration in support of that view is that the many vendor applications with which I work, often in attempts to integrate them with each other, are fraught with bugs and failure points. But that's not even the most significant issue. The real problem is the work-arounds required by the end-user by such applications just to get their jobs done. And I'm talking about major vendors, like McKesson, with huge resources and vast amounts of invested time. While their applications may be enormous and sophisticated, and expensive, in the healthcare environment they require constant care, constant work to make them work, if that makes sense. This problem is transferred over to the development of code that integrates with these systems. So, to my mind, elegance isn't possible in every instance of a practical programming. I used to write simulations of mathematical and physical systems for fun -- that allowed for elegance. But those are highly structured, highly ideal contexts. It is at the opposite end of the spectrum.
Slashdot Mirror
I appreciate this comment. I write code for a hospital. I'm curious how many other programmers here have had the experience of trying to adapt the logical constraints of programming with the ad hoc conditions of health care? I find that your comment about tidy algorithms existing only in books is apt. In the health care milieu, there are very few "tidy problems," precious few systems which lend themselves to discreetly quantifiable logic. There are always multiple exceptions. New decision loops continually intrude on any system so that you have to leave room for the end user to make spontaneous decisions. The same is often true in business programming (especially because of something like tax accounting), and health care combines both the often non-intuitive complexities of business accounting (esp. with regard to insurance claims) with its endless exceptions and special cases, with the impossibly human conditions of point-of-care decision making. I wrote a program to manage insulin therapy administration and the flow diagram looked like a plate of spaghetti. The program works quite well and has improved outcomes, but I always ask myself, how well does it accommodate the incredible complexity and the always threatening presence of the intuitive imperative in patient care? What about that looming black swan? Honestly, I'm not entirely comfortable with it. However, we continue to press for enveloping medicine with highly discreet logical structures. There's no proper accommodation for this even through fuzzy logic, that I can see anyway.
My personal experience is that healthcare requires continual expansion beyond present understanding. Any current logical framework is going to be inadequate as experience reveals deeper causation. But I digress. I just wanted to lend support from my own personal experience as a programmer to the idea that elegant code is at times a luxury of academia, an ideal, more than a quality of the practical application of programming methods. It is valuable as an ideal, though. That elegance isn't always possible doesn't mean you can't still structure and comment and plan carefully so that the code you write is intelligible to others, and to your future self when you have to make the inevitable modifications. And the ideals of elegant solutions can always be a useful guide. If that kind of coding is elegant, then elegance is still possible in any context. But I'm honestly not confident that some practical applications allow for elegant implementation of the logical constructs of code. It is too constraining for some applications, such as healthcare.
Another demonstration in support of that view is that the many vendor applications with which I work, often in attempts to integrate them with each other, are fraught with bugs and failure points. But that's not even the most significant issue. The real problem is the work-arounds required by the end-user by such applications just to get their jobs done. And I'm talking about major vendors, like McKesson, with huge resources and vast amounts of invested time. While their applications may be enormous and sophisticated, and expensive, in the healthcare environment they require constant care, constant work to make them work, if that makes sense. This problem is transferred over to the development of code that integrates with these systems. So, to my mind, elegance isn't possible in every instance of a practical programming. I used to write simulations of mathematical and physical systems for fun -- that allowed for elegance. But those are highly structured, highly ideal contexts. It is at the opposite end of the spectrum.