Archive for the 'Rants and Complaints' Category

Mirvish/TicketKing Lies About Security

February 1, 2010

Not cool in this geek’s books.


On Mobile Phones and Driving

November 5, 2009

Worth repeating, from Jakob Nielsen’s excellent newsletter:

In an opinion poll, the New York Times asked whether Americans wanted to outlaw mobile phone use while driving:


80% of respondents said that using a HAND-HELD cellphone while driving should be illegal.

But almost 90% said that it should be legal to talk on a HANDS-FREE cellphone.

Completely OPPOSITE INTUITIONS about the danger of these two ways of using a mobile phone. This despite the fact that all studies show that it’s EQUALLY DANGEROUS to use hands-free and hand-held mobile phones while driving.

Research has found that the danger comes from the cognitive distraction of carrying out a conversation with somebody who’s not in the car. The problem is not holding the phone with one hand while driving with the other. The problem is the conversation and the way it lays claim to limited cognitive resources.

This finding is completely counter-intuitive: how can it endanger your life to carry on a simple, everyday task like a conversation? The survey clearly demonstrates that people’s perception of danger is completely divorced from the actual danger.

When driving, you are piloting a power plant, and a single mistake will cause human beings to die. This is a task worthy of your full attention.

How much of total software cost goes to maintenance?

September 8, 2009

I thought I had a simple question: How much of total software cost goes to maintenance? I want a number that is recent, backed by evidence, and generally citation-worthy.

It turns out it’s hard to find. Software engineering course notes online tend not to cite their sources. Recent estimates tend to come from magazine articles citing Gartner or Forrester. A 2000 IEEE-published article was cited as “90%,” but digging into the paper I find:

According to an informal industry poll,85 to 90 percent of IS budgets goes to legacy system operation and maintenance.

If you know where I should look, please get in touch.


September 2, 2009

And I quote:

For these reasons, our general approach to DSL development consists of two major tasks:

1. Tailor the DSL engineering process to the project’s context.

2. Apply the tailored DSL engineering process to develop the DSL.

To paraphrase: “Our process, that we are publishing here in this peer-reviewed journal, is: Make up a process, then use it.”
Even though this is a cheap shot, I would also like to point out that this same article has typos. Like, they misspelled “Haskell” as “Haskel,”, and “built” as “build.”
I wonder if I am the only human being on the planet who is reading this thing.

Inheritance Is Over-Taught (and taught too early)

July 21, 2009

Software Carpentry is gnashing through object-oriented programming.

It seems like the de facto way of teaching object-oriented programming involves diving into inheritance and polymorphism. These tend to take up a large proportion of the time because inheritance and polymorphism are hard.

I think the amount of time spent on these concepts is disproportionate to the amount they are used and encourages the overuse of these tools.

Composition, delegation and other relationships can all be modeled using references to other objects. Inheritance, however, relies on modeling a domain using only specialization relationships.

I think very few real domains actually are modeled really nicely using inheritance hierarchies.  I can only think of a few examples: Actors in simulations such as games, data structure libraries, and graphical user interfaces.

Where there is no way to model a domain using specialization, you’re actually lucky. In some cases, there is more than one way to model a domain using specialization. For example, you might be tempted to specialize objects that have physical properties. Some of them have behaviours related to mass, some related to energetic activity. Do you impose a partial ordering on the dimensions? Which partial ordering? Do you teach mixins? Multiple inheritance? Or do you try to teach why you should discard inheritance in this case?

Thankfully for the real world, the kind of domain modeled by inheritance tends to be the kind of domain where a few experts write a library that everyone then uses. This further reduces the argument for teaching inheritance.

Nearly all other relationship types degenerate into composition, delegation and reference.

Of the holy triumvirate of object-oriented principles (Inheritance, Polymorphism and Encapsulation) I think Encapsulation deserves the centre stage and the bulk of the attention, but it doesn’t get it. I like to ask “What information does this class protect from others?” It’s a much more productive question than devising inheritance relationships, which can be viewed as the task of sorting out a partial ordering of dimensions of classification of objects i.e. complicated.

Inheritance should be viewed simply as just one method of code reuse, and a particularly hard-to-use one at that. As such it is appropriate for programmers learning about refactoring and advanced code quality practices (i.e. advanced programmers only). At this time programmers will have a much stronger foundation for understanding this concept. Proper design of inheritance hierarchies requires thinking cleanly about TWO external interfaces for a class: The typical object and the interface to subclasses.

