Re: Just say no to threads [Was: Software architecture]

Andrew McDonagh <news@andrewcdonagh.f2s.com> wrote in message news:<cltr89$b95$1@news.freed
om2surf.net>...
> Debbie Craft wrote: 
>
> snipped
> 
>
> With Phlips and yours conversation in mind, lets say you are about to
> start on a project that has the need for persisting its object model.
>
> Would you :
>
> a) Go straight for RDBMS cause you have done it before.
> b) Use a flat file cause you have done it before.
> c) some other means cause you have done it before..

I would figure out the real need to be satisfied this iteration.  Then
I would write a test for it.  Then I would figure out how to pass that
test in the easiest way -- maybe use an RDBMS if I had one handy.
With the availability of MySQL, an RDBMS is always reasonably handy.
Ideally I would have some high-level persistence library handy, and
could just use that.

Generally, for me, "done it before" is not a good reason to write
code, although sometimes it can often be a good reason not to write
code.  I've worked with a bunch of "done it before" telecom engineers,
and mostly what that meant was that they were going to recapitulate
the same workarounds they needed when developing  for one-megahertz
CPUs with 4MB of RAM even though they were now developing for a 500MHz
CPUs with 1GB of RAM.

On Mon, 01 Nov 2004 17:37:41 GMT, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> wrote:
 
>do 
>
>Do such organizations currently exist? (I'm sure they existed in the past)
>Is there a method/methodology/procedure having such characteristics? (you
>are describing the lack of a methodolgy, an unintegrated collection of
>activities)

No. Pure waterfall is an example of a method that separates those
matters.

Any team with designated analysts, architects, or designers partakes
of that separate /to some degree/.

>Could you give an example?

Of what?

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
 news:9i1eo0167019eo6pi6tnpe1vjrbggja6fp@
4ax.com...
> On Mon, 01 Nov 2004 17:37:41 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
> 
doesn't 
past) 
>
> No. Pure waterfall is an example of a method that separates those
> matters.

Pure waterfall is an idea. As an ideal it separates the two, no doubt about
it. Now if you can only find me an organization that actually practices the
ideal. There are and will be interactions between the tasks in the
organizations that fail to achieve the ideal (pretty much all
organizations).

>
> Any team with designated analysts, architects, or designers partakes
> of that separate /to some degree/.
> 
>
> Of what?



Of an organization that actually has separated the tasks sufficiently well
so as to substanciate you claim

>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<n14co01itdoq3pgktnau0644mblt
jojvoa@4ax.com>...
>
> I would ask the COO ... This design decision reflects my understanding fro
m
> the COO ... My focus is on ... feedback from the COO... I could go to the COO > an
d say: OK, here's version one

What is a COO, Ron?

Daniel

On Wed, 03 Nov 2004 16:32:52 GMT, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> wrote:

>"Cristiano Sadun" <cristianoTAKEun@THIShotmailOUT.com> wrote in message
>news:Xns9596A57CE6662Sadun@212.45.188.38... 
>thinking. 
>
>I agree effort is required.
>
>The basic problem is the Ron contends that the communication never occurs,
>that the development artifacts are simply thrown over the wall, with the
>recipient being stuck with the situation. No doubt this can theoretically
>occur (neither Ron nor I can identify an example of where and when it has
>occured), but, and this is the issue of concern, when it occurs there is a
>pathological problem present within the organization. The pathology implies
>it doesn't matter what methodology is being used. The pathology itself
>impeeds the successful operation of the methodology.

That is not what I "contend". I am stating that separation of job
functions like "architect" or "analyst", and that focus on phases of
work such as analysis and design, which /do occur/ in many processes
on paper and in practice, //tend// to get in the way of communication.
I am further stating that the more integrated a team is, the better
communication can be. The end-point of that, where practical, is the
XP practice of "Whole Team", or "Sitting Together".
>
>This makes "throw it over the wall" a strawman. 
>
>I have always found meeting to be a big waste of time. You get 10 - 12
>people in a room, all reporting "progress" and problems, but nobody really
>understands enough (other then the project manager) to intuit things

This turns out not to match my experience, in situations where the
teams work together intimately anyway, and where there is a discipline
to the meeting. In other words, there are good ways to do it, which,
if you have /always/ found meeting to be a waste of time, you've
perhaps never experienced.
> 
>
>I consider this to be a serious problem, but it is not a methodology
>problem.

It is a serious problem. It can be induced, exacerbated, or mitigated
by matters that do come under the purview of methodology, such as
phases and specialist job positions.

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
 news:kmrio05ck068dl7mgb7qqpmosge65n1tfk@
4ax.com...
> On Wed, 03 Nov 2004 16:32:52 GMT, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> wrote:
> 
message 
as 
occurs, 
a 
implies 
>
> That is not what I "contend". I am stating that separation of job
> functions like "architect" or "analyst", and that focus on phases of
> work such as analysis and design, which /do occur/ in many processes
> on paper and in practice, //tend// to get in the way of communication.
> I am further stating that the more integrated a team is, the better
> communication can be. The end-point of that, where practical, is the
> XP practice of "Whole Team", or "Sitting Together".

There are a lot of things that //tend// to get in the way of communication.
Lack of a telephone, not knowing the telephone number of a person with who
you must speak, not knowing whom to speak with when a problem arises,
undocumented code, undocumented designs, unarticulated requirements, word of
mouth conveyed organization policies, changing requirements readily come to
mind. All in my opinion are greater impediments to communication than
bestowed titles such as architect or analyst.

