Re: OOP - a question about database access

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.

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.

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.

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. A manager talks features with the customer, tasks with his team. There is no fixed relation between features and tasks: a feature may requires several tasks, or a task can implement 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.

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

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. Note that this does not prevent each member from breaking down his task further. If a manager divides the tasks into too fine a granularity, then he is micro-managing. OTOH, if a manager does not know what tasks are involved in implementing a task, then he in not qualified. (A manager can of course consult experts occassionally, but if he has to ask every time, why hire him in the first place?)

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.

Tak

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