[Top][All Lists]
[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: |
Richard Terry |
Subject: |
Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please. |
Date: |
Thu, 6 Jan 2005 14:02:28 +1100 |
User-agent: |
KMail/1.5.4 |
snip.....
> 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.
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.
>
> > 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.
I didn't say I didn't like it - personally I like it alot. 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.
=======================================
[Just in case:
[Cooey \Coo"ey\, Cooee \Coo"ee\, n. [Of imitative origin.]
A peculiar cry uttered by the Australian aborigines as a call
to attract attention, and also in common use among the
Australian colonists. In the actual call the first syllable
is much prolonged (k[=oo]"-) and the second ends in a shrill,
staccato [=e]. To represent the sound itself the spelling
cooee is generally used.
Within cooey, within earshot.
Cooey \Coo"ey\, Cooee \Coo"ee\, v. i. [imp. & p. p. Cooeyed or
Cooeed; p. pr. & vb. n. Cooeying or Cooeeing.]
To call out cooee. [Australia]
=====================================
> Why not concentrate on a few realistic use cases for
> now ?
Because I can't see how that will advance anything.
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, and then bit by bit add the underlying code. This is
no different from how software is developed usually, one normally does a
needs analysis/talks to people in the workplace, do a mock up design, show
it to them, see if it sits with what they want to do, put some flesh on the
bones, and then once the design functionality is acceptable to the client do
the solid backend and debugging.
Over the past 20 years in various languages I've developed and used (1984 -
FORTH - text mode graphics and text editor, 1984 Basic - cheque and expenses
managment program (used it for many years at work), 198? Billing and
appointment system (VB) used in this practice for years till supplanted by
Pracsoft, 1995 Script writer (VB) used by many doctors as part of software
project and for a long time after till I confiscated it because of support
issues (1996) Diabetes managment software (VB) - again project for HUDGP used
by many doctors (1997) Pathology ordering program (VB) - software project in
conjuction with Hunter Area Pathology Service + HUDGP, 1997 + Medical Billing
project (Mine) 1998 Contacts Manager for HUDGP (after they paid for and
discarded ACT) used on 30+ NT machine network. Not to mention inumerable
other mini-programs including things like user-extensible ICPC coding
modules, form generators etc etc etc.
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.
Our current gui which has been bastardised from my original concepts really is
crap. It is non-functional and never will be functional. It contains a whole
lot of elements which will never be used by 99% of GP's and should be
discarded (eg the python tab). The tabbed bottom system is illogical and
clumbsy.
One of my talents (though many may disagree) is that because I'm not a good
'coder' like Karsten/Carlos etc, and because I'm very much a visual person
who sees the big picture, and have developed so much clinical related
software in the past, is that I can easily see a finished functional gui,
and can also often see where and why many of the suggestions on the list
regarding function and gui won't work (both from my intuition and because
I've 'tried that and it didn't work many years in the past'. I'm also able to
take on board suggestions of others regarding the gui and incorporate/evolve
that into my conceptual/design process.
I'm more than happy to hit the gui-prototyping again and attack this (as I
have with my 2.5 examples. However it's no good me doing this if it is not
adopted because others can't see the grander functional result. 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, and they have to let go and
just allow the gui-designer to do his stuff. That's not to say that everyone
doesn't say 'hey I don't like that - why don't we do x,y,z, or 'I don't think
that will work'. Do so, but let the gui-designer then experiment and make the
modificications, and if at the end of the day he decides, 'no we will do it
this way', then so be it, the backend coders will have to work around that.
The 2.5 design (BTW Thilo had a look at that) is implementable in 2.4. However
I think the whole debate about moving to 2.5 needs to be raised because
ultimately that's were we will end up and it is better to take the pain now
and move on. We could fudge a listbooks like function in 2.4 if we had to.
> > Some sort of project management I beleive is essential for gnuMed.
>
> Does that sound like you volunteer ?
No - I'm not a manager, but I'm more than happy as at nauseum I've said to be
the functional/gui manager, which is quite a different thing to the project
manager.
Regards
Richard
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., (continued)
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Horst Herb, 2005/01/06
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Horst Herb, 2005/01/06
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Karsten Hilbert, 2005/01/06
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Horst Herb, 2005/01/06
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Karsten Hilbert, 2005/01/06
Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Karsten Hilbert, 2005/01/05
Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Karsten Hilbert, 2005/01/05
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please.,
Richard Terry <=
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Horst Herb, 2005/01/05
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Richard Terry, 2005/01/05
- Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Horst Herb, 2005/01/05
- [Gnumed-devel] the WHO INN list, Richard Terry, 2005/01/06
- [Gnumed-devel] Re: the WHO INN list, Horst Herb, 2005/01/06
Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Karsten Hilbert, 2005/01/06
Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Horst Herb, 2005/01/06
Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., Karsten Hilbert, 2005/01/06
Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please., E Dodd, 2005/01/06