In every organization there are formal and informal networks that exhert
power and influence on how things happen. Not being tapped into those
informal networks does make things difficult doesn't it?

See the book Power and Influence Beyond Formal Authority by John Kotter



 
etc. 
really 
>
> This turns out not to match my experience, in situations where the
> teams work together intimately anyway, and where there is a discipline
> to the meeting. In other words, there are good ways to do it, which,
> if you have /always/ found meeting to be a waste of time, you've
> perhaps never experienced.

Obviously we have had different experiences.  I have attended "good"
meetings, but they were still in my opinion a waste of time. The differing
characteristic probably is equivalent to your usage of the term discipline.
That is people prepared for the meeting rather than attended them. When a
"status" survey was conducted it was completed prior to the meeting by the
meeting leader and presented as a report (as such it was an integrated
perspected, rather than dribbled factoids).

Problem solving activities are a different issue. Sometime 3 - 5 people have
to be thrown into a room for purposes of that effort. Generally speaking
although "officially" a meeting their purpose by its very nature is ill
defined (most brainstorming)

 
intent, 
confrontation 
>
> It is a serious problem. It can be induced, exacerbated, or mitigated
> by matters that do come under the purview of methodology, such as
> phases and specialist job positions.

Trying to sneak one in eh Ron. How can you have phased and specialist job
positions without a methodology?

>
> Regards,
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.

Responding to Philip...

> But insofar as ordering everyone to occupy all roles, and so far as I
> decline to analyze X today, because I'm not into it, you can't call the
> roles "rolled into one."

I cant prove it to you why fixed roles are not ideal in IID. But I
can show you what industry experts think. It is up to you to disagree.
Iterative and incremental development as it exists today conforms to
one of the following
methodologies: XP, DSDM, SCRUM or FDD (ofcource there are lesser known
variants). In February 2001, a group of 17 process
experts from DSDM, XP, Scrum, FDD, and others interested in simple IID
methods and principles met in Utah. From this meeting came the Agile
Alliance (www.agilealliance.org). So all current methodologies for IDD
conform to "Agile
Methodologies" (http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf).
Agile supports a concept of developers who do everything from design
to development to testing. There may be some specialists but they are
there to help out the rest of the team. Check out the concept of
"Generalizing Specialists" [Scott Ambler] and why this is a good
practice at http://www.agilemodeling.com/essays...pecialists.htm.
Methodologies like XP try to spread knowledge through pairing. If you
dont like analysis you pair with an expert in that area.

linusj.

Cristiano Sadun <cristianoTAKEun@THIShotmailOUT.com> wrote in message news:<Xns9598601CE
EC1ESadun@212.45.188.38>...
> kevin.cline@gmail.com (Kevin Cline) wrote in
> news:e749549b.0411041838.6285a9@posting.google.com:
> 
>
> What do u mean?
> 
>
> Might be. I'm saying that per se pair programmig or code sharing does not
> necessarily guarantee the best solution. Bit like politics: you get to
> the solution with larger consensus - not necessarily the best.
>
> Minimalistic example: say one guy wants to use quicksort, but the others
> don't get it and stick to bubble. The guy gives in, and you'll have a
> less than optimal choice but with maximum consensus.
>
> Then, it's true that the best training is where both the teacher and the
> student do learn from the process. Still, this required an engaged pupil
> or is a waste of time for both.
> 
>
> Sure enough. The issue sometimes is way more the people than the process.
>
> I am merely point out that that holds for any process, comprised XP
> practices. So you never have "automatically" the best solution out of any
> process or practice, regardless how smart they are.
> 
>
> I'm perhaps a bit less optimistic than this. Not too much, tough. :)
> 
>
> Not at all. Take a problem X. I come with a solution S1, you come with a
> solution S2. Your solution is better - for some appropriate definition of
> "good" (say it performs exponentially better). I still have come out with
> the best I can do, that is, S1 (in other words, I might have had some
> solution S0 worse than S1) - but there is a solution which is better,
> when all the possible known solutions (that is, yours and mine) are taken
> into consideration - S2.
>
> So "better" referred to all the accepted solutions within a team (or
> person) is quite a different thing than "better" referred to all the
> accepted solutions within a set of teams (or  people).
> 
>
> True. I do like the practice. Just, I woudn't like having it presented as
> a silver bullet.

It's not a silver bullet.  It's more like an anti-silver bullet.
That's what I liked when I read "Extreme Programming Explained" the
first time.  XP says to express the requirements as executable tests,
so you'll know when they are satisfied.  No magic there.  XP says that
you should test before coding, so that you'll know what to do, will
know when you are done, and will know when something gets broken, and
how it got broker.   No magic there.

I contrast this with other methodologies, which give at least some
managers the idea that if they get the requirements and design
documents just so, then coding will be like laying bricks, and can be
done equally well by anyone with the right diploma or certification.
That would be pretty magical, if you could somehow hire minimally
skilled labor to follow an untested design and convert an imprecise
requirements specification into bug-free executable code that would
perfectly meet the customer's needs.

One of my favorite Dilbert cartoons shows a consultant at a conference
table saying something like "You would be a fool to proceed without at
least investigating all known key facets, and creating a holistic plan
covering all the key areas".  Then Dogbert jumps on the table, shows
the consultant a program listing and says, "Look!  Actual code!"  Then
the consultant melts like the wicked witch of the east.