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

[Hilmar Berger]

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. Gnumed can't be everything to everyone. You have to decide 
what GnuMed should be. 
Nevertheless, I'm convinced that there *are* people in GnuMed that have a clear 
vision of what GnuMed should achieve. 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. Maybe it is already in the Wiki. 


> > 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'm quite convinced that GnuMed is complex enough to
> > need a specification.
> 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. 
 
> 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). 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). 
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. 

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. 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 - which might even save you time. 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. 
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. 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'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).

> 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. 

> 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. After all, you better talk before everything is ready if GnuMed-DE 
should have something in common with GnuMed-AU (or GnuMed-CA,...).

> > 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. 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. 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. 
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.

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. 

Hilmar



--