corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: "I'd Really Like This Done By Friday"
Date Fri, 13 Feb 2015 10:46:44 GMT
On 13 February 2015 at 11:33, Peter Kelly <pmkelly@apache.org> wrote:

> > On 13 Feb 2015, at 4:14 pm, Dennis E. Hamilton <dennis.hamilton@acm.org>
> wrote:
> >
> > There is a great lessons-learned article at
> > <
> http://jasonpunyon.com/blog/2015/02/12/providence-failure-is-always-an-option/
> >.
> >
> > Joel Spolski, whose company supports Stack Exchange, made this comment
> in his twitter message about it:
> >
> > "Now you know why experienced developers are really conservative about
> technology choices."
> >
> > My reason for remarking on this, beside it being a great story, is the
> "I'd Really Like This Done By Friday"  topic on the very end.  I notice
> that we do not seem to have very many places in Corinthia, right now, where
> such prospects for agile baby-steps stand out.  (The request to make
> Windows Native scripts for the externals downloads and extractions is the
> closest I've seen that I could act on that way.)
>
> Anyone can start writing a filter today, without immediate concern as to
> ensuring it fits within an a particular architectural structure. It doesn’t
> even need to use any of the functions in the library - if the algorithms
> are in place, they can be subsequently integrated into the main codebase.
>
> Here’s a couple of other quotes from the article:
>
> "Bad planning, bad tech decisions, and a propensity for sinking weeks on
> things only incidental to the problem all adds up to
> excruciatingly…slow…failure.”
>
> "We dropped back to the simplest system we could think of that would get
> us going" ... "Within two weeks we had real-world tests going and we got
> incredibly lucky. Results of the model tests were nearly universally
> positive.”
>
> My takeaway from this is that it’s a bad idea to obsess too much over
> architecture, build processes, and getting a perfect underlying structure
> before starting on feature work that matters to end users. I think this an
> extremely valuable lesson.
>
+1 these structures should be created from practical needs.

>
> > I am thinking that moving Corinthia to Apache might have been a bit
> premature with regard to the state of the code base and the degree to which
> the super-programmer has ideas about how it is to become different.
> Agreed, Corinthia is a podling.  However, it seems me that the reason for
> being an Incubator project is not so much about the status of the code, it
> is more about a place to transform to a project and process that evolves
> toward some level of *sustainable* maturity.  Currently, there is a lot of
> moving target and it depends on the super-programmer as benevolent dictator
> at this point.
>
> Well, I don’t want to be a benevolent dictator. Sure, I have a lot of
> ideas for the project - as do others - that I’d like to see come to
> fruition some day. But my ideas shouldn’t carry any more weight than anyone
> else’s. Jan is another person who has lots of ideas and has done
> significant work on improving the architecture (prior to his involvement
> there was no clean separation of concerns in the codebase), and I
> anticipate further improvements in this area.
>
> But I disagree that this means it was too early to move into incubator, or
> that it’s too early for people to start working on whatever they are
> interested in the project. As I mentioned previously, if we wait for a
> stable base then nothing will ever get done, because the base is something
> will evolve to meet our needs as a team, and that’s only something that can
> be done with involvement from all of us, working together.
>
I agree with Peter, one of the main reasons to be in incubator is to grow
our community.

You do not need to be a super programmer to do things with Corinthia
- you could easy add the getopt-long option we have in jira.
- you could easy get the editor working within e.g. firefox
and more

Writing a filter as peter suggest is also doable, but is clearly a bigger
task. Please remember had we waited to enter incubator until corinthia was
mature, you would not have much chance of influencing it, but had to accept
everything as it was defined.

I see the state of the code, as one of the biggest advantages for
corinthia, because new programmers really have a chance to influence the
outcome.


> My “out-there" ideas about a generic parser library, the statically typed,
> functional programming language for implementing language transformations,
> the implementations of filters in that language as opposed to C, formal
> verification of transformation algorithms etc are all just stuff I’ve been
> thinking about. The last thing I want is for these or any other suggestions
> I’ve made to be seen as reasons for delaying beginning of coding work on
> stuff like ODF.
>
> > With regard to exhortations to start doing something, I just stumbled on
> the quotation at the beginning of Mythical Man Month Chapter 6, Passing the
> Word.
> >
> >   He'll sit here and he'll say, "Do this! Do that!"
> >   And nothing will happen.
>
> There was a bug report someone filed about requesting a roadmap. I was
> waiting for someone else to fill one in, but after a few weeks of nothing
> happening on that front I came along with my comments about ODF (which I
> assume you’re referring to). My suggestion really comes down to the notion
> that we should be focusing on new features or major improvements.
>
+1

>
> I’m well aware of the difficulties caused by lack of proper documentation
> - which I’m continually trying to find time to get around to. I have to
> juggle this with paying work though which is keeping me quite busy right
> now. However, I’d love to answer questions about “How does thing X work?”,
> “Why did you do Y this way?” etc. as I think this would help people along
> and also be a good indication of the most important priorities for
> documentation.
>
Actually it is not as bad as it seems, a couple of evening looking at the
OOXML filter, and a lot of the core was pretty logical (not that I agree
with the way it was done though).

Compare corinthia to e.g. AOO (which Dennis knows better), that code is
also not documented, but are millions lines of code, and still people
contribute.

In my opinion, the new filter interface is much more important, than to
constantly think about documentation. Whatever documentation you come up
with, there will always be someone that tells you it is too little and not
what they need....baseline is that developers need to take a look at the
code.

just my opinion
rgds
jan i.


>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message