Re: OOP - a question about database access

From: Tak To <takto_at_alum.mit.edu.->
Date: Sun, 09 Nov 2003 17:35:47 -0500
Message-ID: <o_OdnfHvYs4XXTOiRVn-jg_at_comcast.com>


"Tak To" <takto_at_alum.mit.edu.-> wrote

BB.5> Management is management. Selling is selling. They require
BB.5> different skills from engineering and from building. I have
BB.5> direct experience with excellent technology managers [...]

But technical management requires knowledge and skills of both management _and_ technology. (Again, my opinion.) I am skeptic of context free "management skills" in general.

BB.5> You may never have experienced what I have experienced, but my BB.5> experience contradicts and invalidates your assertion.

Your experiment is different from mine so your conclusion is different from (or "contradicts") mine, fair enough. However, I don't see how your experience can "invalidate" my conclusion.

BB.5> Since your only support for your assertion amounts to
BB.5> claiming ignorance of any contradictory information, the
BB.5> support for your assertion is inadequate.

I voiced an _opinion_; but if you claimed it is an "assertion" I am not going to quibble. Just bear in mind that your "assertion" (so far) is just as inadequately supported as mine.

  • -----
BB.3> You assumed that features are rooms and then the only "tasks"
BB.3> you mentioned amounted to "add a feature".  Pulling wire is
BB.3> the equivalent of adding the wiring feature.

TT.4> No, this was my analogy so I got to choose what constitutes
TT.4> features.  Here _only_rooms_ are features and "wiring" is
TT.4> _not_ a feature.  This reflects the common situation in
TT.4> which a customer wants to organize things in his perspective.
TT.4> You missed this point entirely.
TT.4>
TT.4> And if your manager tries to talk the customer into accepting
TT.4> "wiring" as a feature, then your manager is doing exactly what TT.4> I say he should do, namely translating features into tasks.
BB.5> And I got to decide whether the analogy is apt. The analogy
BB.5> is inapt for the reasons I stated previously. Claiming that
BB.5> plumbing is a task and not a feature does not change reality.

The purpose of my analogy is to illustrate the disparity between a customer's perspective (of how things should be organized) from that of management. To this end my analogy is apt because it shows the difference clearly. It appears that you have misunderstood the purpose of the analogy. (In another message of you implied that the purpose of myanalogy was to illustrate the importance of sequencing tasks/features -- an obvious misunderstanding  that is shared by you and Uncle Bob.)

Are you claiming that however the customer organizes features they are suitable for management purpose? So if a customer insists on using rooms as units the manager should talk to his team member in terms of rooms?

  • -----

BB.3> Stripping a wire or fastening a conduit or connecting a BB.3> box is a task.

TT.4> It is a task, but not necessarily at the right granular TT.4> level to be assigned to a team member.

BB.5> You are joking, right? If not an electrician, who will
BB.5> strip the wire? Who will fasten the conduit? Who will
BB.5> connect the box? Who will pull the wire for that matter?

I am not joking and I don't understand your objection. To answer your question: it is an electrician; but I fail to see any contradiction between that and what I have said.

  • -----

BB.5> Are you suggesting that 'add a room' is an appropriate task BB.5> to assign to a team member?

No I am not; and if you have spent any time reading my posts you would have got that. Once again, what I am suggesting is that the manager should translate "building a set of rooms" into specific tasks, which btw is exactly what you say a manager should _not_ do.

BB.5> Will all of your team members have the following trades?
BB.5> Carpentry, plumbing, electrical, drywalling, plastering,
BB.5> painting, flooring, interior decoration?

This question appears to be entirely irrelevant to what I have been saying.

  • -----
TT.2> So let me try again.  Contracting a plumber to do the water
TT.2> pipes as well as the wiring conduits is a task, not a
TT.2> feature.

BB.3> The task is: Hire someone, a plumber, to add a feature,
BB.3> plumbing, which is a management task, and every manager
BB.3> has the requisite skill. The plumber has the requisite BB.3> skill to break the plumbing feature into necessary tasks.
TT.4> But plumbing is _not_ a feature in my analogy and my usage of
TT.4> the word "feature", which has been explained:
TT.4>
TT.4> TT.2> A manager talks features with the customer, tasks with
TT.4> TT.2> his team.

