Re: [Gnumed-devel] Re: get something done

[Sebastian Hilbert]

Hi Hilmar,

short version : good points worth to discuss, made me think

On Thursday 01 December 2005 20:59, Hilmar Berger wrote:
> On Wed, 30 Nov 2005 13:14:12 +0100
>
> Sebastian Hilbert <address@hidden> wrote:
> > From my point of view there is no project official vision. I live here
> > and now. My day has 24h. I know what you mean. A project needs a vision
> > for other people to be attractive. I know what you mean. Endless thinking
> > has been put into this by me and Karsten. One day I simply had a choice
> > to make. ...
>
> This sounds somewhat like you would have to decide either for thinking
> about what the vision for gnumed is or to do other important things (PR,
> packaging, etc.). I strongly believe that a project without a well-thought
> project goal (=vision) is not able to achieve anything. Nor does it make
> sense to invest in PR for such an project.
Hmm, Many readers will applaud you. Maybe you all share a common vision.
I don't. Short version. I do PR for what is there already. 

> Gnumed can't be everything to 
> everyone.
True.
> You have to decide what GnuMed should be.
I wish it could everything for me. I see that it can do a few things for me 
right now. Regarding scalability. No hospitals. Period. My point of view.
> Nevertheless, I'm  
> convinced that there *are* people in GnuMed that have a clear vision of
> what GnuMed should achieve.
E-Mail them to the list or me. If you can be as structured and detailed as you 
can. Send it in by chapters if you want. I would love to read it in a 
compressed form.

> I suspect there is even more than one vision 
> available at request :).
You bet.

> All we have to do is to write it down, print it 
> out and put it above our monitors.
Good idea. I started with my vision a year or so ago, failed and gave up. I 
challenge all readers to perform better. For the sake of GNUmed.

> Maybe it is already in the Wiki. 
Maybe. We can put it there once it's back up. I will create a page vision or 
something and add names or each individual linking to the individual's 
vision. Start writing now if you can so we have something ready when the wiki 
comes back to life.
>
> > > Over the last years I learned that large and complex projects without a
> > > final specification *before* starting to work will either have
> > > difficulties or fail completely.
I hear you. 

> > > I'm quite convinced that GnuMed is 
> > > complex enough to need a specification.
Many people seem to think that way.

> >
> > We have specs. Just no active mainatainers and no active lobbyists.
> > Richard's GUI specs have been there for ages but never revised. I mean
> > they represent what he knows is best for him but noone took the liberty
> > to follow up the endless discussions we had on it and revised thos specs.
>
> True. There are specs, but we never took time to get a revision everybody
> could live with. Which is sad, because this eventually means that all good
> points which were raised in discussion will be buried in tons of mails.
This is really sad. Let's form a team of volunteers to extract this 
information. Jim has done a great jon but cannot do it all alone. I will go 
back and try to extract everything that has been said on lab specs and 
archive specs. 

I challenge everyone else to pick a task.
>
> > What other specs you need ? We don't have any specs before we code
> > individual plugins. True. But I am not going to write up specs for
> > GNUmed/Archive because this project is so self contained that one person
> > working on it is sufficient. If I start writing up missing specs for yet
> > to be defined modules who is going to code the GNUmed/Archive. See the
> > catch ? I am not arguing against specs. It's just not me who is going to
> > write them.
>
> I suspect that you believe that you can do the second well without the
> first (i.e. code without specs).
I seem to believe this. I have no formal CS training and very little 
experience.

> Let me explain why I believe that this is 
> an misconception. Specs are basically (at least to me) nothing but your
> ideas put into words and written down. If you start coding, you usually
> have a clear idea of what you are going to do. If not, you will probably
> have to change your code again and again until you found out what your goal
> really is (please note that I'm talking about recoding because of unclear
> goals, not technical improvements and bug-fixes).
Doesn't happen very often. I know the specs. I don't write them down.
I always thought specs are there so someone else can follow them and code. I 
always thought that once I am done with a plugin it does what I need so I 
don't need to write down specs. 
> This idea usually 
> consists of two parts: requirements and an idea of how you would like to
> realize them (say, how the user interface should look like). The latter
> part is usually called design. So even for more or less self contained
> projects that can be done by one single person will have specs, you just
> don't write them down.
That's what I do.
>
> Now why would one want to 'waste' time with putting down specs ? Well, I
> see the following benefits: 1. The process of writing something down helps
> you see clearly what you are going to do and to identify possible problems
> in your design or requirements you might have forgotten before.
True.
> One rule of 
> thumb is that if you have difficulties writing requirements and design
> down, this usually means that you still have no thourough understanding of
> what you are going to do. Think of building a house: before moving the
> first brick you usually make at least a sketch of what rooms/space you
> need. 2. Written specs help you and others talk about the part of software
> you are writing.
True if more than one person is working on the same thing which does not 
happen with GNUmed. That's why I am a fan of defining small projects.

