A site devoted to discussing techniques that promote quality and ethical practices in software development.

Thursday, April 30, 2009

Is it a second coming for Apple?

Recently Apple announced that it is building up its capability to build its own chip. Is its Apple's second coming or another case of Deja Vue.

Jim Carlton in his book has documented Apple's first foolish attempt between 1986 and 1989 that ended up flushing down the drain $20 million as follows:
...an Advanced Technology Group engineer named Sam Holland, who in 1986 convinced Gassee that Apple should design its own microprocessor chips.
Believing that Gassee and the engineers knew best, Sculley gave Aquarius his unequivocal support, to the extend that he even bought the engineers a $15 million Cray supercomputer they could use to perform their design work on.
The underlying motivation behind the Aquarius project was Apple's fear that the Motorola line of microprocessors that it was dependent on would soon run out of steam and be surpassed by the rival line from Intel.
Holland proposed that Apple design not only a new chip but one that would incorporate four microprocessors onto a single piece of silicon.
The only problem was that this had never been attempted before in a computer as small as a desktop.
"Aquarius was an example of the willingness of the top management of Apple to embark on grand projects that skilled technical management would have known was unfeasible," Alcorn [Al Alcorn was an Apple Fellow] says.
The italics emphasis is mine.

The project was shut down after a chip expert called Hugh Martin was recruited to help with the Aquarius project and this exchange between him and Sculley led to the cancellation of this bold & foolish attempt:
"He said, 'What do you think about Aquarius?", Martin recalls. "I said, John, that's ridiculous. Apple has no fab or chip experience. How do you compete with Intel and Motorola?"
Within 6 month after that conversation, the project was canceled.

Let's hope Apple management can still remember this secret project and learn from the history. Now Motorola is effectively out of the contention and Martin's question to Apple in 1989 was as appropriate to Apple as it is now, except that you can substitute Motorola with AMD.

"Apple - the inside story of intrigue, egomania, and business blunders" by Jim Carlton, 1997, Time Business a division of Random House. Page 86-90

Open Office Plan leads to lower productivity

Recently an article cited some research concludes that:
"In 90 per cent of the research, the outcome of working in an open-plan office was seen as negative, with open-plan offices causing high levels of stress, conflict, high blood pressure, and a high staff turnover.

"The high level of noise causes employees to lose concentration, leading to low productivity, there are privacy issues because everyone can see what you are doing on the computer or hear what you are saying on the phone, and there is a feeling of insecurity.''

This is not a startling result because Tom DeMarco & Timothy Lister had reported similar finding way back in the '80 and they concluded that:
Workers who reported before the exercise that their workplace was acceptably quiet were 0ne-third more likely to deliver zero-defect work.
Furthermore, Tom and Timonthy discovered, at that time,
The advocates of the new format produced not one shred of evidence that effectiveness would not impaired.
One digging around published data, they found the following justification for open plan office:
The fundamental areas of consideration in designing an open-plan office within an information processing environment are: the system's electrical distribution capabilities, computer support capabilities and manufacturer and dealer service.
In other words, open-plan was not designed for the benefit of human and is still is not even today!

"Peopleware - Productive Projects and Teams, 2nd Edition" by Tom Demarco & Timonthy Lister, 1999, Dorset House Publishing Co. Inc. Part II, Chapter 9

Wednesday, April 29, 2009

Setting the language in Word

It was an issue bugging me for a while when I went to spell check in Word (Office 2003), it defaulted to English-US even though the English-Aus was also checked in the list.

I went to use the Office's Office 2003 language settings tool to no avail as it was already correctly saying the default language is 'English (Australia)'. I use the Word's Tools | Language | Set Language... menu including setting English-AUS as the default in Normal.Dot, via the 'Default...' button. Again with no success.

Being a experience Internationalisation programmer and with detail knowledge of how Internationalisation issues are handled by the operating system, it dawn on me that the fix is not in Word or Office suite. They merely follow orders or hints.

A check on the default input locale revealed that I was using 'English - US' as the default input rather than 'English (Australia) - US'.

Once that is corrected, Word automatically defaults to use English (aus) spell checker and date.

Thursday, April 23, 2009

Always be vigilant about security even at places you feel comfortable - the office

The recent article on WSJ only brings home the truth that you must always be vigilant with online security, particularly on a terminal that's not yours and that your privacy is taken at lip service.

Any USB drive or your own materials that reside on company's machine must be protected using suitable encrypting device, such as TrueCrypt. If you suspect keyloggers are planted, use keyfiles with your TrueCrypt volume designed to foil keyloggers from capturing your password.

