[interfacekit] Re: Fwd: Re[2]: Wanting to work on the App/Interface Kit

Wow, I just re-read this message this morning and it sounds *far* more
harsh than I ever intended it to.  Stepan, if creating a UML tool is how
you want to contribute to OpenBeOS right now, then go for it.  I
sincerely hope I didn't manage to offend you.

I gotta stop sending email after 1:00am; I'm too far gone by that point.
=P

e

Erik Jakowatz wrote:
> 
> >I'm  not  scared  by  the process doc, although it is very rigorous. I
> >agree  with this kind of approach - system must be specified before it
> >is  coded.  And I also have a suggestion here: we need an tool to ease
> >the  process  of  specification - writing all specs manually is a hard
> >process. More than that, plain text specs may take too much time to be
> >read  and  understood.  I suggest writing a visual modeling tool, like
> >Rational  Rose,  and  using  UML  for  the  needs  of  specifying  and
> >documenting  of a system. UML is a perfect language for this puprose -
> >it is very understandable, and compact. Also it is very easy to learn,
> >in  case  you  (or anyone else) don't know this language. I've already
> >started  creating such tool for BeOS a few days ago, and I suppose the
> >first  working  version  to  be  ready in a couple of weeks (4-6). You
> >don't  have  to  wait  for  its  completion, but I think you should be
> >prepared for it.
> >
> >Stepan Stolyarov [stevebest@xxxxxxx]
> 
> Thoughts, guys?  Personally, I don't think we need a UML tool at this
> point -- most of our function specs and use cases will get pulled right
> out of the BeBook.  app_server is one place I might normally agree it
> would be useful, but I'm inclined to pass because I think 1) I'd rather
> not wait 4-6 weeks to start getting some app_server docs and 2) I'm
> sceptical that the tool can be written that quickly.  Or rather, a UML
> tool written that quickly is not going to be feature-full enough to be
> worth using.  Oh, and 3) I hardly know UML myself and don't have time to
> really get a grip on it right now.  Anybody else is in the same boat?
> 
> Otherwise, I like Stepan's enthusiasm for the process and doing design
> and architecture up front. =)
> 
> My $.02,
> 
> e
> 
> Data is not information, and information is not knowledge: knowledge is
> not understanding, and understanding is not wisdom.
>         - Philip Adams

Other related posts: