On Jul 27, 2006, at 7:11 PM, Jason Stephenson wrote:
As a programmer, I can tell you why. Most programmers are not well versed in the art or the science (if there really is any) of programming.
There is a pretty large body of "Computer Science." Witness the ACM's Library or CS programs at MIT, Berkeley or CMU. However, we have an industry that needs 5% scientists and 95% practitioners at levels from architect through designer, planner, manager, tester and coder. Everyone on the assembly line at GM doesn't need a PhD in "Automotive Science" but they need well-designed tools and to follow a grand scheme they may only see a little piece of.
Do you know why? Most programmers don't really get to see that much source code. It's true. In the commercial realm of closed source software most programmers only get to see the code of the project (s) to which they are assigned. They never get to see much code that's better or worse than what they are used to seeing.
True.
The same is true in most university CS programs. Students are not exposed to all that much code. It's mostly theory and mathematics and then applying that theory and mathematics in code.
The "back page" opinion piece in last month's Communications of the ACM voices this same thought - stop having students write "toy" projects.
Additionally, software is in its infancy. I imagine that the first few thousand bridges that were built were pretty dodgy things. They were probably very likely to collapse under you. It took mankind a long time to figure all this out. (They still don't always do it right as the big dig mess is proving.) Software is a bit more complicated on the inside than making a bridge, too.
"One of the biggest reasons bridges come in on-time, on-budget and do not fall down is because of the extreme detail of design. The design is frozen and the contractor has little flexibility in changing the specifications. However, in today's fast moving business environment, a frozen design does not accommodate changes in the business practices. Therefore a more flexible model must be used. This could be and has been used as a rationale for development failure."
"But there is another difference between software failures and bridge failures, beside 3,000 years of experience. When a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry where failures are covered up, ignored, and/or rationalized. As a result, we keep making the same mistakes over and over again. "
The CHAOS Report, Standish Group, 1994 http://www.standishgroup.com/sample_research/chaos_1994_1.php
Writing software is like writing fiction or nonfiction in the sense that the only way to really get better is to do it. You read a lot and you write a lot.--It helps to eat your own dog food, too.
In "Why Does Software Cost So Much?," DeMarco argues that the construction metaphor is a terrible choice, for many reasons like the arguments above. He has some great suggestions for some other metaphors to try.
Software development may have bases in science, but it is not yet an engineering discipline. That may take quite some time or, indeed, prove not to be an appropriate model.
Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
