On Tue, May 13, 2008 at 08:03:33AM -0700, Christopher Smith wrote: > [EMAIL PROTECTED] wrote: > >Just like one can't estimate how one will do a math proof, > >one can't predict the outcome of struggling to design a software app. > > > >Hence, it would appear programming is mentally exhausting just like math > >right? > > > It very much depends on the work. Sometimes the work *is* math, but a > lot of the time it doesn't seem to much resemble math or seem similarly > mentally taxing (of course, some math isn't very taxing either I guess). > >You can't just sit down and solve a software problem in a linear fashion > >right? > > > Again, it depends. A lot of the time I pretty much just do that. There > are problems for which that is totally not the case though. > >1. Think hard for a bit until your brain is fried. > >2. Do something else. > >3. Psyche yourself up to repeat #1 again. > > > #2 is frequently to actually code up the solution and/or write tests for > it (or the next task). > >Therefore, it seems unrealistic to pay a developer for a full days work > >for one > >day! Why? *Because no developer can sit down and bang out a solution in 8 > >straight hours!* Instead, it is a inefficient process that often appears > >like > >no work is getting done with lots of breaks just like math! > > > I honestly don't see how this follows. Certainly, you can compensate > people on a per task basis, but that doesn't prevent the use of > estimation and time-and-materials type payment. For most tasks, the > level of effort required can be determined empirically. If you think > about it, if one follows your logic, there isn't much use for software > development for most business needs, as it'd be impossible to know when > the projects would be done. > > --Chris IMO, there is often great difficulty predicting the cost of software projects. Two books discussing this and related issues are:
Yourdon, Edward. _Death_March_ Glass, Robert L. _Software_Runaways_ Some of the difficulty with cost estimates is attributed to the extremely large number of interacting components in large software projects. No mechanical device has as many moving parts as a large program has individual arithmetic and logical operations. Also, a detailed understanding of what is included in a software project is, in the worst cases, only obtainable by developing most or all of the project. Not only can businesses fail by underestimating the difficulty of software projects, but also they can fail by refusing to undertake software projects which are reasonable calculated risks. In particular, a project that has novel programming or mathematical difficulties may promise a highly interesting and profitable product. In this case very inaccurate cost estimates may be bearable if the project seems likely to either succeed or be abandoned early enough. Stewart Strait -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
