I think it is well understood the weaknesses of task-based software development processes - hence the popularity of agile frameworks. Telling a programmer to code a small little piece of a large framework out of context is error-prone, slow, and most importantly a difficult way to keep talent. Give me a piece of a system and say "work with teams A, B and C to make D" is entirely different than saying "Do tasks X, Y and Z" without any basis for them. Good managers want the input of the expert paid to do the job - even if that expert is a 21 year old pimply-faced programmer punk. Sure, I might have more overall smarts and education than my mechanic - but when he's elbow deep in grease with my car taken apart I'm not going to give him tasks, just a goal: make it work. Anything more is micromanaging and gives substandard results (since I'm not an expert but he is) -- that doesn't mean I can't keep an eye out on him from dumping metal shavings into my oil-pan.
Micro-managers give "tasks"; Good managers give "goals".
It may sound like a mere semantic difference, but there is some real value in conceptualizing the distinction. Shortly, a task is a step toward reaching a goal. Sadly, there are people who cannot tell the difference. If you have one, or are one, my condolences. Some good things about goal-based over task-based management:
- Easier on the manager (my favorite reason). If a manager has to take a collection of goals from higher-ups or customers (the ultimate higher-ups) and distill them into tasks, that puts a great strain on the manager. (S)he becomes a point of failure in the organization, since all new goals must travel through that point. However, when a manager spends time giving out goals rather than managing tasks, (s)he can spend the time ensuring that the goals are reached satisfactorily.
- Gives a sense of ownership to employees. Great for morale, sure, but also keeps talent around. Smart people don't like feeling like cogs, and almost always prefer to have a stake in the outcome. When given a goal "get project A done in two weeks - by any means necessary" rather than a series of tasks "come in between 8am and 5pm; 3 days of design, 4 days of coding, 3 days of testing; utilize technology X" they are more likely to care about the outcome - it becomes their baby.
Are these benefits psychological? Sure. Companies are groups of people working toward a common set of goals - psychology is an important organizational component. But it has another bonus beyond the sanity of employees: goal-based directives are developed faster. My feelings on fast initial development are no secret, mainly because most projects have such short lives (if any at all) building "perfect" architectures are sinkholes of money and time. Complex top-down architecture (as opposed to emergent) take a high-minded view of an oligarchy which are suited for dividing labor into discreet tasks: create a caching mechanism, create a logging framework, create the model layer, create the DAO layer, etc. Oftentimes (I'll go as far as say usually, in my experience) these tasks are divided up to several people. Can you spot the vicious waste? If person A is working on component 1a, and person B is working on 1b you have now succeeded in failing in two ways:
- If person A quits, person B can hardly take on 1a without a learning curve. Perfect interchangeability of programmers is a pipedream - you have gained nothing by way of componentizing the org chart.
- Person A and B must cross artificial barriers to communicate (viz, between 1a and 1b). If person A and B were given a goal (work on component 1) they could leverage each others strengths, as well as cooperate in a manner comfortable to themselves to avoid redundancy. But as it stands, A will work on 1a, B will work on 1b, and any common effort not outlined by the oligarchy will be duplicated (1ax and 1bx - versus 1x).
Proponents of the top-down, task-based method will argue: "Iterations fix this problem!" True, after the effort has been expended once, retrospect will come into play and fix the original faulty analysis. But why go through the effort? Just let A and B loose to develop 1, fixing any architectural defects on later iterations. A simple shift in tact frees up a manager to work with the employees by removing obstacles rather than managing a check-list. Either that or going golfing.