[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: get something done
Re: [Gnumed-devel] Re: get something done
Thu, 1 Dec 2005 22:21:17 +0100
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
> 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
> I suspect there is even more than one vision
> available at request :).
> 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
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
> 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.
> 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
> - 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.
> > 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
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
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
> > > 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
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.
Leipzig / Germany
[www.openmed.org] -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86 -> No files, no URL's
My OS: Suse Linux. Geek by Nature, Linux by Choice