|laziness, impatience, and hubris|
Re^2: Programming *is* more than "just writing code" ( but it's *not* a science) (was: Programming is more than writing code, but it's *not* a science)by mr_mischief (Monsignor)
|on May 11, 2007 at 22:10 UTC||Need Help??|
There is a serious flaw in comparing programming to scientific research. Programming in the large is not science.
To equate programming in general to fields of science is like equating architecture and construction of a building to physics. Programming uses CS as a basis the way architecture and construction use physics as a basis.
There are a couple of simple rules at work here that often get overlooked in the programming realm: The size and complexity of the project determines how sophisticated and informed your methods need to be. Also, the more levels of knowledge being built upon your contributions, the more fundamental and universal your contributions need to be.
Let's face it. A cook is a chemist of sorts, and so is a candle maker. Neither is going to rewrite textbooks about chemistry. A carpenter or bricklayer has some sort of physics knowledge, but they are not going to split the atom or need a particle accelerator. At one time, a cab driver or a cashier actually had to know some math, but they weren't in the business of proving the number of dimensions in the universe.
We don't have any solid, universally accepted differences in title between a sysadmin who's really talented with shell scripts and someone who writes frameworks for generalizing facial recognition software. Just because both might be called "programmer" or "software developer" does not mean the two are equivalent. I think this is a large part of the confusion in the software industry. I also think it's part of what causes so much friction between the highly qualified, very method-oriented people doing lofty things and the people who write small applications for small clients in small markets.
The truth is, you don't want everyone to be a scientist. You don't even want everyone to be an engineer. You won't wait for a Pasteur or a Salk to mix your cough syrup. You won't wait for a Hawking or an Einstein to build your house, or for a Tesla or Westinghouse to wire it. What you want, down in the trenches, is people who take the results of research and engineering and figure out how to apply those components and best practices to the project at hand. Researching fundamentals is important, but so is having homes, food, clothing, and a community site like Perlmonks to debate the point. If the research and experiments have already given us evidence that a particular way of doing things is a good way, why can't some people just use those good ways while others further the research?
Just because some people don't use best practices when they should doesn't mean everyone should be in the realm of developing new fundamental knowledge. That's where the line between technology and science lies. Technology benefits from science, but people as a whole benefit from the fruits of technology more than directly from the fruits of science.
Day-to-day programming is, like building construction, more a technological trade than a science or research topic. It's a method of combining established parts using established methods to further one of a set of fairly common goals. Sometimes a building contractor finds an innovative and truly better way to build part of a house. An architect is more likely than the contractor to find a new and better way to design the whole house. That same architect might develop a new and better way to fasten two materials together, but an engineer is more likely to do so. The engineer might develop an altogether better material from which to make the fasteners, but a researcher is more likely to do that. It's this way in any field, really. I'm not sure why people get the idea that software should be different.
Another trend you'll notice if you look at more established technologies is that these mostly stratified layers become more established the longer a trade is around. We didn't used to have a designer, a spinner, a dyer, a weaver, a cutter, and a seam sewer for making garments. People used to design and build a car single-handedly, but now there are auto researchers, auto engineers, auto factory engineers, auto factory employees, and auto factory robots. In time, I think we'll see such lines drawn in the software industry, of course with some mobility among layers. I just hope the titles aren't still, 'chief software designer', 'system analyst 3', and such meaningless chaff.
Christopher E. Stith