Category: Technology

WordPress is really quite nice to use for a blog.  It takes a little getting used to, but it’s clearly a highly tuned application that’s gone through multiple iterations of improvement.   Still gotta change that kumbaya banner photograph that came with the default installation though.

From the Computerworld article:

Oracle will not stop bundling what critics describe as “crapware” and “foistware” with its Java installer anytime soon, a company representative intimated last week.

Currently, the Java installer for Windows includes an offer for the Ask.com browser toolbar. Unless users explicitly uncheck a box on the Java installation screen — in other words, opt out — the toolbar automatically downloads and installs, and the browser’s default search engine changes to Ask.com.

Long-time Windows blogger Ed Bott of ZDNet found that the Ask.com toolbar was not immediately installed, but waited 10 minutes after Java finished to kick in. “I’ve never seen a legitimate program with an installer that behaves this way,” said Bott, who speculated that the technique was an attempt to hide the toolbar’s installation from technically-astute users.

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 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

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.

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.

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”