Psychology Vs Cut And Dry Poll

Informal Wiki Poll

• SoftwareEngineering is mostly a fuzzy science that is heavily tied to human psychology: (2)

• Most SoftwareEngineering principles can be found using math and clear-cut reasoning that cuts beyond personal psychology: (0)

• I don't know. The question is too hard or we know too little at this stage: (1)

It's definitely not science, neither psychology nor mathematics, neither soft nor hard. It's engineering discipline. That's why it's called software engineering, for crying out loud. Why this dummy poll since the subject is discussed in many other places on wiki ?

• I disagree. Engineering is about physical things. Most software design issues are about the interaction of humans with computers (be it software maintainers or users). In physical bridge design, there is little or no human-side to it all (except perhaps for esthetics). Bad bridges wobble, rust, and/or fall down. Nobody disputes it when a bridge crashes into the water. One can apply hard math and physics models to know what will work and what doesn't. We have nothing similar that tells whether Lisp, TCL, or Eiffle is a more productive language to use, for example.
  • You can disagree all you want, Top but just do not spread all your disagreements repeatedly and redundantly over tons of wiki pages. In the meantime, I don't hold my breath until SoftwareEngineering will eb called SoftwareHumanities?.
  • Usually I don't do this - but I'm going to agree with Top here. What programmers do is SoftwareDevelopment, what everyone wished we did is SoftwareEngineering. Unfortunately there is no base to build an engineering discipline on - things get too fuzzy when user interfaces are introduced. -- LayneThomas
  • My response to the unfriendly "redundantly" accusations are answered at about 60% the way down at TopMind topic. Ironically, this is about the 3rd time you've accused me of redundancy.
  • In my mind, the biggest problem is that the discipline is still quite immature. We want everything in our discipline to be hard science, but it's not. ComputerScienceIsaSoftScience. To that extent, I agree with top. I disagree quite strongly with his (implied) belief that the fact that HumanFactors are involved means that we should abandon all attempts at scientific discovery and engage in a massive free-for-all (though much of the discipline is in that state currently, with many disputes resolved by non-scientific means). Top's entire premise seems to be "since this isn't an entirely hard science, my opinions on any subject matter (including things he is demonstrably ignorant of) should carry as much weight as any respected scientist who actively researches that subject -- and no amount of further research or discovery can change this state of affairs." It's an anti-scientific posture. Although ComputerScienceIsaSoftScience, I firmly believe that it is (or should be) a science.
    • That's all well and good - and I would prefer it as a science. I'm tired of everything being relative and having little formal basis for programming (except for hard computer science). The question is how do we get there? We can't take any steps forward until we have a way to evaluate techniques. Everyone wants to claim method <x> is better, so they can claim it as a "basis for engineering" - but without an objective way to evaluate things, it just re-descends into pointless arguing. -- LayneThomas

    • A few ideas:
      • We need to lose the arts-and-crafts mystique that some people have. When alchemy (a black art) morphed into chemistry (a science), wondrous things occurred. When manufacturing migrated from smithies to factories (the industrial revolution), production jumped by orders of magnitude. Yet still we have lots of folks here on Wiki (including most of the founding crowd, it seems) prattling on about how programming is an art form. It frustrates me to no end how much this attitude holds the discipline back.
      • Are we "softies" the cause or just the messenger? Probably a bit of both.
      • We need to start treating seriously the experimental results that are produced -- evaluating them for methodological soundness of course. Too many programmers view the softer parts of the discipline as inherently un-scientific. Papers that are produced which show X outperformed Y by Z% under conditions A, B, and C are summarily and uncritically dismissed as hogwash by advocates/fans of Y. (Of course, the vary notion of fandom is itself unscientific -- scientists should always be prepared to accept new results).
      • {If you know of such "proof X is better" studies, please place them under EmpiricalEvidence.}
      • Too much pure research is undertaken by corporations (especially Microsoft); not enough is done in more neutral forms such as universities.
      • Microsoft also has a history of tainting standards in their quest for monopoly that would have helped progress programming - That alone has held up the progress of programming for decades -- LayneThomas
      • A stronger sense of professional responsibility would be nice; perhaps backed with teeth. Far to easy for programmers and software houses to write crap software and wash their hands of it. What other article of trade gets away with disclaiming all warranties, expressed or implied?
      • Many "crap" programmers claim they are simply responding to a fast changing world that values FutureDiscounting.
      • Well, if a program crashes - who do you blame? Do you blame the hardware designers, the compiler designers, the operating system? Application developers are sitting on a mountain of other people's code, usually proprietary patent ridden closed source management-dictated code - The blame must be spread around to be fair. -- LayneThomas
    • My point exactly - and until then what we do is SoftwareDevelopment, SoftwareEngineering is an ideal - not a reality. -- LayneThomas
    • Maybe you have to change disciplines to obtain that. Software may never offer that (until we completely reverse-engineer the human mind.--TopMind
      • ''The problem is many of those papers contradict other papers, unfairly compare different languages, or are biased by certain machine optimizations. The reason programmers refer to it as an art form is that they are trying to resolve paradoxes. The two major problems are complexity and humans (complexity having gone beyond our mind's ability to hold the whole picture), and humans as inherently illogical and inconsistent (there is no absolute way to evaluate user interfaces, just as there is no absolute way to evaluate beauty) - I don't see any real solutions to those two problems - and that is at the heart of what is keeping programming from being engineering. -- LayneThomas
      • The key word is "absolute". We think that absolute proof of any claim is required; else the claim cannot be made. Our mathematical roots are showing. And therein lies the problem. If medicine required absolute proof of medical claims, we'd still be using leeches and bloodletting for everything. Nothing in medicine (well almost nothing) is absolute; most medical claims are of the form "in clinical studies, drug X was shown to be 12% more effective in treating disease Y for males age 65 and order.". Which is a far cry from "X is proven to cure Y". Yet doctors and other medical caregivers consider such research to be golden. This is how the state of the medical art is advanced--in tiny steps. Revolutions like the discovery of antibiotics are rare in medicine. In our discipline, many of us would consider an equivalently strong claim to be dubious and reject it out of hand, if it doesn't meet with our preconceptions.
      • Unfortunately we don't have a baseline to compare with - humans are mostly alike(at least genetically), but computers vary widely at every level of abstraction. If there were just "computers" - we could evaluate better, but studies running on a supercomputer optimized for vector operations have little bearing on an embedded 386 used for process control. -- LayneThomas
      • Of course, studies dependent on the hardware have little to do with psychology. Questions regarding to "what's faster" are easier - even if hardware dependent, they are usually repeatable. Questions that do deal with HumanFactors ought to be as hardware independent as possible. I think the problem isn't our ability do do research on the soft questions - as I point out above, many disciplines like medicine and psychology deal with softness just fine - it's are willingness to do so. Too many of us have preconceived notions about things that we aren't willing to let go of - contradictory evidence is dismissed or ignored. In many cases the psychological problem isn't with the subjects, it's with the scientists. As long as many of us assume an anti-scientific mindset, we simply won't be able to do science very well, if at all. -- ScottJohnson

I'd say the problem of comparing programming techniques is like comparing different human cultures - it is heavily biased by one's own environment, and usually ignores a host of factors. For instance, Americans like to think they are the pinnacle of freedom - even while having the highest percentage of our own populace imprisoned. Americans may be "better" in some ways, but there is no way to objectively decide "culture <x> is better than culture <y>" - so why do we think the same can be done of another multi-cultural system like programming? Can you imagine the difficulties in trying to scientifically decide how to create our culture - and ignoring the subtle artistic things? It's the same for programming. . . -- LayneThomas

Compared to anthropology, the social aspects of programming are much easier to deal with. We're just unwilling to deal with them. The problem is that we're not like anthropologists observing some pre-technology culture from a secret hideout in the trees; we're anthropologists trying to observe ourselves.

In other words - John says <x> is better, Jane says John is biased against <y>, Joe sees the conversation and decides <x> and <y> are equal because there is still debate about them. . . It doesn't matter if <x> or <y> are better because everyone assumes bias from then on (it's kind of like our 2004 presidential election).

Finally, there is a tendency with programmers to see things as a binary choice (HaHaOnlySerious). In reality we don't have to decide if <x> is "usually" better than <y> - we only have to learn where <x> is inferior or superior to <y> - understanding the context is where the "art" part comes in. I still can't decide if I like printf or cout better, but I don't have to - I just use whichever is more appropriate at the time - but qualifying that choice is difficult, just as qualifying whether using caffeine is beneficial or not is subject to many non-orthogonal, but still related factors. -- LayneThomas

---

I predict a LaynesLaw debate over SoftwareEngineering vs. SoftwareDevelopment (many do not consider them synonyms)

---

See also: MostHolyWarsTiedToPsychology, DisciplineEnvy