Difference in Word Counts between Microsoft Word and Open Office

Recently, I was alerted to cases where word counts, often used as assignment benchmark, produced by Microsoft Word and Open Office appear to differ when analysing the same document.

How much do they differ or is there trend? To understand this phenomenon, a number of Word documents are used; some have extensive diagrams while another is a pure text produced from a very large document containing diagrams, tables etc.

Here are the results:
There does not appear to be any trend from these data samples and hence more investigations are required.

It is interesting and educator relying on the Word Count may have to be aware of this issue as more and more students are using Open Office.

Feature useable to users as well as Virus writter

I have always maintained this autorun feature is a questionable design feature and asking for trouble and now has been used to attack NASA's space station.

Sure you can get the Anti-Virus to scan it before launching it but why tempt fate.

A convenient feature to a users will be of equally convenient to Virus/Trojan attackers.

Turn it off.

Why software fails

According to this article:

The biggest tragedy is that software failure is for the most part predictable and avoidable. Unfortunately, most organizations don't see preventing failure as an urgent matter, even though that view risks harming the organization and maybe even destroying it. Understanding why this attitude persists is not just an academic exercise; it has tremendous implications for business and society.
[...]
Among the most common factors:
• Unrealistic or unarticulated project goals
• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project's status
• Unmanaged risks
• Poor communication among customers, developers, and users
• Use of immature technology
• Inability to handle the project's complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures

If the software coders don't catch their omission until final system testing—or worse, until after the system has been rolled out—the costs incurred to correct the error will likely be many times greater than if they'd caught the mistake while they were still working on the initial sales process. And unlike a missed stitch in a sweater, this problem is much harder to pinpoint; the programmers will see only that errors are appearing, and these might have several causes. Even after the original error is corrected, they'll need to change other calculations and documentation and then retest every step.
[snip]
In fact, studies have shown that software specialists spend about 40 to 50 percent of their time on avoidable rework rather than on what they call value-added work, which is basically work that's done right the first time. Once a piece of software makes it into the field, the cost of fixing an error can be 100 times as high as it would have been during the development stage.

If errors abound, then rework can start to swamp a project, like a dinghy in a storm. What's worse, attempts to fix an error often introduce new ones. It's like you're bailing out that dinghy, but you're also creating leaks. If too many errors are produced, the cost and time needed to complete the system become so great that going on doesn't make sense.

But this is 'the commercial approach' where companies are all too happy to attempt to manage bug reports from customers slavishly. Furthermore,

software developers don't aim to fail...we need to look at the business environment, technical management, project management, and organizational culture to get to the roots of software failures. Chief among the business factors are competition and the need to cut costs. Increasingly, senior managers expect IT departments to do more with less and do it faster than before; they view software projects not as investments but as pure costs that must be controlled. Political exigencies can also wreak havoc on an IT project's schedule, cost, and quality.

The follow advice should be heeded by all in software development:

Organizations are often seduced by the siren song of the technological imperative—the uncontrollable urge to use the latest technology in hopes of gaining a competitive edge. With technology changing fast and promising fantastic new capabilities, it is easy to succumb. But using immature or untested technology is a sure route to failure.
[...]
Bad decisions by project managers are probably the single greatest cause of software failures today. Poor technical management, by contrast, can lead to technical errors, but those can generally be isolated and fixed. However, a bad project management decision—such as hiring too few programmers or picking the wrong type of contract—can wreak havoc.
[...]
In IT projects, an organization that values openness, honesty, communication, and collaboration is more apt to find and resolve mistakes early enough that rework doesn't become overwhelming.
[...]
Even organizations that get burned by bad software experiences seem unable or unwilling to learn from their mistakes.

Here is the "Hall of shame" of software and interesting to see a fair share of shame is with ERP software.