Re: OOP - a question about database access

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

TT.0> It seems to me that these managers have confused features with
TT.0> tasks.  Using the analogy of a building: these managers think
TT.0> they can schedule construction by rooms, thereby ignoring
TT.0> tasks  such as pouring the foundation, laying down the pipes
TT.0> and ducts and pulling the wires.

BB.1> A foundation is a feature. Pipes are features. Ducts are features.
BB.1> Wires are features. Some features are "must have" features and
BB.1> some are not. Humanity got by without foundations, pipes, ducts
BB.1> or wires for many millenia.  Granted, dwellings without
BB.1> foundations have quality, stability and durability issues, but
BB.1> they are still used on every continent.

BB.3> There is a distinction between tasks and features. However,
BB.3> I find both the analogy and the conclusion inapt. Managers do
BB.3> not need to divide features into tasks; the tech staff working
BB.3> for the managers need to have this skill.

This is _your_ point of view of what a manager should do, and this is exactly where we differ. I assume we are talking about a technical manager here and in my view (no doubt different from yours) a technical manager should manage technology -- i.e., the development of software. There are of course non-technology related tasks a manager does, such as what you have listed: negotiate timelines and budgets, hire resources, motivate and discipline employees, manage contacts. However, in my experience (which no doubt differs from yours), non-technical management tasks alone usually do not justify the expenses of a manager position -- at least at the typical manager-staff ratio that I have seen. In other words, I think many of the mid-level bean counters that I have seen who do not contribute technically are essentially superfluous.

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.

No, this was my analogy so I got to choose what constitutes features. Here _only_rooms_ are features and "wiring" is _not_ a feature. This reflects the common situation in which a customer wants to organize things in his perspective. You missed this point entirely.

And if your manager tries to talk the customer into accepting "wiring" as a feature, then your manager is doing exactly what I say he should do, namely translating features into tasks.

You can say my analogy as inept, but to critize it merely because it is different from your analogy (as you seem to be doing here) is rather pointless.

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

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

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

But plumbing is _not_ a feature in my analogy and my usage of the word "feature", which has been explained:

TT.2> A manager talks features with the customer, tasks with TT.2> his team.

Note that your team member may be a manager himself, in which case the task that you have assigned to him becomes a feature from his perspective. In other words, the plumber that you have contracted might actually be a plumbing contractor who assigns finer tasks to his team members.

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.

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

• -----

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.

I don't understand your question.

• -----

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.

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

• -----

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

I am not sure I would hire you. You don't seem to be willing to entertain the possibility of a difference of terminology (in "feature" and "task") but instead rather quickly conclude that I would be encroaching on your territory.

• -----

Tak

--
----------------------------------------------------------------------
Tak To                                            takto_at_alum.mit.eduxx
--------------------------------------------------------------------^^
  [taode takto ~{LU5B~}]      NB: trim the xx to get my real email addr