[prog] State of software engineering profession

[Jenn Vesperman]

On Tue, 2003-04-15 at 20:18, Jimen Ching wrote:
> On Mon, 15 Apr 2003, Jenn Vesperman wrote:

> I
> guess because you equate implementation and design, the patch would be the
> same as the plan.  So there are two layers of disagreement here.  I don't
> think it is worth discussing the second disagreement, when the first one
> is actually more fundamental.

Well, you've totally misunderstood me. I do not equate implementation
with design in its industry specific meaning.

Implementation of software is a design process, in the broadest sense of
the word 'design'. Not in the industry-specific sense.

Design of software is a narrower definition of the word 'design', and
means (very, very roughly, don't hold me to this definition) 'to have a
structure within which to develop the finer grades of detail'.

I do not believe you can use assembly line methods to produce software
because, by its nature, the process of creating software is inherently
one of design (broadest sense of the word).

I firmly believe that software should be designed (narrower,
industry-specific sense of the word) before being implemented (by
designing the details, and providing that design spec to the compiler,
which automates the process of converting from the design language to
machine code).

Does that clarify? I honestly think we agree on this point, you're just
misinterpreting me.

In fact, earlier in your letter you said:

> I agree that there are design elements in implementation.  But I
> differentiate between a design step and an implementation step in the
> development of a software application.  Basically, there are different
> levels of design.

.... which is basically what I just said now. We agree. You just haven't
understood what I was saying.

> >'show us the code' means 'produce something, and we'll listen'. That can
> >be a well-thought-through design.
> 
> I don't think so.  At least not in the free/open source software world.
> "Show us the code" usually means send in a patch.  The word 'code' has a
> very specific meaning in this world.  Of course, whether a 'plan' is
> needed depends on the feature being added.  If the feature is simple, the
> plan could be as easy as asking 'would this feature be useful?' But with
> more complex features, or features that might change entire sub-systems,
> then a more well thought-out plan is in order.
> 
> By asking for patches, these people are saying they don't want to discuss
> the 'plan'.  They just want an implementation and review it instead. 

Strongly disagree.

'show us the code' means 'ok, your patch concept is within the scope for
this program, can you actually do it and do you code well? Have you
thought of how it will interact with existing material? Are you capable
of writing test cases? Are you even capable of reading the documentation
we've provided for programmers who want to contribute?'

If the answers to all of those are 'no', then there's no point in the
person contributing a patch unless there's someone already in the
project willing to train them up.

I've sat on project mailing lists, and watched people suggest features
and be told 'yes, that'd be nice, but we'd have to redesign (subsystem)
from the ground up to do that - if you really want it, you could fork
the project'.

I've sat on project mailing lists, and watched people suggest features
and be told 'that's out of scope for this, THIS project is about
achieving task foo, that feature is about achieving task bar. Why not
use the integration hook baz that we provided, and make a complementary
tool?'


So I strongly disagree with your interpretation of 'show us the code'.


I also strongly disagree with your premise that open source programmers
don't have a design or plan in mind.



Jenn V.
-- 
    "Do you ever wonder if there's a whole section of geek culture 
        	you miss out on by being a geek?" - Dancer.
   My book 'Essential CVS': published by O'Reilly in June 2003.
jenn at anthill.echidna.id.au     http://anthill.echidna.id.au/~jenn/