BB.5> It is a feature regardless whether you call it one. If you
BB.5> insist that it must not be a feature for the sake of your
BB.5> analogy, then your analogy is inapt. Basically, your analogy
BB.5> is nothing more than a straw man, and I do not find it at BB.5> all convincing.

Once again it shows that you have misunderstood the purpose of the analogy. Try reading the earlier part of this post again. Note that you are attacking the "if" part of a conditional statement rather than the logic or the conclusion.

This analogy is not a strawman because this kind of disparity happens _very_often_. In my experience it is the norm rather than the exception.

  • -----
TT.4> [The definition of feature and task are:]
TT.4>
TT.4> TT.2> A manager talks features with the customer, tasks with
TT.4> TT.2> his team.
TT.4>
TT.4> Note that your team member may be a manager himself, in which
TT.4> case the task that you have assigned to him becomes a feature
TT.4> from his perspective.  In other words, the plumber that you
TT.4> have contracted might actually be a plumbing contractor
TT.4> who assigns finer tasks to his team members.

BB.5> Sometimes multiple programmers collaborate on a feature. BB.5> So? Do you have a point?

My point was to explain my definition (usage) of "feature" and "task" further in the hope of alerting you that perhaps our usages were different. Obviously my effort was wasted.

  • -----
BB.3> I disagree that it is necessary for a manager to talk
BB.3> tasks with his or her team provided the tech staff have
BB.3> the requisite skill to translate tasks completed into an
BB.3> accurate fraction of the feature.

TT.4> You completely miss my point that a customer may not want TT.4> to organize things in the way you want them organized.

BB.5> You completely miss every point I make,

No I have not. I just disagree with it. (And you are still missing my point.)

BB.5> and I did not say
BB.5> anywhere that anyone must force the customer to anything
BB.5> the customer does not want to do.

And I have never implied that you have said so.

  • -----
TT.2> There is no fixed relation between features and tasks:
TT.2> a feature may requires several tasks, or a task can
TT.2> implement several features.

BB.3> I find the latter assertion questionable. What sort of BB.3> task implements several features?

TT.4> I don't understand your question.

BB.5> In other words, no task can implement several features, BB.5> and you find it inconvenient to admit the fact.

How does one answer a question like "what sort of set has more than one member other than "those sets characterized by having more than one member"?

  • -----
TT.0> Translating featuers to tasks is often non-trivial.  Most
TT.0> managers lack the necessary skillset and that is often why
TT.0> they become managers instead of architects or independent
TT.0> consultants.

BB.1> Every manager has the necessary skillset to ask [...]

TT.2> I am not sure why you assume that all managers are competent.

BB.3> I assume only the competence to ask a question. Is that BB.3> too much?

TT.4> Yes (I think you are assuming too much) based on my experience.

BB.5> Your experience is not worth much if you can only draw conclusions
BB.5> from what you have never experienced, and your lack of an experience
BB.5> cannot invalidate my experience of an event or of a fact.

Gee thanks, I have been meaning to say the same to you too. See below.

BB.5> My positive experience of an event or of a fact can and does BB.5> invalidate any assertion you make on the basis of ignorance.

Only if my "assertion" has universality. Note that it is you, not me, who uses a universal qualifier in your statement. Specically, you claimed "every manager...". Thus, any one of my (numerous) encounters with incompetent managers would invalidate your claim.

BB.5> I find it quite a stretch (far beyond credibility, in fact) BB.5> to claim that all managers lack the skill to ask a question.

Once again I have never claimed "all..." -- it is you who claimed "every...".

Btw I think this shows clearly that you haven't really read my posts, or re-read your own.

  • -----
TT.2> Perhaps we have a fundamental disagreement.  I think it is
TT.2> the manager's job to map features to tasks and to assign tasks
TT.2> to team members.

BB.3> I would never work for you, nor would I want to work for any
BB.3> manager who second guesses my decisions. The only task a
BB.3> manager really needs to map to a feature is: implement the BB.3> feature.
TT.4> I am not sure I would hire you.  You don't seem to be willing
TT.4> to entertain the possibility of a difference of terminology
TT.4> (in "feature" and "task") but instead rather quickly conclude
TT.4> that I would be encroaching on your territory.

BB.5> Good. You will get what you deserve instead.

Amen. I surely hope to get what I deserve; and I certainly don't deserve you.

Tak

--
----------------------------------------------------------------------
Tak To                                            takto_at_alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr
Received on Sun Nov 09 2003 - 23:35:47 CET

Original text of this message