Re: OOP - a question about database access
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
But technical management requires knowledge and skills of both
management _and_ technology. (Again, my opinion.) I am skeptic
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 [...]
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 acceptingTT.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.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 managerBB.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 analogyBB.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 aBB.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 addrReceived on Sun Nov 09 2003 - 23:35:47 CET