Exactly. My complaint was not that there were books (even many books) about process in the Software Engineering section, but that there was essentially nothing else. I also found it quite tellintg that there was a separate section named Programming. Do you see separate sections for electrical engineering and circuit design? Well, maybe. But even then, the schism is hardly so glaring.
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. --- "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