Any passwords that you need to submit to a site must be managed securely, using tool such as Password Safe, and never allow that to be cached on that machine. If it is convenient to you, it is also convenient to your attacker, who could be your supervisor, as confirmed in the WSJ article. It is important to use this kind of tool that avoids exposing the password to preying eyes.

Always use strong password and if you use things like Password Safe, you should always use the generated password by this tool.

E-Mail communication through the company's channel must be suitably protected. You can use Password Safe's command-line operations:
  pwsafe -e filename
To encrypt the file and
  pwsafe -d filename
To decrypt the file. It is advisable to perform these operations on a TrueCrypt volume to avoid residues being picked up.

A better option is to use the field and time tested free PGP, commercial version or GNU PGP.

Trust no one, no matter how warm the smile appears to be, and treat all environment as hostile are the best advice.

The truth about office life - shallow and fake

Alain de Botton documented this artificial environment:
"A lot of these firms, in a downturn, having spoken about love and friendship and all that, don’t lose much sleep about getting rid of 20 per cent of the workforce," he points out.

"And that really fries your head, to be told ‘we love you, we love you’ and then to be got rid of."

Office life exists on a level of "shallow cheerfulness", and talking about a crisis of meaning or any other deep feeling is strictly frowned on.

Thursday, April 16, 2009

How strong is your password?

Check your password strength here.

What can you do to make it harder for Conflicker?

A very good article mentioning what Conflicker attempts to do and how one could make life harder for Conflicker. Good advice:
First and foremost, if the user of the desktop that is being attacked is NOT a member of the local Administrators group, the worm will have a tough time infecting the computer
Even in Vista. Many advice in this article is for the Vista. To turn off Autoplay please refer to this support article.

Wednesday, April 15, 2009

Google's Unit Testing framework for C++

This is a good site on unit testing in C++ made available by Google. A companion blog discussing C++ Unit Testing issues can be found here.

Monday, April 13, 2009

Internet Explorer and Windows Explorer are not the same thing

Today, after filing a 'bug report' with the Commonweath Bank of Australia's NetBank, I have got a call from their staff and I was then passed across to the NetBank's support.

The support staff then told to bring up Windows Explorer and then go to Tools | Internet Option menu.

I was taken aback as I know my Windows very well and hence I asked her to repeat that again. This is my Windows Explorer's Tools menu:

As you can see this does not have the "Internet Options" menu item. When I pointed this out to her that Windows Explorer did not have an "Internet Options" menu item, she became rather stroppy.

Realizing what she really wanted was the Internet Explorer, I fired up IE8, which she knew I was using, as it was pointless arguing with someone who clearly had less clue than me:

Which clearly shows the presence of the "Internet Options".

Well she was partly correct. The Windows Explorer could embedded a copy of IE6 in it and when that happened, IE6 would have merged the Explorer's menu resulting in the Tools Menu containing the Internet Options as show here:
This was captured in a XP machine with IE6 installed. This is only available after you have navigated to a web page.

It is important to use precise language in a support situation otherwise it can result in conflicts. As an advice to support staff, you should use steps that are as independent as possible from environment issues; in this case the version of Internet Explorer makes a lot of difference. Hence if the support staff wanted the customer to go to Internet Options, it would be far better to use the following navigational path:
Start | Control Panel | Internet Options

This will work for all versions of Internet Explorer and would avoid all sorts of misunderstanding.

Sunday, April 12, 2009

Dissection of an amateurish COM business solution

There is a company which should remain nameless specialized in enterprise business application managing inventories, purchasing, work order, etc. the typical business operations. This blog post is to dissect this solution to demonstrate the:
  • superficiality of this company in the COM technology
  • wrong choice of architecture.
The dissection does not require access to source code because they are using COM, a industry wide interop standard that requires publication of the interfaces specification. This post will show you the free tools you need to see the laughable implementation. I will also offer integrator advice on controlling the rogue COM programs in future posting.

Program structure

The actual names of the programs are also altered to save the embarrassment. This program uses executables gratuitously and was first described in my previous post. It has a controller program, much like Windows Explorer, that can launch their business applications. Each business application, fictionally called M100, M200, M135, M500, etc are COM local servers allowing the controller to communicate with it and to allow inter-application communication.

The program uses Delphi3 and this is an important fact as it will become obvious. Naturally, they all have the Delphi's COM Server bug which can be observed using Process Monitor.