To make matters worse, we’ve only been discussing traditional inheritance. Prototype inheritance is another paradigm entirely. Many smart people think prototype inheritance is a better system overall, but the world is stuck with these 1970s concepts.

So to sum up this rant:

  • Inheritance is hard to use right in the real world.
  • Compared to other object relationship types, inheritance isn’t used that much in the real world.
  • Inheritance is just one of many ways of reusing code.
  • Inheritance is taught too early to novice programmers.
  • Inheritance consumes too much of the object-oriented education curriculum.

In my view, instead of the status quo we should:

  • Teach objects only in the context of information-hiding. Treat classes as simple, standalone templates for objects.
  • Teach delegation as the primary method of code reuse.
  • Omit discussions of inheritance until as late as possible.

Things I can’t do with my iPhone*

July 8, 2009

Things I can’t do with my iPhone*

*that I should be able to and can be implemented in software.**

** that I may simply not have learned how to do yet.

  • Download a picture from picasaweb
  • Sync over bluetooth or wifi. I could do this with my several-years-old motorola phone and Apple’s own iSync. Two steps forward, one step back.
  • Sync saved Safari passwords, Airport networks, or VPN settings from Keychain.
  • Manage iCal to-do lists
  • Record calls
  • Get the app store to remember my password

Fido + iPhone Fail.

July 7, 2009

A while back I compared the big smartphones available in Canada. I decided I wanted the iPhone 3GS. Then I compared Fido to Rogers for my needs and found a Fido plan that I liked. This seemed convenient because I’m already a Fido customer, which I thought would make things easier.

On June 19 I went to the biggest Fido store in Toronto to buy one, but they were out of stock. I called around and all the other Fido stores were also out of stock. I thought this was silly, because they had been advertising the phone heavily and this was the third iPhone—they should have anticipated the demand better.

The next day I called Fido to order one over the phone. I waited 25 minutes on hold before my phone went out of service and the call dropped.

The next day I called Fido to order one over the phone. The woman on the phone told me it would probably be shipped to me in the next week or so, but in the worst case it would arrive July 7th. She wanted to activate my new plan right away, but we agreed that it would be silly for me to pay for data and visual voicemail and other features until I had a phone to use them with. So, I would receive my new phone, call Fido, and activate my new plan to give Fido lots more money.

About two weeks later I called to check on the order. I was assured the July 7th deadline was still good.

Today is July 7th. I called to find out what had happened.

The gentleman on the phone told me the phones were out of stock and backordered, but there was a waiting list.

I told him that I had already been promised a July 7th delivery, and asked him why I didn’t have my phone.

He told me he would check to see if it had been shipped yet. It hadn’t. They had no shipping tracking number.

I asked him when I could expect a new phone.

He looked into my file and told me that as a matter of policy they could not give me a new phone at agreement price and that the back office had blocked my order.


I asked him to clarify since I didn’t understand.

He said that as a result of my phone plan change in November which included a system access fee I could not order a new phone.

What just happened?

I asked him what happened on June 21 when I ordered my phone and it was to be delivered July 7th at the latest.

He said the woman I spoke with had made a mistake.

I asked him why I had been allowed to order a phone then. I also suggested to him that it was strange that the back office would block my order due to a policy I had never heard of without notifying me.

He left to check with his supervisor. When he came back, he said that my plan change in November made me ineligible for a new phone, even though I didn’t get a new phone at that time.

(In November, I changed plans. I was already a Fido customer, but on an old plan. I switched to a new, better plan and paid a $35 activation fee. I’ve always used my own unlocked phone and I’ve never signed a long-term contract.)

I told him that this didn’t make sense, because if I wasn’t already a customer, I could walk into a Fido store, give them money for a new phone, and sign up for an agreement. I asked him how we could solve this problem.

He said he couldn’t do anything about the policy.

I asked who I could talk to who could solve this problem and clarify what the hell had happened here.

A few minutes later, I had a supervisor named Oliver on the line.

We talked through the situation. Oliver made some exceptions that I don’t fully understand to work around the Fido system. As of now, I’m on a different (worse) plan, but, if I can find an iPhone in a store, I’ll be able to buy it without the system throwing up some error. I’m also on a waiting list if the central Fido gets some new stock.

I called the biggest Fido store in Toronto. They are out of stock. I called around and all the other Fido stores were also out of stock. I thought this was silly, because they had been advertising the phone heavily and this was the third iPhone—they should have anticipated the demand better.

ANTLR: Buyer beware

May 13, 2009

The author of ANTLR, Terence Parr, is a professor at the University of San Francisco and is the inventor of the LL(*) parsing strategy.

