Computer “Science” doesn’t deal with the issue of humans writing software

In the article titled, Faith, Hope, and Love An essay on software science’s neglect of human factors (PDF) the argument is made that Computer Science is useful as a mathematics tool, but doesn’t deal with the elephant in the room issue of what software techniques help humans write better software.

There is surprising little human factors or industrial psychology style research used to design new computer languages or programming guidelines (eg. object oriented design)

Another article points out that most of the major computer programming languages in use today were not developed by computer science academics.

Kodak got a lot of things right—and still got it wrong

Kodak saw digital photos coming, but didn’t have the guts to kill it’s cash cow film business until it was too late. They did roll out some digital photo products early on, but they didn’t commit the amount of money necessary for product development to compete with the Japanese camera makers. See:

http://spectrum.ieee.org/podcast/at-work/innovation/innovation-is-hard

What caused the wealth gap? (in the US over the past 30+ years)

So it’s not really Wall Street and big banks which are the source of our econmic problems, it’s globalization.

From http://news.salon.com/2011/10/11/what_caused_the_wealth_gap/:

“for most of American society, and certainly for the majority of Americans who don’t have a bachelor’s degree, globalization has meant facing much lower-wage workers abroad and increasingly powerful competitive pressures. So our society began to separate between the “haves” and the “have-nots,” really in the early 1980s.”

And paraphrasing: Ronald Reagan’s solution to the problem (less government), completely missed the point and, in fact, made things worse.

Is Software Engineering engineering? (and is Computer Science science?)

An article in the Communications of the ACM (March 2009, vol 52 #3) makes software engineering sound just slightly better than a voodoo ritual (no disrespect to voodoo intended). I would also ask a related question, “does computer science have anything to do with software engineering?”. For example, objected oriented design is the accepted software design methodology today, but what science exactly is behind this? CS seems to deal with the logic and complexity of algorithms, but that’s really a very small part of software engineering.

Anyway, here are some quotes from the article:

In its most general form, the “engineering process” consists of a repeated cycle through requirements, specifications, prototypes, and testing. In software engineering, the process models have evolved into several forms that range from highly structured preplanning (waterfalls, spirals, Vs, and CMM) to relatively unstructured agile (XP, SCRUM, Crystal, and evolutionary). No one process is best for every problem.

Despite long experience with these processes, none consistently delivers reliable, dependable, and affordable software systems. Approximately one-third of software projects fail to deliver anything, and another third deliver something workable but not satisfactory. Often, even successful projects took longer than expected and had significant cost overruns. Large systems, which rely on careful preplanning, are routinely obsolescent by the time of delivery years after the design started. Faithful following of a process, by itself, is not enough to achieve the results sought by engineering…

software engineering literature … relies heavily on software anecdotes and draws very lightly from other engineering fields. Walter Tichy found that fewer than 50% of the published software engineering papers tested their hypotheses, compared to 90% in most other fields.

The Limited Importance of Process Maturity in Software Development

An article by Steve McConnell from IEEESoftware.com notes that, surprisingly, software development process maturity (ie., rigorous technical management procedures) doesn’t seem to matter as much as “soft” factors like: seniority of personnel, good communication, motivation, analyst experience, etc.

The unstated implication is that the academics and big corporations concentrate too much on process maturity (eg. ISO 9001 & CMMI), because that’s easy to quantify, rather than actually being important.

Object oriented design lesson: Control flow should not be a class behavior

From an article in the journal IEEE Software, May 1996, page 37. Unfortunately, I don’t have the author or title of the article and searches for the content on ieee.org don’t seem to find it, so I’ve scanned it in below.

Although most of the software world doesn’t seem to talk about OOD this way, the “lesson” below seems reasonable based on my experiences.

If the control flow is partitioned into a “separate dynamic control flow object” as mentioned below, isn’t that object really not an object at all, based on the definition of an object containing data and actions modelling an entity? Stated another way, object oriented design only makes sense when the actions are centered around a piece of data. In this case, the actions are centered around coordinating control flow.

Could the whole computer science industry be so wrong about something for so long? I seems similar to the repudiation of psychoanalysis after 60 years of the dominance of the theory:

Continue reading “Object oriented design lesson: Control flow should not be a class behavior”