Let me refer you to the Chaos Report (http://www.standishgroup.com/sample_research/chaos_1994_1.php) which tells us that the main reasons most IT projects fail (over-budget/late) is exactly that reason. And then, let me ask you to step back and take a different perspective. Look at this like a business - a humanitarian business - but a business non-the-less. If we are going to provide accurate health information (what VistA is actually all about), then we MUST have definitive parameters from which to work. Saying that it will cost more to change directions after we are almost done with development is exactly correct - and that is exactly the point. The fact that we have a vision - a desire to make healthcare more affordable, more accessible - does not mean we have to take an additional year or two to get SOMETHING out to the public. The beauty of VistA is that it is not a static program, but a living system, capable of being patched AFTER we have something out there that will benefit the public.
Okay, back to the business aspect - we have a bad reputation. We have the greatest product going in the arena of health care. We have the capability of providing patient information around the globe at Internet speeds to virtually and and all systems running, and we are having a hard time selling it. Why? Because we have the reputation of taking untold amounts of time to 1: make a decision; and 2: act on that decision. Okay, I'm pontificating now, so I'll quit. Let me leave you with this - more than once a group of people have come up with awesome ideas/technology to benefit mankind and improve some aspect of life on this blue marble. And more than once, they have failed because they lapsed into esoteric diatribe instead of moving forward with practical applications. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gregory Woodhouse Sent: Wednesday, July 13, 2005 10:16 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] philosophy??? I guess I owe you a better response than that. In the post mortem of virtually every project with which I've been involved, there have been complaints of "scope creep" or inadequate analysis. It seems as if we believe that, through a herculean effort, we can anticipate every eventually, every feature the user will need to be able to use the system productively, every possible risk that might hamper the project's success, every possible platform or personnel problem, and so forth. That's just not realistic. We can (and should) plan, but in practice, that plan simply will not account for everything. So what do we do? Well, there's the old 50% rule, which may be okay for estimating timelines, but what if you choose an architecture that makes it difficult to adapt to change? It is often said that the further along the development cycle you are, the more expensive change is. (It costs more to make design changes than changes to requirements, more to modify code than to make design changes before coding starts, and so on.) There's a lot of truth to that, but could it simply be an artifact of the way we traditionally develop software? If we choose an implementation strategy where design is "locked in" once we start to code, then change will be more expensive than if we use an approach which is more flexible. That is not impossible, not even all that difficult, but it is something we have not traditionally done, given our "Just make it work" attitude (or maybe philosophy?) === Gregory Woodhouse [EMAIL PROTECTED] "The whole of science is nothing more than a refinement of everyday thinking." -- Albert Einstein On Jul 13, 2005, at 9:08 AM, Gregory Woodhouse wrote: > Tell that to the folks at MIT. Trying to build a robot capable of > walking by simply programming into it *how* it should move its legs > is all but a hopeless undertaking. > > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "The most incomprehensible thing about > the world is that it is at all comprehensible." > --Albert Einstein (1879-1955) > > > On Jul 13, 2005, at 8:44 AM, HITS wrote: > > >> Whether you are talking about uncertainty or non-determinism as it >> relates >> to philosophy or computer science doesn't seem to really matter. >> What >> matters is that you have an idea, a vision if you will, of where >> you are >> wanting to go; a firm grasp on where you are now; and a solid plan >> on how to >> get from point A to point B. Both uncertainty and non-determinism >> are >> anathama to solid development (IMHO). Even the most cloudy of >> visions can >> be clarified by clear intermediate goals that take you toward the >> cloud. >> The closer you get to the cloud, the more the mists separate; >> sometimes into >> more than one cloud; sometimes not. >> >> Bottom line - plan the work; work the plan. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] Behalf Of >> Gregory Woodhouse >> Sent: Wednesday, July 13, 2005 8:05 AM >> To: hardhats-members@lists.sourceforge.net >> Subject: [Hardhats-members] philosophy??? >> >> >> I wonder if my post last night emphasizing the difference between >> uncertainty and non-determinism (and the similarities which I think >> tend to go unnoticed) wasn't a might too philosophical. It reminds me >> of a time a week or so ago when I was sitting in a cafe reading a >> book about provability and a woman started a conversation with me (it >> turned out that she was a philosophy student at UC Berkeley). >> Immediately, I could see the look in her friend's face: "Oh no! Not >> again!" Ever since then, I've been wondering if some formal training >> in philosophy might, perhaps ironically, turn out to provide useful >> background for parts of computer science, if not software >> development. As strange as that sounds, I believe that thinking about >> the nature of the task of developing software really can help to make >> one a better programmer. I can hear it now: This guy is bonkers! >> Maybe so, but as a simple example, one question we would do well to >> ask ourselves a little more often is, What am I REALLY doing here? >> Basic design questions, such as whether a variable pointer (or >> multiple inheritance) is the right way to solve a given problem often >> hinge on the answer to a question such as this. and theoretical as it >> may seem early on, it doesn't take much time trying to support or >> enhance the code you've written before it becomes clear that the >> question was really a practical one, after all. >> >> === >> Gregory Woodhouse >> [EMAIL PROTECTED] >> >> "Design quality doesn't ensure success, but design failure can ensure >> failure." >> >> --Kent Beck >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the 'Do More With Dual!' webinar >> happening >> July 14 at 8am PDT/11am EDT. We invite you to explore the latest >> in dual >> core and dual graphics technology at this free one hour event >> hosted by HP, >> AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar >> _______________________________________________ >> Hardhats-members mailing list >> Hardhats-members@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/hardhats-members >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the 'Do More With Dual!' webinar >> happening >> July 14 at 8am PDT/11am EDT. We invite you to explore the latest >> in dual >> core and dual graphics technology at this free one hour event >> hosted by HP, >> AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar >> _______________________________________________ >> Hardhats-members mailing list >> Hardhats-members@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/hardhats-members >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
