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

[Richard Terry]

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