This might make you think that ANTLR rests on the same academic foundations as many other tools created in universities and given scary names like “LL(*) Parsing Strategy.” Not true.

From “The Definitive ANTLR Reference”:

In particular, Part III provides the only thorough explanation available anywhere of ANTLR’s LL(*) parsing strategy.

Read: There are few academic publications on ANTLR and seemingly none on its underlying technology.

This isn’t normally a problem. Most useful software is not built on academic foundations. However, ANTLR is positioned more than most to look “academic”. It’s not.

The State of ESE

May 10, 2009

Let me get this straight:

  1. We are not able to systematically get requirements right.
  2. We are not able to systematically get estimation right.
  3. We have completely standardized on an diagramming notation that doesn’t address the real needs of diagram users. Accordingly no one uses it.
  4. A large proportion of software engineering research is poured into the general area of formal methods. Yet, the ROI on formal methods is not known to be positive in general or in any specific case.
  5. Debugging is the greatest time sink in any programming activity and yet nearly no curricula contain a systematic debugging course.
  6. We have no agreed notion of the populations of
    1. software engineers,
    2. software engineering students,
    3. software engineering problems,
    4. or of software engineering environments. Therefore we cannot draw representative samples of any of these.
  7. We have no standardized (valid, reliable) constructs for measuring software engineer skill on any dimension whatsoever.
  8. The greatest general productivity improvements in the real world have been attributed to successively higher-level programming languages, yet programming language theory had nearly no influence on the most important programming language of all time (C). Modern programming language theory has had next-to-no influence on the most influential programming languages of this generation (Ruby, Python, PHP).
  9. In sum, we have no knowledge whatsoever of transferability of software engineering research into practice.

And yet, despite these failings, software “out there” has managed to take over the world. Without “us.”


On Claims and Citations

April 26, 2009

Help Needed: Where can I download a machine-readable database of publications in computer science or especially empirical software engineering? Or is this a job for Amazon Mechanical Turk?

At a small gathering of junior computer scientists today we had an involved discussion about the reputability of claims in scientific publishing.

A few key agreements from my perspective:

  • Sometimes a lemma is more interesting than the main theorem in a publication. Then future citations cite the paper for the lemma though not for its main result. More generally, sometimes we cite tangential results, not the main result of papers.
  • Sometimes a paper’s research does not truly support its claims. Future citations of the paper lose this information.
  • Sometimes a paper’s research does not support its claims as strongly or as generally as citations of it seem to imply.
  • Sometimes researchers will repeat a citation of a paper without reading the paper. Thus imperfect paraphrasings propagate unchecked.
  • Sometimes good research is built on foundations of less rigorous research.

It would be nice to build a database of publications with metadata for supported claims. It should include the strength and method of the support of the claim. Then we compare citations of that paper against the claims the paper actually supports.

This method would apply even in mathematical fields where the purity of knowledge is higher. For example, we could imagine a proof P that relies on theorem T. A paper presenting P would cite a paper proving T. If P no longer holds if T is false, then it is interesting to know how thoroughly the proof of T has been checked. Has it been glanced over casually by two overworked reviewers, accepted on trust and reputation? Has it been checked formally by computer? Our database would include this kind of information in its entry for the paper proving T.

We should also consider the importance of a given citation to the citing paper.

Some citations are critical. In this situation a paper would lose its force if the cited paper were incorrect.

Some citations are informational. In this situation a paper is cited because it is considered interesting and relevant. But a later debunking would not invalidate the citing paper.

Some citations are methodological. In this situation a paper is cited because its method has been copied or tweaked. This leads us to another important consideration I will not discuss today: The (lack of) standardization of methodology in empirical software engineering.

An near-term achievable goal would be to gather a large number of machine-readable papers, build a dependency graph of citations, and compare the citing sentences. It is common practice to tag a citing sentence with a reference[1].  These sentences we could extract programmatically. Thus we could gather a large number of citing sentences and compare them to each other and to the actual claims in the paper. I suspect we would not like the smell of what we found.

Help Needed (repeat): Where can I download a machine-readable database of publications in computer science or especially empirical software engineering? Or is this a job for Amazon Mechanical Turk?

[1] Not a real citation.


