> > Clearly, large software projects can be daunting, and clearly it is not > enough simply to know a language and a DBMS. There is a LOT more that > goes into making projects succeed. Sadly, though, in softwre > engineering, we do not take the technical side of the discipline nearly > as seriously as we should, the invetiable result being poor quality and > high maintenance costs. >
The problem is that software engineering is still viewed as something like writing a novel rather than building a bridge. No business shmuck from Stern university would even consider trying to build the Verrazzano Bridge, while they think knowing of sticking their nose a mile deep into engineering an industrial strength banking or hospital system. Ruben > --- "A. Forrey" <[EMAIL PROTECTED]> wrote: > > > My point is that using information about "proces" can be useful but > > it is > > never a panacea but too many times folks like to skip over aspects > > that > > they should think about, even if they'd like to ignore it. THOUGHT > > should > > never be ignored but is often provoked by reminders. No need to > > belabor > > that further. > > > > > > On Wed, 5 Oct 2005, Greg Woodhouse wrote: > > > > > "Process" isn't the problem, so much as the degree to which process > > > consumes so much of our time and energy. I fear that we tend to > > think > > > that the right process will somehow prove a panacea -- or we become > > so > > > focused on process that tend to neglect other aspects, well, of the > > > activity of software development. > > > > > > --- "A. Forrey" <[EMAIL PROTECTED]> wrote: > > > > > >> My take on this is that The "Process" is a guide not a catechism > > and > > >> the > > >> pre-defined set of steps, documents and stages is a reminder of > > what > > >> may > > >> need to be considered and developed to facilitate the "Work". In > > the > > >> M/VistA environment this may be different than that in other work > > >> settings. The point has to be that these aspects support effective > > >> work. > > >> > > >> > > >> On Wed, 5 Oct 2005, Larry Andreassen wrote: > > >> > > >>> Comparing small and large team projects I've been involved > > with... > > >>> Small teams... "Do the work..." > > >>> Large teams... "Do the process..." > > >>> By process I mean a pre-defined set of steps, documents and > > stages. > > >> And, > > >>> often these stages do not fit naturally with the work. > > >>> On 10/5/05, Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > > >>>> > > >>>> From an outsider, it seems that more manpower WOULD be better, > > >> within > > >>>> reason. > > >>>> > > >>>> It seems to me that creating software should be somewhat similar > > >> to > > >>>> any other engineering project. My hospital has been adding a new > > >>>> wing for the last year or so, and it certainly wouldn't have > > gone > > >> up > > >>>> faster if there had been LESS people working on it. There has to > > >> be > > >>>> some optimal number of people to work on each aspect of > > >> element/stage > > >>>> the project, and then there is the interdependence of stages > > >> (can't > > >>>> start step 5 until step 4 is done etc.) > > >>>> > > >>>> I am also interested in following the computer gaming industry > > >> (which > > >>>> by the way earns more each year than the movie industry, for the > > >> last > > >>>> two years). Consider a typical 3D game. It requires the > > following > > >>>> basic elements: > > >>>> - base art creation > > >>>> - 3-D model creators > > >>>> - 3-D model animators > > >>>> - game shell to run levels > > >>>> - game level creators > > >>>> - music composition > > >>>> - sound effects > > >>>> - overall story creator > > >>>> - management team > > >>>> - database functionality (if MMOG) > > >>>> > > >>>> It seems to me that within each aspect of the project, you are > > >> going > > >>>> to have more productivity with more manpower--albeit with > > >> deminishing > > >>>> returns at some point. e.g. 6 modelers will get the game's > > >> resources > > >>>> created faster than 2 would, but 20 modelers might not be able > > to > > >> work > > >>>> at 100% effeciency. So I can imagine creating a graph with > > >> X=number > > >>>> of workers and Y being the total productivity. The curve would > > >> start > > >>>> out with a straight 1:1 increase, but then flatten out at extra > > >>>> workers help less and less. > > >>>> > > >>>> So the issue would be as to how much the project can be divided > > >> into > > >>>> truly unique aspects. There was a comment before that division > > of > > >> the > > >>>> project causes the individual parts to loose site of the whole, > > >> and to > > >>>> get demoralized etc. Perhaps that would be because the parts > > were > > >> not > > >>>> as unique as in my example above. In my example, I can't image > > >> that > > >>>> one person could be the musician for a game, and also a database > > >>>> programmer. But if you had two teams both working on databse > > >> issues, > > >>>> there could be problems. > > >>>> > > >>>> Anyway, enough writing about something that is completely > > outside > > >> my > > >>>> area of expertice! I have woken up way to early this morning > > (4:00 > > >>>> am), and I think I'm rambling a bit.... :-) > > >>>> > > >>>> Kevin > > >>>> > > >>>> > > >>>> On 10/4/05, Gregory Woodhouse <[EMAIL PROTECTED]> > > >> wrote: > > >>>>> Fred Brooks was a hopeless optimist. > > >>>>> > > >>>>> > > >>>>> === > > >>>>> Gregory Woodhouse > > >>>>> [EMAIL PROTECTED] > > >>>>> > > >>>>> "One must shy away from questionable undertakings, even when > > they > > >> have a > > >>>>> high sounding name." > > >>>>> --Albert Einstein > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Oct 4, 2005, at 5:29 PM, Ben Mehling wrote: > > >>>>> On 10/4/05, Nancy Anthracite <[EMAIL PROTECTED] > wrote: > > >>>>>> I have been trying to recall, but I think it is something like > > >>>> doubling > > >>>>> the > > >>>>>> number of programmers quadruples the time it takes to complete > > >> the > > >>>>>> project ...or something like that. > > >>>>>> > > >>>>> > > >>>>>> On Oct 3, 2005, at 10:51 PM, Nancy Anthracite wrote: > > >>>>>>> I have I heard this before as an aphorism with a lot fewer > > word > > >> but > > >>>>>>> exactly > > >>>>>>> the same meaning. As I recall, I heard Rick Marshall pass it > > on > > >>>>>>> as a quote > > >>>>>>> from someone else about what happens when you add more > > >> programmers > > >>>>>>> to a > > >>>>>>> project. > > >>>>> > > >>>>> I'm going to guess you're thinking of the 'classic' book > > Mythical > > >>>>> Man-Month? > > >>>>> > > >>>>> http://en.wikipedia.org/wiki/The_Mythical_Man-Month > > >>>>> > > >>>>> - Ben > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> ------------------------------------------------------- > > >>>> This SF.Net email is sponsored by: > > >>>> Power Architecture Resource Center: Free content, downloads, > > >> discussions, > > >>>> and more. http://solutions.newsforge.com/ibmarch.tmpl > > >>>> _______________________________________________ > > >>>> Hardhats-members mailing list > > >>>> Hardhats-members@lists.sourceforge.net > > >>>> https://lists.sourceforge.net/lists/listinfo/hardhats-members > > >>>> > > >>> > > >> > > >> > > >> ------------------------------------------------------- > > >> This SF.Net email is sponsored by: > > >> Power Architecture Resource Center: Free content, downloads, > > >> discussions, > > >> and more. http://solutions.newsforge.com/ibmarch.tmpl > > >> _______________________________________________ > > >> Hardhats-members mailing list > > >> Hardhats-members@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/hardhats-members > > >> > > > > > > > > > > > > === > > > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > > > > > > > > > "Without the requirement of mathematical aesthetics a great many > > discoveries would not have been made." > > > > > > -- Albert Einstein > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: > > > Power Architecture Resource Center: Free content, downloads, > > discussions, > > > and more. http://solutions.newsforge.com/ibmarch.tmpl > > > _______________________________________________ > > > Hardhats-members mailing list > > > Hardhats-members@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: > > Power Architecture Resource Center: Free content, downloads, > > discussions, > > and more. http://solutions.newsforge.com/ibmarch.tmpl > > _______________________________________________ > > Hardhats-members mailing list > > Hardhats-members@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > "Without the requirement of mathematical aesthetics a great many discoveries > would not have been made." > > -- Albert Einstein > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