> Imagine I would ask you to tell me what your Archive 
> Module is supposed to do and what it will look like. Instead of writing
> lengthy emails you could just point to the specs
True. Interesting. I will have to decide if I want to invest the time to write 
it down. 
> - which might even save 
> you time.
Not really. Description of it is in the Wiki . I once issued a call for all 
developers to document what they have coded in the Wiki. Prove me wrong but 
the call wasn't answered the way I would have liked. Seems like we all have 
certian ideas what needs to be done but don't do it. If i want I can find 
explanations all day long.
> Since your Archive Module will be used in the context of GnuMed, 
> it will help others to understand better which functionality will provided
> by your module. This will especially help newbies that still do not know
> how the modules relate to each other.
Worth thinking about. Maybe *I* should put action where my mouth is and 
document my code the way it should be. It'd be interesting to see how many 
people will follow. By the way Hilmar, you have some code in there as well.
Maybe we should bo the set an example. What do you think ? 
> 3. It helps you defining what state 
> you have reached, what will be the next steps and future plans. Instead of
> everybody having his own ToDo-List, you can add you on requiremenrts, ideas
> and request by others to your specs.
Sounds fair.
>
> > We are no company. Show me one successful project which has detailed
> > specs out.
>
> If people that have to earn money by writing software use specs they can't
> be so bad an idea to increase efficiency of software creation. The level of
> detail you use should be adapted to the needs and available ressources of
> the project team. GnuMed will probably not need an industry-strength
> development process.
Au contraire. It needs industry strength development process plus an 
experienced lead who acts like a dictator. 
> But writing specs for a module you can develop on your 
> own shouldn't take much more than one our (given you really knwon what you
> want). Discussing it may take some time if there are others involved, but
> specs help a lot once they are finished.
>
> > > I'm sure Karsten knows exactly how he wants to build
> > > GnuMed (as knows Ian, as knows Richard, ...), however, I believe we
> > > would be able to get more collaborators if we could only show a
> > > well-thought plan what milestones we want to achieve next.
> >
> > Don't be disappointed about what I am going to say now. You are wrong. I
> > once thought like you. One day I stopped. Right or Wrong. That's what
> > happened. There is no magical vision for GNUmed as far as *I know*
>
> IMHO there is a vision (see above). Something you can put in two-three
> phrases.
I still cannot see the vision. What I can see is a vision of how parts of 
GNUmed should look like. That's what I would call specs.

> I'm sure Karsten can tell us his vision instantly. Maybe there is 
> no detailed roadmap (another point that can be get easier to define once
> you have specs at least for some further milestones).
There is a roadmap :-)
>
> > For Germany GNUmed will be code plugin by plugin. Order of completion
> > depending entirely on what code is there already plus real use cases
> > 0.1 - structured medical documentation
> > 0.2 - GNUmed Archive - getting paper into digital form
> > 0.3 - lab module - Jim's use case.
> >
> > See a pattern here ?
>
> I don't see a problem if modules are done one by another. Just that I would
> like to see specs for every module that gets coded.
I will write those for my modules. It will slow down GNUmed even more than it 
does now but that's what most people on this list seem to want. I consider 
this as an experiment. if it doesn't work i can always go back to the *bad 
style* of developement.
>
> > For Australia it has been pointed out that GNUmed is all or nothing which
> > is not coding to happen with German coders. We will *support* efforts
> > made by Australian doctors best we can *but* not more.
>
> So if you have to accomodate different needs it's even better to have specs
> ready.
I don't have to. I do because I consider this a good idea. In this context 
specs make sense I guess.
> After all, you better talk before everything is ready if GnuMed-DE 
> should have something in common with GnuMed-AU (or GnuMed-CA,...).
Well. 1st there is no ready. 2nd. If you follow Karsten's style of coding and 
planning you will notice that he practically enforces what you want. But this 
has led to numerous discussions about him not letting anyone touch the GNUmed 
database schema. Plus every now and then someone complains about the snail 
like process. Hell we could speed it but by 2 or 3 , leading to a complete 
rewrite ( in case it will ever happen) Why do you think a lot of commercial 
software sucks at a level you cannot see ( code that is ). I have seen it.
They were fast alright. They earn money with it. That is not going to happen 
with GNUmed. 
>
> > > I therefore suggest that at least some energy should be spent in
> > > documenting and discussing our plans for the nearer future.
> >
> > I once had that dream as well. Karsten never talked me out of it. But he
> > showed me that his way of doing things led to more usable results. I am
> > converted. I still have that dream. Maybe I can help *you* start.
>
> Karsten's way of doing things is a hard one. Basically because there was
> nobody else colloborating he decided to do it his way and implements what
> he needs most.
IMHO the only sane choice. Nonone has managed to prove him wrong. There was 
your opportunity to beat GNUmed to a working version. Horst has managed to do 
so in record time. But is his code deployable, documented, stable. No 
comment. Let's just ask Horst because he is about the only one how might be 
able to compare GNUmed to his software.

> Which is ok if you want to continue alone. But every day 
> without Karsten sharing his ideas (say, specs) with the rest of the world
> there is less a chance to get other people to work on GnuMed.
This seems to be a convenient and common mispercption. What exactly keeps you 
from doing exactly what Karsten has failed to do ? None expects you to add 
missing documentation in a week. One thing people tend to forget in today 
fast paced life is the fact that GNUmed has been and is an ongoing project.
You say you will need two years to add the missing documentation because we 
failed to it right from the start. Fine. Start right now. I will be around in 
two years as well.
> Even if you 
> reach a revision where basic things work for Germany you can't expect
> others to join the project if you can't tell them how GnuMed works and what
> is the idea behind it.
I can. That's the beauty of it. Another misperception. Users are not stupid. 
You'd be surprised how many people you can actually reach during a 
LinuxWorldExpo or a LinuxTag. 
> Karsten, I'm not criticizing you here, I know you 
> are willing to share your knowledge if only somebody else cares to write it
> down.
Same goes for me. I do notice the irony here. Me being reluctant to write 
anything down while complaining that noone else (actually no true) writes 
code or documentation.
>
> I already offered to start working on specs some time ago. I'm still
> willing to do so, as far as my limited spare time allows.
Suggest a process and follow up on it. Some ideas come to my mind.
1st) document you own stuff
2nd) interview Karsten, Carlos, Ian , Richard, Horst, Liz, Jim, Syan ( yes I 
forgot people). Come up with questions and publish the interview as specs. 
Sounds like a plan for a start.

Meanwhile I will shut up and go documenting some stuff.
>
Sebastian

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice