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.

Code Review Checklist - why every one wants to write one?

In my previous blog, I have report some of the recommendations from Robert Glass on Software standards and how they should be developed.

Today, I was asked to review a Code Review check list for .Net development submitted by a development group. Granted that Code Review Checklist is not the same as standards but more like a form of guidelines it should be written at least by someone that knows the stuff.

After spending some time reviewing the contents, which is made up of something like 30 items, I was horrified at such a low quality. Clearly the author of this check list has only had superficial knowledge of .Net. One example to show the naive level of knowledge is the demand that all string comparison should be performed in lower case. Clearly this person has not read this article. Another is the incorrect exception handling technique to look for in this checklist.

Some of the mistakes made, like method and parameters naming conventions, give an idea that the author's background is really in Java.

It begs the question why someone wanting to write a check list when FxCop has already contained one far far more extensive that this novice has been able to muster. There is even a book on the guidelines. So why bother?

In fact, the first item of the check list should demand a clean run of FxCop or VSTS Code Analyzer. Other check list items should be more about advanced issues like couple metrics, design patterns and complex issues, any unit tests and are they constructed in the spirit of Unit Test, etc.

The check list, as Robert Glass said,

should be written and reviewed by the best programming talent in the shop, not by whomever happens to be available at the moment.

This is not the first time nor will this be the last for me seeing this kind of mistake.

Software Standards and how to develop and use it properly

Over time, I have come across many attempts by software engineers from different development shops or organisations and have formed an opinion that many of these attempts are not only poorly compiled but often containing dangerous information. They are better served by adopting world recognised publications but there are very few that are well written and of International standard quality.

I have never been able to find any publication to back up my observation and opinion until I come across the chapter titled "Standards and enforcers: Do they really help achieve software quality?" in a book called "Softeware Conflict 2.0 - The Art and Science of Software Engineering" by Robert L. Glass.

This chapter not only supports my opinion but also clear my doubt of whether or not adherence to software standard produces quality software by his explanation that:

Standards are a narrow subset of the total issue of quality, and although it would be nice to establish the definitions of quality in terms of conformance with a sufficient set of standards, it is simply not possible. Software quality is defined in terms of attributes such as portability, efficiency, human engineering, understandability, testability, modifiability, and reliability.... you will quickly see the software quality cannot simply be legislated, it must be performed. Efforts to measure software quality in terms of standards conformance are doomed to letting poor-quality software slip through undetected.

While conformance to standards alone does not necessary produce quality software, he has found:

They do indeed help software quality and software productivity. But they must be done right. There are many pitfalls along the way, and many people aren't doing them right.

So how do you do it right? Here are his recommendations:

First of all, standards should be terse and to the point. The must rules for writing software, no matter what the installation, should be distilled into a short manual which can be digested quickly, applied easily, and enforced conveniently..... Guidelines, not standards, should be established. This document may be as long as it needs to be, because it contains helpful hints which most programmers will want to read, and length will not be a problem since there is no need or even intention of enforcing these rules.

Second, standards should be written and reviewed by the best programming talent in the shop, not by whomever happens to be available at the moment.
[...]
Third, enforcement of standards should be mandatory, not something done if there happens to be time.... Enforcement processes should include automated enforcers where possible (these are sometimes called code auditors), and the use of reviews as necessary where automation is not possible. Peer code reviews are one important way of doing standards enforcement, although the main focus of such a review should be on quality as a whole, not just standards enforcement.

Finally, Glass has this warning to Quality Assurance group:

Often quality assurance organizations will perform standards enforcement activities, and pronounce the software to be of high quality.

Microsoft still does not understand security.

It is good to see Microsoft is trying to force their user to give up their love for running Windows in Administrator's account.

But I wonder whose fault is that that induces Windows Users' to fall in love with running in Administrator's account? Certainly not Linux and Unix nor Mac as they do not set up user's account with Administrative rights.

As I have blogged previously, Microsoft could have nipped the bud when it was beta testing Windows 2000 which began to enforce profile security. Microsoft all along has not provided any developer's assistance to toe the line. Instead it makes its installer to set up users with Administrative privilege.

Microsoft's representative seems to contradict himself with comment like this in defense of not following the Linux/Mac modus operandi:

"Least privilege permissions are a part of a good defence-in-depth strategy but it's not the endgame. If everybody is logged-in not as admin or not as root, it is really not going to stop the malware in the long run ... malware is not going to disappear," Grimes told AusCERT delegates.

Grimes added malware could infect a computer using various attack vectors but if the user is not an administrator, the attacks are generally less dangerous.

"Can a malware program steal your password if you are not an administrator? Can [criminals] create a program that waits for you to log into your bank, authenticate and then take all your money? The short answer is, yes, absolutely," he added

No one is suggesting not running at root account is going to prevent malware attack absolutely or the disappearance of malware. Running in LUA, reduced the attack surface and it makes the attack harder to implement as acknowledge by Grime.

Another instance to demonstrate Microsoft does not understand security and still breeding an army of developers with a myopic view of security.

Recently we have discovered that developing strong name assembly in Vista using Visual Studio 2008 requires the IDE to run as administrator. It does not require administrative right to do the same task in XP Pro despite running in LUA. One naturally begs to ask why?

Not only is this stupid but downright dangerous. The reason is that the developers are writing code that could do all sort of stuff a standard users cannot. This results in program that does not run in XP LUA but runs in Vista with the support of UAC redirection. I would have thought Microsoft would not only encourage but demand developer to write code requiring the Least Privilege.

It is causing the same very problem that Microsoft is trying to stamp out. It is a bit late to close the gate when the horse has bolted.

Looks like Microsoft only half-hearted attempting "to break away from its tradition of users being an administrator by default."

Using Runas to run Windows Explorer

I have been using the recommendation from Keith Brown to launch an instance of IE6 from the Admin console to perform administrative task when running in LUA.

Unfortunately IE7 cannot run like this and hence I have refused to use IE7.

Thankfully, the unintended usage of "Launch folder windows in a separate process" in Windows Explorer discovered by Aaron Margosis does the job equally well.