Re: OOP - a question about database access

From: Bob Badour <bbadour_at_golden.net>
Date: Thu, 6 Nov 2003 09:42:45 -0500
Message-ID: <rcudnSc1sLv3wzei4p2dnA_at_golden.net>


"Tak To" <takto_at_alum.mit.edu.-> wrote in message news:46idnclna_7LnzeiRVn-uA_at_comcast.com...
> Phlip wrote:
> Ph> Some managers cut everything up into features, sort them
> Ph> priority, and track how long each one takes to finish.
> Ph> Then they use this velocity metric to estimate how many
> Ph> features would be finished by a given time. This allows
> Ph> them to, eventually, put the most important 5 pounds of
> Ph> shit into the bag.
>
> "Tak To" <takto_at_alum.mit.edu.-> wrote
> TT> It seems to me that these managers have confused features with
> TT> tasks. Using the analogy of a building: these managers think
> TT> they can schedule construction by rooms, thereby ignoring
> TT> tasks such as pouring the foundation, laying down the pipes
> TT> and ducts and pulling the wires.
>
> Bob Badour wrote:
> BB> A foundation is a feature. Pipes are features. Ducts are features.
> BB> Wires are features. Some features are "must have" features and
> BB> some are not. Humanity got by without foundations, pipes, ducts
> BB> or wires for many millenia. Granted, dwellings without
> BB> foundations have quality, stability and durability issues, but
> BB> they are still used on every continent.
>
> I am not sure if you think my analogy is inapt, or you think there
> is no distinction between tasks and features.

There is a distinction between tasks and features. However, I find both the analogy and the conclusion inapt. Managers do not need to divide features into tasks; the tech staff working for the managers need to have this skill. You assumed that features are rooms and then the only "tasks" you mentioned amounted to "add a feature". Pulling wire is the equivalent of adding the wiring feature. Stripping a wire or fastening a conduit or connecting a box is a task.

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

The task is: Hire someone, a plumber, to add a feature, plumbing, which is a management task, and every manager has the requisite skill. The plumber has the requisite skill to break the plumbing feature into necessary tasks.

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

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

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

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

> TT> Translating featuers to tasks is often non-trivial. Most
> TT> managers lack the necessary skillset and that is often why
> TT> they become managers instead of architects or independent
> TT> consultants.
>
> BB> Every manager has the necessary skillset
>
> I am not sure why you assume that all managers are competent.

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

> BB> to ask their
> BB> technical people for a task breakdown. Some of the best tech
> BB> managers I have worked for have no tech background but know
> BB> how to build a trust relationship with their tech
> BB> staff.
>
> Perhaps we have a fundamental disagreement. I think it is
> the manager's job to map features to tasks and to assign tasks
> to team members.

I would never work for you, nor would I want to work for any manager who second guesses my decisions. The only task a manager really needs to map to a feature is: implement the feature.

> Note that this does not prevent each member
> from breaking down his task further.

Such as breaking down the feature into tasks.

> If a manager divides the
> tasks into too fine a granularity, then he is micro-managing.

I suggest that dividing it below the feature level constitutes micro-managing.

> OTOH, if a manager does not know what tasks are involved in
> implementing a task, then he in not qualified.

The only qualification a manager needs to know what tasks are involved is the qualification to ask. The action of asking the question will provide the necessary knowledge, and every manager has the requisite skill to ask a question.

> (A manager
> can of course consult experts occassionally, but if he has
> to ask every time, why hire him in the first place?)

Because he knows how to manage. Why else?

> There are situations in which features and tasks are almost
> always one to one so that a manager can just dole out
> features to be implemented. In such cases, the role of the
> manager is perhaps superfluous and can be eliminated.

I disagree. Managers must prioritize the features, negotiate timelines and budgets, hire resources, motivate and discipline employees, manage contacts with other groups and with higher management, delegate effectively, and generally keep things moving toward the goal. The tech staff who cannot break a feature into tasks are incompetent and superfluous, but the manager is not. Received on Thu Nov 06 2003 - 15:42:45 CET

Original text of this message