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

[Karsten Hilbert]

> I'd ask anyone reading this to give it time and considered, not knee jerk 
> opinion. Though I've mentioned particular names of some of those involved in 
> the project, I hope that those mentioned are able to not take any comments 
> I've made in a personal way.
No problem.

> Also, firing back comments to this post such as 
> 'its in the Wiki' 'It's in the road-map' is not going to be helpful.
Especially since we don't have the Wiki back up yet :-)

> Slashdotters amongst you may possibly already have read one of today's links 
> entitled "Developers, is your project a sinking ship?". If not please read 
> the link before continuing: 
It lists the following causes sinking a (commercial) project:

Use of an inappropriate technology

 I have seen no evidence yet to the fact that we are doing
 that. In fact, most people with technical understanding who
 took a look at GnuMed technical points were in favour of what
 we do.

Lack of customer involvement

 If any we've got too much of it. I would assume Richard would
 say that those are the wrong *kinds* of customers, eg the
 involved users also are the developers. However a) we always
 invite non-developers to join in and take action and b) there
 isn't really any such thing as a *customer* for GnuMed. There
 will be *users* eventually. Those users will only turn into
 customers of GnuMed when there is a company taking GnuMed,
 packaging it, polishing it and *selling* it to them. No
 problem that I can see here.

Dissimilarity to previous projects

 This applies to companies doing a "new" product. They should
 base it on "existing" solutions. Translated to GnuMed this
 would mean we should base our solution on existing FOSS
 solutions. And we do. I have looked at about a million open
 source EMRs. I have looked at Richard's design/client. I have
 assessed a few commercial packages I have access to. I have
 taken ideas and lessons from all of them. We have (by matter
 of action or rather non-anti-action) decided to let Richard's
 design be our reference design. Personally I don't think we
 are too bad on this.

Lack of formal project management practices

 Yes, we are lacking here. Make a suggestion as to who would
 be doing this. There are three people I trust to do a good
 job on this: Sebastian, Jim, Andreas. Andreas does not have
 the resources. Sebastian already volunteered to be the
 "relaese manager" once release time comes up. Jim, wait, Jim
 already sort of did some project management.

> Anyone checking out the gnuMed web site is confronted by the following 
> hopeful description;
I never ever liked that. Please feel free to make a proposal
today as to what we should write there. I am happy to lend my
voice to replace that boilerplate.

> The essence of the problem to me is whether or not gnuMed can ever offer an 
> alternative to current medical software
I wonder whether that's the concern ? This sounds like
clamouring about not being able to build a fully furnished car
because we lack the more sophisticated tools for
leather-furnishing the seats and gold-plating the steering
wheel. Why not concentrate on a few realistic use cases for
now ?

> Having such an ambitious project which in the end only 
> works for a few individuals in the world because that's the way they designed 
> it, is not of much use.
Well, how else would you define the milestones ? As I see it
the only thing that works for a vertical application is to
define use cases and work on them. And then go back and
redesign to keep them working but make the infrastructure
flexible enough to a) cover similar use cases and b) be able
to be enhanced to different use cases.

> Some sort of project management I beleive is essential for gnuMed.
Does that sound like you volunteer ?

> each of the developers have an allocated role
Unfortunately, "each of" is a bit of an overstatement here.

> ... a number of active developers on the list seem to 
> actually beleive that there is structure and process
I for one don't think there is much of (formal) structure and
process. I happen to think, however, we don't need much more
of that quite yet (we will, eventually). I do think there is
(informal) structure and (if slow) proGRess, however. The one
thing we need to tackle with a formal-type process *first* is
a sane schema-upgrade/data-migration methodology.

> 1) We need a project manager WHO IS NOT INVOLVED WITH CODING.
Suggest someone. I suggest Jim, Andreas or Sebastian.

>  ie someone with project management experience and talents who at the end of 
> the day has the final say
If you find someone suitable ...

>, who can overide Karsten, Horst, Ian, myself, 
> carlos, etc, because they will have the ability to have a larger over-view 
> than anyone in the project.
If that is truly so, no problem with that.

> 2) Individuals who are accepted as part of the project development team need 
> to have their abilities respected, and given the final say in their aspect of 
> the project design over other team members, subject to the final decision of 
> the project manager.
That really isn't much different from now except we don't
have a project manager and that the "final say" is informal.

> 3) We need a heavy dose of reality checking in respect to what will make the 
> project actually become usuable
Please do make suggestions. I am eager to hear them. I always
propagate working against use cases. That's why I work on
mine. That's why I am happy to work on Jim's anticoag clinic
any minute as long as he keeps pushing that use case.

> e.g sticking to the niave belief that drugref 
> will be able to provide usable drug data
I for one am not sticking to that. I have already considered
writing interfaces to two of the German databases, eg Gelbe
Liste and IFAP. Haven't had a use case (spell, need to act)
yet, however. They provide their own frontends interfacing to
which is butt-ugly both design-wise and technology-wise but you
called for pragmatic decisions. Of course, once drugref
delivers it will be interfaced.

> Though I almost cringe at the thought of another frustratiing day, perhaps 
> its 
> time for another gnuMed AU(+DE) conference to thrash this out for once and 
> for all.
There is no such thing, "once and for all".

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