Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please.

[Karsten Hilbert]

> > Lack of formal project management practices
> I've noted Tim Churches reply and his peripheral involvement. Perhaps he 
> could 
> be co-oeced? Certainly I think it should be someone outside of the core 
> group.
Oh, I would be fine with Tim, too (I'd have a harder time
pushing "my agenda" *evil grin* but, hey, I think he could do
the job). I just never thought he'd be interested to/would have
time to do so.

> > > Anyone checking out the gnuMed web site is confronted by the following
> > > hopeful description;
> 
> I didn't say I didn't like it
No you didn't - but I said I didn't. It sounds a lot like
grand scheming, like Revolutionizing Medical Practice(tm),
a phrase veteran Adrian Midgley warned against (Ars longa, IT
brevis).

Often times it is not the content but rather the wording of
something that casts doubt upon things. If we remove the hype
and put things in perspective (eg. this first, that later) the
content of the current boilerplate is, of course, what
everyone would want for GnuMed to happen eventually.

> I think it is a 
> very concise, clear and should definately be left on the site. My comment 
> more pertained to the fact that it promised much, but after much development 
> wasn't within cooee of delivering the basics.
Precisely, so why not remove the hype, IOW the Big Promise,
and replace it with incremental little promises ?

> > Why not concentrate on a few realistic use cases for
> > now ?
> Because I can't see how that will advance anything.
It will get those use cases working. Not sure how that is not
advancing anything ?

It's like my Mom deciding (and she has) that she wants the
best vaccination status handling she can get. So I figured I
need within GnuMed:

- allow her commercial application to hand a patient to GnuMed
  and raise the vaccination widget - done
- in case the patient does not exist, create it - not done
- allow definition of vaccines, schedules, put patients on
  schedules, calculate missing vaccinations and a vaccination
  status chart with prospective dates - done in
  backend/middleware, GUI partially missing
- allow for rapid, assisted entry of given vaccinations (this
  is where Richard's edit area shines hence I implemented it)
  - fairly done

So, what is wrong with that ? It is a clearly defined use case
and I've been working on it (should mention that Carlos also
contributed).

All this needs to be implemented by Good Code, eg code that
does not prevent me from a) using the data in other ways, b)
let me re-use the middleware/UI code in other parts of GnuMed.

My Mom couldn't care less whether today GnuMed does anything
else (apart from the document archive).

BTW, same with lab results. We implemented a lot of
functionality for this and attempted to make it be able to
accomodate any type of measured results, not just German lab
data. It so happens that AU lab data does not come back as
measured results which makes it a bit difficult to put that
into the Measurements part of GnuMed. Jim has defined a use
case for his anticoag clinic. If he keeps pushing successively
more defined specs our way we (I) will be happy to improve
GnuMed lab data handling to accommodate for his needs. This
should and will make GnuMed's lab handling more generic.

> I'd advocate an approach you dislike intensly, ie RAD of a gui-functional 
> prototype, which seems to offer the promise of doing everything, but in fact 
> does nothing (yet).  IE you sort out what you want the program to do, put the 
> GUI in place to do it
This is excellent as a skeleton around which to develop the
actual application. Given detailed specs like yours it takes
the hard part of deciding on a GUI off the coder's shoulders
(I couldn't really design a sane GUI in any case).

However, as for the potential *release* candidate it should
not promise "everything" but do surprisingly little. It should
do what it seems to do. And that should be something real people
actually want. This is no different from what you did in your
impressive list of projects - you extracted what they wanted
and implemented that. The difference is that we try to write
code that would not require a different database/middleware
for each of those little projects and even offers a GUI
framework (uh oh, there's the bad word) that is flexible
enough to host GUI plugins written to each of the little
projects. No different in the net result.

> bones, and then once the design functionality is acceptable to the client do 
> the solid backend and debugging.
Hey, we already do that ! Maybe in a less formal way that
you'd wish: We got your specs, we got your VB client, we even
got your partial implementation of the specs. Off those we
develop the "real" client and add backend/middleware stuff as
needed (but try to do so with "vision") - where's the wrong ?

> Note that many of these programs were developed in conjunction with a 
> committee of people (management team), where the specs were defined, written 
> down (as part of the HUDGP process/contract). The method of developing the 
> GUI/ showing the team, modifying etc, then doing the nuts and bolts works 
> well.
We don't have the luxury of a working manangement team/process
we can piggy-back on. But we do have specs written down (eg
yours) which are followed for the GUI. Not to the letter as
you cannot anticipate the use cases.

> Our current gui which has been bastardised from my original concepts really 
> is 
> crap. It is non-functional and never will be functional.
I fully agree it is nowhere near perfect. I wonder why though both
my parents and all their staff do get along with that GUI re the
document archive.

> One of my talents (though many may disagree) is that because I'm not a good  
> 'coder' ... is that  I can easily see a finished functional gui, 
That's why I strongly want you to stay with GnuMed.

> At the end of 
> the day, just as I recognise I'm not a coder, the coders have to recognise 
> that their talents maybe don't include design,
Mine certainly don't.

> The 2.5 design (BTW Thilo had a look at that) is implementable in 2.4.
IMO 0.1 is not the place to change away from the current base
UI code. Neither is moving to 2.5.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346