Bob La Quey wrote: > On Jan 16, 2008 12:16 PM, James G. Sack (jim) <[EMAIL PROTECTED]> wrote: >> Bob La Quey wrote: >>> On Jan 16, 2008 9:03 AM, Darren New <[EMAIL PROTECTED]> wrote: >>>>> Definition is hard >>>>> to outsource depending as it does on the "customer" who often >>>>> must be worked with face to face. Implementation OTOH is >>>>> realtively easy to outsource if one has a good solid definition, >>>>> which is, of course, a _big_ if. >>> First I completely agree that your list does a good >>> job of defining the problem. I do _not_ think that >>> you avoid the probem by avoiding outsourcing. You >>> have these problems whether you outsource or not. >> The all-to-common situation is that some PHB says let's outsource, and >> nobody clues him/her in. Sometimes it gets all "arranged" by >> intermediaries who are equally clueless, and then some lowly techhead is >> told to "make it work". Almost invariably, it doesn't. >> >>> So let's take them one by one. >> <total snippage> >> >> >> Regards, >> ..jim > > I agree that lousy management is the rule not the exception. > It does not follow though that lousy management > will do any better a job with their own internal program > development. > > Plenty of systems get botched without outsourcing > the botch :;-(
Yes, indeed. And I did not intend to downplay the good remarks in my "snippage", either. Any non-trivial development project is painfully difficult and expensive and risky to do in a (disjoint) definition + implementation manner -- that is in the traditional waterfall approach. Breaking it up into pieces or phases (including your tall-thin idea) is the only way to go unless you have unlimited resources. Even with unlimited resources, a spiral development cycle instead of pure waterfall has major advantages -- a large part of which is such things as feedback, visibility, continuous reevaluation of goals and risks, .. The separation of definition from implementation has a cost. In the smaller environments that I have experience with, the requirements gatherers, architects, systems analysts, designers and implementers are within the same small group (for better or worse). Removing the tight coupling may break the effectiveness of such small groups. I can't speak from personal experience about larger development projects, but I'm inclined to believe that development benefits from applying modularity and decoupling almost the same as the software itself. I'd like to hear advice from people with large-project experience. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
