gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please.
Date: Sun, 9 Jan 2005 11:50:34 +0100
User-agent: Mutt/1.3.22.1i

>    I (and many othe people also involved in health informatics in
> Spain) never thought GnuMed as any kind of unmanaged project, neither as
> a project lead in the wrong way.
I think this is really two different points. Richard argues
that GnuMed suffers from insufficient (not lack thereof)
*management*. I don't think he argues for it going the *wrong
way*.

>    As a coder, i've worked in medium size projects suffering the pain
> of writing code for lots of screens and forms and designing and
> redesigning the model at the same time... the PM usually just gave us a
> sketch of the functional requirements, but we cried for ... *model*. I
> confess, even in those adverse situations, the projects were successful
> and the applications are dealing with critical informations 24 x 7  ...
> so , what could we have done if we had got the appropiate  model -
> backend before coding the rest of the app? ;)
While it certainly helps to have a thoroughly thought out
backend schema that isn't quite the same as having a "formal"
model. One needs to ask "Model for what ?". For how the
application is supposed to behave (Richard does that for us) ?
*How* data is stored (the backend hopefully answers that
question) ?  Or how medical data is handled including
reference to what the data *is* in the first place ? We don't
do the latter quite yet and likely will only then do it when
we can switch to working with OpenEHR archetypes eventually.

> So, at this stage of development, I would schedule the model (GnuMed
> backend) as the main objective.
Having a strong backend certainly is one of the aspects I
consider paramount for 0.1. That can not mean it's the last
schema we will ever have but it should be strong in it's
basics, eg. not bearing to many arbitrary limits.

>    -people tend to encourage less discussion and more coding
>    -there's not great pain in committing and releasing initial
> approachs and "there's always time to fix the bugs"
The difference is that in GnuMed we don't work on displaying a
pretty button somewhere showing system activity but rather fate
ourselves with storing medical data upon which life-and-death
decisions *might* potentially be taken. No way we can be sloppy
with storing that data. Utmost care needs to be taken in the
fundamentals.

>    If you look at KDE, there are the mailing lists, the roadmap and
> some general good decisions. We have all of them. But we have not their
> resources (material, human...)... really I prefer not looking at other
> projects and comparing, I consider we're wise enough to drive this
> project to the best way by ourselves...
But we can surely learn from others.

> >I've watched a large number of talented people come enthusiastically to the 
> >project, only to melt away into cyberspace.
>    And many were (legitimally) looking for a ready-to-use software. In
> my experience, I found a very kind small community, lot of help and
> collaboration and  concrete tasks to be progressively involved... who
> can ask for more? ;)
I should agree with Carlos here though Richard seems to
disagree. As Tim pointed out he thinks we are in pre-alpha.
Given that's true new team members need to have *some* technical
knowledge. We aren't into making it easy for non-technical
people just yet IMHO.

>    Sorry if i repeat myself. For me, we *do have project management*,
> and Karsten is doing an excellent work on driving and helping this boat
> to arrive to a good harbour.
But I am only one of the rowers and deciding which way to turn
my pulley. I am not sitting at the steering wheel (not
intentionally, anyways).

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]