April 24, 2009
  1. Download Microsoft Windows Vista Business, for free, from MSDNAA.
  2. Burn it to DVD+R. Learn that DVD-R is evil.
  3. Partition drive using Boot Camp. Boot Camp partitions live without a reboot! Partitioning fails due to a disk integrity error.
  4. Reboot computer using Mac OS X Leopard installation CD. Run Disk Utility. Repair disk.
  5. Reboot normally. Partition drive using Boot Camp. Leave 50GB for Vista.
  6. Reboot using Vista CD.  Answer a few setup questions.
  7. Vista installation zooms by!
  8. Enter a password for Vista.
  9. Wait for self-configuration to finish.
  10. Insert Mac OS X Leopard installation CD. Install all sorts of drivers and things.
  11. Reboot into Mac OS X. Retrieve important passwords from Keychain. Store them and some files to USB stick.
  12. Reboot into Windows. Connect to internet!
  13. Download 51 updates, mostly critical security patches. Reboot.
  14. Between 10 and step 13, confirm your intentions to Vista 3,042 times. Yes, I really want to do the thing I just asked you to do, Vista.
  15. Download Project, Visio, Visual Studio from MSDNAA. Copy .iso files to USB stick for later burning. Toys to play with and learn!
  16. Fiddle with various .iso mounting tools for an hour. Settle on one. Install free expensive Microsoft Software. Installations (seem to) go much faster from USB drive than from hard drive.
  17. Download and install Expression.
  18. Spend hour or more trying to get Dell 2405FPW monitor to work properly. Its maximum resolution is 1024×768 in Windows Vista even though in XP or Mac OS X or Ubuntu it works at 1920×1200. No driver for it.
  19. Download 24 new critical updates made necessary by new software installations.
  20. Look for toys to play with. Fail. Turn on Aero and play with Windows-Tab for fourteen minutes and thirty-two seconds. Discover and get mind blown by Windows Live Writer’s sheer awesome. Laugh yet be intrigued at IE8’s suggested sites. People who like Windows Live Search also like MySpace. People who visit Microsoft Update also visit Firefox Download Page.
  21. Bring laptop to office. Forget power cable.
  22. Watch in terror as battery meter drops precipitously. Scramble to find power settings. Find them. Turn on maximum power saver. Forty-five minutes of charge remaining at 3/4 full battery. Scramble to find option to turn off Bluetooth and WiFi. Fail. There is no easy way.
  23. Reboot into Mac OS X. Miss Windows Live Writer. Make note to learn Visual Studio, F#, C#, Project, Visio, Expression, Power Shell.
  24. Look forward to Julie Larson-Green saving the Windows UI.

On Non-Truthful Peer Evaluation Mechanisms

February 23, 2009

In September, I reviewed a paper called “Turning Student Groups into Effective Teams.”

In one of my classes, we do a large project in groups of four. Based on a suggestion by the paper, the professor has implemented a peer review system.

The peer review system compares an evaluation of me to the average evaluations for my group.

Here is the system:

  1. Every teammate gives a rating for every other teammate’s performance for each assignment. In a group of four, I make three ratings and I am rated three times.
  2. My overall rating is the average of the three ratings of me.
  3. The baseline rating is the average of all the overall ratings.
  4. The professor assigns a mark to the group.
  5. If my overall rating is higher than the baseline rating, my mark is the group mark plus an adjustment bonus.
  6. If my overall rating is lower than the baseline rating, my mark is the group mark minus an adjustment penalty.

Game theorists have a concept called “Truthful Mechanisms.” A truthful mechanism is a system in which every player’s best interest is to tell the truth. 

This is a non-truthful mechanism. Nobody should use it ever.

Imagine I give all my teammates a perfect rating. If any teammate gives me a less-than-perfect rating, my overall rating will be lower than otherwise and my mark goes down. By giving everyone a perfect rating, I raise the team average and hurt myself.

Imagine I give all my teammates a zero rating. If any teammate gives me a better-than-zero rating, my overall rating will be higher than otherwise and my mark goes up. By giving everyone a zero rating, I lower the team average and help myself.

The professor argues that, because we perform this evaluation rigmarole several times, unfair conduct will be weeded out. I say, garbage in, garbage out. The incentive becomes “mark your teammates as low as you can get away with.”

The system is malicious: It pits teammates against each other.

The system is also very dumb. It can punish individuals in perfectly functional teams!

Let’s say a team works really well together. Pete thinks, “Everything went very well. I’ll give everyone ‘Excellent.'” Everyone else thinks, “Everything went well. I’ll give everyone ‘Very Good’.” Result: Pete’s mark is adjusted downward. Everyone else is adjusted upward. Oops!

Please, do not use the system presented in the Oakley paper.

A Gallery of Bad Design

January 30, 2009