Their technical lead/designer knows this much that each application must implement a common interface, called IXyzApplication in order to meet the above stated objectives. But it is shown below that their modus operandi is not only naive and amateurish showing complete lack of understanding of COM but also their developers lack proper training and mentoring. In reality they have failed to meet the objectives to implement a common interface.

To dissect this program you will need to use the free tool called OleView, which is part of Visual Studio of any version or can be download from Microsoft.

The analysis

With this enterprise business application installed, it is time to use the OleView to examine the implementation defects. If you expand the interfaces tab and scroll down until you see the IXyzApplication, you will not be encountering just one entry of IXyzApplication but you will see at least 130+ copies of this interface. If you click on each IXyzApplication, the right hand pane will tell you the server supporting this interface, its type library and the COM identity.

In fact, the reason there are so many IXyzApplication is because each one of them:
  • has unique IID, thus making them unique; the name is only for human consumption and essentially irrelevant.
  • each one of them is supported in their individual business application.
In effect, they should rename the IXyzApplication to IM100Application, IM120Application, IM500Application etc to be precise.

This laughable situation is not caused by the the developer's fault but a management's fault; management has failed to provide technical leadership of sufficient caliber to guide their developers and to review their work. Their technical leaders also fail to provide structural infrastructure to allow their developers to implement this interface in their business applications; their current implementation also publishes unique IXyzApplication interface as well as implementation in each business application.

Obviously, to the management, it does not require much training to use Delphi3 IDE that so easily can produce a COM application with several keystrokes. Wow, could this be the silver bullet that has eluded Frederick Brooks [BROOK]? Don't think so and will be unveiled.

Furthermore, to their untrained technical leaders with only superficial understanding of COM, the Controller can talk to their business applications and that they are all named as IXyzApplication in each application. So isn't that fine? Not quite.

Using the OleView, we can disassemble the registered type library into IDL, Interface Description Language, to see a much clearer definition of the IXyzApplication. Here are the points to be noted:
  • IXyzApplication is derived from IDispatch interface
  • IXyzApplication is declared as dual interface
  • IXyzApplication has distinct guid for the interface.
For the moment we will forget some of the more ambitious ones, which violate more COM practices. Drilling into their COM characteristic further and comparing several IXyzApplication you will also noticed that:
  • The same method name can have different method id's in different business applications.
  • Some IXyzApplication's have different set of methods.
  • Some IXyzApplication has more methods.
  • Some has a different method in a method id that is used by others.
In other words, these developers only believe using the same interface name is all that is required. They obviously has no basic idea of COM and they are poorly served by their incompetent technical lead/architect in not providing a single definition of IXyzApplication with which they can implement it. They have no clue on the concept of implementing an interface and publishing an interface.

Digging around the installation area and using OleView reveals that they appear to have interfaces publishing DLL that they could and should include IXyzApplication there. For some unknown reason they did not. Perhaps that is out of the ordinary task supported by the IDE and that they cannot handle this.

Standing back from this problem, one wonders how the controller can communicate to all these business applications each with a unique IXyzApplication interface? The answer further illuminates their total ignorance of COM.

In order for the controller to work and for business applications to talk to another one via the 'IXyzApplication', they are not using IXyzApplication but using the following technique:
  1. They are actually using dispinterface via the IDispatch interface, the base interface of IXyzApplication.
  2. They are using a language/framework that does not cache the method id.
Reason 1) is supported by the fact that there is only one definition of IDispatch belonging to Microsoft but there are at least 130+ 'IXyzApplication'. In order words their declaration that their interfaces supporting dual is incorrect or at least superfluous.

Even allowing the client/server to be using IDispatch calls, the haphazardly assigned method ids and missing ones would have play havoc to client that caches the method id.

The only reason that their Delphi solution works is because Delphi does not cache the method id at compile time, unlike those using Microsoft Foundation Class/ATL or Visual Basic 6. Using cache id is perfectly acceptable because COM spec demands the consistency in method id assignment and there is only supposed to be one and only one IXyzApplication. Basically Delphi will call IDispatch::GetIDsOfNames() followed by IDispatch::Invoke() to call each IXyzApplication methods.

Using this inefficient dynamic technique ignoring the COM interface specification is the only way to deal with a haphazardly assigned method ids.

While the solution 'works' albeit in a very tightly coupled to a particular tool that happens to use an inefficient implementation, it means that it has completely destroyed the benefits of an opened industry-wide interop standard, such as COM.

It fails to use a more efficient call mechanism, such as v-table call supported by dual interface that the IXyzApplication has adored with. It cannot possibly use IXyzApplication because which one is to be used? There are 130+ IXyzApplication. The management of this company does not understand the fundamental of COM; it is not the name that matters in COM; it is the guid. If the guid is the same, then it must be the same interface regardless what you call it. Their mistaken belief produces such a laughable solution.