A large number of (what I consider to be) design errors:


  1. Amazon has a list of books I’ve already bought from Amazon. It also has a list of books I intend to buy, courtesy of my (large) shopping cart. It also has a list of books I have no interest in, due to my clicking “Not Interested” where appropriate. Yet, throughout the site, it continues to recommend books from all three categories.

    The Little Computer Scientist’s recommendation: Amazon’s recommendation engine should not recommend books I already own or books that are already in my shopping cart. 

  2. I keep many books in my “Saved for Later” section of the Shopping Cart. It’s my “intend to buy when I have time to read” list. Every so often I bump a few books into the Shopping Cart proper and buy them. The UI for the “Saved for Later” does not support searching or efficient browsing. Furthermore, when I look at a book listing, there is no hint if that book is already in my cart.

    Recommendation: Allow searching in a cart. When I make a change in the cart, it should not cause a full page reload, nor lose my place in the paginated list. Integrate the cart with book listings, such that a listing for a book warns me if the book is already in my cart. 

  3. Amazon maintains a taxonomy of books. It allows a user to “Browse by Category.” But many books are in the wrong categories. There is also lots of overlap. For example, The Black Swan and The Adobe Photoshop CS4 Book for Digital Photographers top the Computer Science category. The Adobe Photoshop CS4 Book for Digital Photographers tops the Software Engineering category under Computer Science. What?

    Here are the categories for Adobe Photoshop CS4 Book for Digital Photographers:

    1. #1 in Books > Computers & Internet > Programming > Algorithms > Digital Image Processing
    2. #1 in Books > Computers & Internet > Computer Science > Software Engineering > Information Systems
    3. #1 in Books > Computers & Internet > Digital Photography & Video > Adobe Photoshop

      In an earlier revision of this post, I accused Scott Kelby, the author, of cheating the system, because I believed authors chose their categories. I shouldn’t have jumped to that conclusion—this is entirely Amazon’s fault. 

DrProject,, and others

  1. Do not break my browser’s password-save feature. Please. In DrProject’s case, the login form is in a JavaScript popup, unlike every other website that has a dedicated login page. Firefox is clever enough to offer to remember the password, but alas Safari is not. just deliberately breaks password saving on its sign in page by specifying autocomplete=off in its form.

    I hate it when coders put effort into features that degrade the experience. You actually have to try hard and spend time to break the browser’s password-save feature. It doesn’t help anyone.


  1. WordPress recently redesigned their interface. Presumably they tested it and found some advantages. Yet they have ignored the #1 rule of human-computer interaction: Responsiveness is king. The new interface is noticeably slower than the old one. The old one was already slow.

    Responsiveness lets users make mistakes without consequences and therefore without fear. Responsiveness allows experimentation, which gives a UI discoverability. Responsiveness compensates for many other design errors. Responsiveness is the most important UI principle in the world. 

  2. If I don’t give a post a category, it is placed in the Uncategorized category. If I later give it a category, it remains in “Uncategorized” as well. This is wrong. Posts should only be in Uncategorized if they’re uncategorized.
  3. Switching between the Visual and HTML views of the blog post editor loses whitespace information. Whitespace operations should be preserved between the two views of the same post.

I don’t get REST

October 25, 2008

I thought I understood REST to mean “Name your nouns with unique URLs and use HTTP verbs to modify and access them.” I learned this through Ruby on Rails blogs and books when REST was the fad du jour. I remember thinking that all the explanations I could find of REST were too complex and that it was a simple idea at its core. I didn’t understand why the complexity was there but I didn’t think too much about it.

Along came an article from REST’s inventor expressing frustration at things being called REST when they don’t match his definition.

It appears that “REST” is a word with two distinct meanings. One meaning is as described above. I’m not alone, as others use the same interpretation. Roy T. Fielding holds the other meaning. It’s clear that there are deep ideas and subtleties in what Roy originally meant by REST. It’s also clear that Roy has difficulty communicating these ideas. Some evidence: The comments on the blog post, a link on Hacker News, Sam Ruby’s take. I certainly don’t understand Roy’s comments and I can’t even say whether or not Roy’s REST is actually coherent.

On Unsubstantiated Claims of Technical Superiority

October 8, 2008

From the Django Book, chapter 3:

… one of Django’s core philosophies is that URLs should be beautiful. The URL /time/plus/3/ is far cleaner, simpler, more readable, easier to recite to somebody aloud and … just plain prettier than its query string counterpart. Pretty URLs are a sign of a quality Web application.

(Emphasis added)

The Little Computer Scientist says: “No Longer Acceptable! Unacceptable!”