Secondly, it fails to support interop in a wider sense supported by COM. Their action prevents their customers from writing custom controller or to interop directly to those business applications in other tools than Delphi; COM is a language and tool neutral interop technology. However, there is a way to do this without using Delphi as a client and that is the subject of a future post.

As a result, the customers are the poor losers in this sad affair. If this software is a car, some form of medicine or financial instrument, I am sure the company responsible for this will be prosecuted for misrepresentation of the facts or producing unsafe product. But in software, this is masqueraded as innovation!

The company has not found a silver bullet; they have only addressed incompetently the accidental part [BROOK] of software building as their product has demonstrated unequivocally.

Frederick Brooks, "No Silver Bullet - Essence and Accidents of Software Engineering", IEEE Computer, April 1987.

Wednesday, April 8, 2009

A case of deja vu

An article I have just read from ACM Queue is almost like that movie by Denzel Washington except that this is about a failed software package:
the seeds of failure are all too obvious, at least with the benefit of hindsight. The two warning signs that really jump out are the absence of any coherent statement of requirements or goals (note, for example, that the notion of performance appears to have been an afterthought) and the fact that the team chose a technical approach they had few qualifications for—namely, writing PC software while avoiding any use of Microsoft technology.
This article also points to another reason why this failed product fails:
effort quickly turned into a matter of technology looking for a problem to solve (an all-too-common occurrence)
What had been identified by Peter are the cause of failure in my experience. It is not a RIA but a .Net application which ended up best summed up as a .Not application (Not a .Net application but a half-baked one). In this case it was faddish to be a .Net application so they need one! This failure contains many lessons that are worth exposing and will be covered in future blog posts.

In my situation, there required no hindsight to know the right atmosphere for failure; the foresight was arrogantly rejected prior project began; the management was too amateurish and haughty to ask for advice and to receive any. Their steadfast refusal to recognize their failure causing the company huge amount of ongoing waste and their customers excessive expensive run time resources as well as missed opportunities. The resultant is a big embarrassment of a comatose .Not product.

Tuesday, April 7, 2009

Allowing error message to corrupt download - www.ingdirect.com.au - Not Nice

For the last few months, whenever I downloaded banking data from ING Direct in Quicken format, the download data failed to be imported into my accounting package complaining about import data corruption.

Not easily deterred by this kind of things particularly the downloaded file was a text file and that I was very knowledgeable in QIF file format, I opened the file in a text edit and the reason was so obvious.

What happened was that at the end of the download of the correctly structured QIF data, their .Net web server application must have thrown an exception and their application then formatted the message into HTML format ramming it into the QIF file. Here is the error message:

Server Error in '/Client' Application.

Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customerrors> tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->

<customerrors mode="Off">

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customerrors> configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->

<customerrors mode="RemoteOnly" defaultredirect="mycustompage.htm">

Not very nice. I doubt the download feature was used much otherwise people would have complained or people just believing mistakenly that the Internet corrupted the download.

Once I deleted the error message from the QIF file, I could import it successfully. Have they actually tested their web application at all? I wonder!

Monday, April 6, 2009

A snapshot view of how Asia's best employers deal with economic down turns.

This is a snap shot analysis of how Asia's best employers deal with the economic down turns:
many of the best employers in Hewitt's survey see the global economic crisis as an opportunity to cement their relationship with their staff, train employees and woo key people from competitors.
According to the survey many are adopting the "Employee first, Customer Second" method:

Forward-looking companies across the region are adopting that business model. HCL Technologies, an IT outsourcing firm based in Noida, India, and a top 25 Hewitt winner, adopted a new vision statement called "Employee First, Customer Second" in 2006.

The idea: by empowering employees and giving them any tools they need to help customers, the business will thrive.
This is very same model used successfully by Southwest Airline, USA that came through 9/11 attacks financially intact with no layoff of any staff. This is how the former CEO James F. Parker explains it in his book, page 168:
At Southwest, we were sometimes asked who we sought to serve first - employees, customers or shareholders. We always said employees come first. We knew the way we treated our employees would determine their attitude towards our company. We knew that if we served our employees well, they would serve our customers well. And if our customers were happy, it was pretty likely the shareholders would be happy too.
That all pretty good sense to me sadly too many companies fail to see this simple rule.

[1] "Do The Right Thing - how dedicated employees create loyal customers and large profits" by James F. Parker, Wharton School Publishing, 2008.

Blog Archive