On mats, and cats, and programming

You are a teacher of C++ or any of a number of similar languages. You are marking an exam. The first question is, "Write code to add 1 to variable x."

Candidate A's answer consisted primarily of the following:

x = x + 1;

Candidate B had, by contrast:

x++;

I'm guessing, but I reckon the majority of examiners would find no fault with Candidate A's answer. They'd do that because by most standards, there is nothing wrong with Candidate A's answer. It means exactly what it was supposed to mean. It says what it was supposed to say.

Now; you are a teacher of English As A Foreign Language[1]. You are marking an exam. The first question showed a picture and the following jumble of words: "mat", "the", "sat", "cat", "on", "the".

The candidate had to "Rearrange the word jumble to match the picture."

Candidate A wrote the following:

On the mat the cat sat

Candidate B had:

The cat sat on the mat

I'm guessing, but I reckon the majority of examiners would find fault with Candidate A's answer. They'd do that because by most standards, there is clearly something wrong with Candidate A's answer. Although it means exactly what it was supposed to mean, and says what it was supposed to say, it's wrong. It's not how English is spoken by English speakers.

The difference is simple. In natural languages, idiomatic correctness is seen as being part and parcel of overall correctness and we don't stand for it when it is missing. By contrast, we seem to tolerate its absence in programming languages?

Why?


[1] I chose EFL instead of just English for my example, because lets face it, the more enlightened examiner may give more marks to "On the mat the cat sat" to reward its more poetic quality, a quality lacking in the idiomatically correct but more mundane, "The cat sat on the mat". But EFL is, sadly perhaps, more about simply getting on in English speaking environments than about writing poetry.

(Trying to do) Business in Canada

Over six months since my last post and what is it that gives me the kick in the pants needed to blog again? Not some advance in the field of chip verification; not an epiphany on how to spot future world class programmers from the way they play Plants versus Zombies. No, nothing so valuable. What's got me hitting the keys again is what always gets me hitting keys hard: government and how it can get in the way of Just Doing Business. I annoyed some people a few years back when I lobbed a few barbs at Germany for its anti-business funkiness. Well have a break Germany, cuz it's Canada's turn now, eh?

Enter Canada's Regulation 105. It goes something like this (subject to the usual IANAL caveat)

If a non-Canadian firm delivers a service to a Canadian client, then that client may be required by the Canada Revenue Agency to withhold 15% of their invoice payments, to cover possible Canadian tax. Now it's important to re-stress: the 15% withholding is merely provision for possible tax. In the case of a US firm, it is entirely possible -- likely even -- that if its affairs are in order (specifically, if it is not deemed to have a Permanent Establishment in Canada) it will be paying the relevant taxes back in the US and it simply will not owe any tax to Canada at all. In that case, at the end of the year, the US firm can submit a Canadian tax return and and request a refund of all the withheld money. But even though at the end of the day there may be no actual money owed to the CRA, 105 is still expensive, especially to the smaller company. Here are five reasons why.

Clouds of EDA

Todays DAC panel session on EDA and Cloud Computing was interesting and the ensuing discussion was fairly lively (I'm speaking relatively of course. it's a conference of chip design geeks; how lively do you think it could ever get?) But while cries of "The Cloud, The Cloud, My Kingdom for The Cloud" are all very well, I'm only going to get excited when I see some important enabling technology show its face first. Here are four:

1. Mobile apps. This is really what Cloud computing is all about. Sure you get to stuff your stuff up on Amazon, somewhere in, well, in the Cloud. But it's how you interact with it when it's up there that's important. You have a LinkedIn app on your iPhone? Or a DropBox one on your iPad? Well, you'll want a Regression Dashboard one too. 
2. Data Visualization Technology. It's already bad enough trying to wade through a jillion lines of plaintext logfile coming off one or two or five simulations. Imagine what it's going to look like when you have five thousand simulations running in parallel, the log outputs combining into a flood. I'm not just looking for a glorified grep I can run during a boring DAC talk (the Cloud one wasn't boring). We need new ways to look at and in other ways analyze simulation data. We don't, for the most part, know how to do that yet. People like Edward Tufte might. We should ask him. (Here at Verilab we already sent one of the team to do exactly that.)
3. Virtualization. Partly because the chip design environment is so heterogeneous (lots of different things as opposed to lots of things-the-same), partly because the EDA tools are not always as well-behaved citizens of the GNU/Linux environments in which the live as we'd like, and partly because it's not easy making a large number of GNU/Linux boxes behave in a sane and stable way anyway, the last thing we want to do is in anything like a manual fashion try to configure five thousand in-the-cloud servers so they are ready to run big chip sims. One way to solve this is to rely on virtual machines which are then cloned and farmed out to the farm.
4. Much *much* more robust GNU/Linux configuration. Even with the help of virtualization, that merely helps the scaling, You need a stable system in the first place. Unfortunately GNU/Linux sysadmin is often treated as little more than a glorified (if that) backup-tape-changing, email-fixing job. Its not. If we compare looking after GNU/Linux systems in a chip engineering environment to looking after financial systems, then too often GNU/Linux admin is barely at the level of book-keeping. What it should be compared to is the role of the sophisticated M&A specialist, or investment quant. The GNU/Linux infrastructure needed to design and verify a modern SoC is a significant piece of engineering in its own right, and it needs a significant piece of engineering brain power to run it. Every chip team worth its salt needs such a large-brained sysadmin. Verilab has one. If you don't, go get one. If you don't know what one looks like, ask me and I'll tell you. But a clue: if your guys aren't running Puppet, or something similar, ask why.

Of course there's more to it than even that. We'll want FaceBook "Like" buttons next to simulation output displays, and the ability to retweet a successful regression will be cool too. All of this is why, unlike what one questioner suggested at this evening's panel, "The Cloud" is much more than the same simple build-versus-buy decision we've contemplated for years. No; done right, Cloud-based EDA -- Cloud-based anything -- will be a game changer. Why else would Big Brother Steve be so excited about it, and Brother Richard so not?

Programming as Soulcraft

I'm always looking for "proxies for greatness" in potential new members of the Verilab team. It can take some time to find out if someone is good, because in the end "good" in this context means something like "consistently delivering desired results", and you can only see that over time. But there are clues early on that a person may be, or may become, good. Those are the P'sforG.

One is mentioned by philosopher-turned-mechanic, Matthew Crawford in his "Shop Class as Soulcraft". In chapter eight, "The Further Education of a Gearhead: From Amateur to Professional" he tells the story "Of Madness, a Magna, and Metaphysics" in which he takes on the task of bringing back to life an old and neglected-by-underuse 1983 Honda Magna V45. A key part of the repair was fixing the clutch hydraulics.

As he burrows in through the layers of grease and grime, he encounters a suspicious oil seal that he suspects is the culprit. But he can't be sure without a lot of extra work. This triggers a debate within himself as to the sense of digging into that oil seal when he knows he can perform a reasonable if temporary fix by simply focusing on the slave cylinder:

"It occurred to me that the best decision would be to forget I'd ever seen the ambiguously buggered oil seal. With a freshly rebuilt slave cylinder, the clutch worked fine. Even if my idle speculation about the weeping oil seal causing the failure of the slave cylinder was right, so what? It would take quite a while for the problem to reappear, and who knows if this guy would still own the bike by then. If it is not likely to be his problem, I shouldn't make it my problem."

Note that he's not idly trying to avoid work. His concern is for the client (who'll have to pay for the extra work), and for sheer economic sense in to the bargain. But there's more at work here than simple economics:

"But as I walked back into the fluorescent brightness of the shop, I wasn't thinking about the owner, only about the bike. I just couldn't let that oil seal go. The compulsion was setting in, and I did little to resist it."

It's that word "compulsion" that intrigues me. Only sentences later he mentions it again:

"There is something perverse at work here, and I would like to understand it. The oil seal was the opening to Pandora's box: I felt compelled to get to the bottom of things, to gape them open and clean them out. "

 Not money, not because the boss or client wants it. A compulsion, and thinking only about the bike. I agree with him; it's perverse, and I too would like to understand it. And his inner conflict, and outright guilt at the perversity of it is clear:

"But this lust for thoroughness is at odds with the world of human concerns in which the bike is situated, where all that matters is that the bike works... [The] more ... pragmatic view of the motorcycle ... grounds the fiduciary responsibility of the mechanic to the owner. In digging at that oil seal needlessly, I was acting out of some need of my own."

But if he didn't intend to be ironic there, he should have. And that's my point. It is the very compulsion he demonstrates that I believe is a Proxy For Greatness. I see it (and its sad opposite, a robotic lack of compulsion) all around in software.

The Proxy -- the sign you may be standing in the presence of programming greatness, or the potential for it -- is the tendency in some individuals to write clean, well-nigh poetic code not because it's useful (although it usually is) or reusable (ditto) but because they cannot *not* write such code. They are compelled to do so. They avoid, where possible, writing the same lines of code in more than one place not because a coding standard tells them not to, but because they are compelled to be succinct. Saying the same thing twice is icky -- it *feels* bad. Or they look on existing code, and cannot help but notice that those four "different" functions are really the same function. The itch to refactor develops, and may well become irresistible.

The correlation is not 100%. There are potentially fine programmers out there who don't have this instinct but can learn it. And I've met a few who go too far to the extreme, sacrificing all real concerns for an elusive platonic form of every program. But I reckon it's a very strong predictor. And I'd recommend erring on the side of too much of it than too little.

Verilab is hiring that kind of people in the field of chip verification. If you're looking for a place where Programming as Soulcraft is appreciated, where the beauty of a solution is part of its merit, and where you would be part of an elite team who understand the compulsion to Just Do It Right, give us a call.

Egnyte - update

So, a local person (well, US) called me. Turns out the latest local cloud client is busting something on Mac SnowLeopard. They gave me an older version and I'm now in action. Now I can start comparing.

Egnyte versus DropBox, or, No You Can't Login To My Machine With GotoMeeting!

Sorry but this isn't a comparison. If you want a comparison, go somewhere else for now. It might become a comparison, but it can't yet be one because Egnyte has fallen at the first fence.

The story so far. After quite a bit of diligence and analysis, and looking at lots of options, we settled a year or so ago on Dropbox for Teams for my company. I had a whole list of requirements but the primary ones were:

1. Fast local access to files (no having to download them from websites)
2. A regular folder-view of the local files, so my non-techie users felt at home
3. Secure in transmission and secure in storage

DropBox does all that, but there are a few things that I wish were different. I wish:

1. There was an option to lock files on the local copies so that you had to explicitly unlock before editing. That would give conflict resolution. DropBox isn't completely clueless in this respect, and it tends to "fail" safely by letting you know there has been a conflict (and giving you copies of the file in question). But it doesn't prevent conflict
2. There was finer-grained access control. For now it's an all-or-nothing control at any given shared folder (and children). I cannot give you access to: A, A/B, A/C but not A/D; while giving someone else access to A, A/B, A/D but not A/C. The workaround is to think carefully about your top level folder arrangements, but finer grained controls would be better.
3. You could have multiple DropBox accounts on a single machine. Many of my team have personal DB accounts, but also need access to our DB for teams account. Not easily done.

But despite those things, DB is pretty awesome. We use it constantly, and I like it.

But one thing arose today that made me go revisit Egnyte, which was one of our shortlisted candidates when we first looked about. I don't think we every disqualified it, we just had to make a decision and I went for DB. But today I found myself wanting to share a large file with someone outside the company who did not have a DropBox account (or a Google Docs account, which would have been an alternative). Asking on a local business support group I received the following advice (thanks Paul):

"We use www.egnyte.com as our cloud server and then can share files with end clients with links that require login, expire after X clicks, or expire after X days."

That got me interested enough to re-visit Egnyte and I noticed a bunch of other things that DB doesn't have. It appears to have the fine grained access control I'd like. Also it has lock-modify-unlock. Tasty. Now I don't know if it allows multiple accounts per machine -- I'm going to guess it doesn't. But if we used Egnyte for business, everyone could happily continue to use their own DB accounts for their personal stuff. 


So, rather than faff about with lots more reading I thought I'd go for a 15 day free trial of the "Pro" edition. I'll mess with it for a days, then let some of my team play. If we like it, cool. If not, no loss. The sign up and install seemed to be fine. I now have web access. But the local disk access is vital, so I downloaded the client and got it installed on my Mac. And the problems begin. Throughout the process I have only ever provided one password, so when I was sent to a web page to set my local cloud preferences and was asked for a password, I used that one password. I got the following message, "Change password to match Cloud File Server. Please re-authenticate."

Now exactly what does that mean? Does it mean that it wants me to change the password? Why? To what? I have only one password (and it works on the main Egnyte site). And what is the cryptic note below the "Save" button? And yes while I'd like some answers, wouldn't it just be better if the errors meant something to a normal user?

So it gets more frustrating. If I click on that "Contact Support" icon at the top right, I stay stuck on the page. In fact if I click on anything on that page I stay stuck there. Apparently you can't get support about not being able to login unless you are able to login.

Nest step, I find a phone number for support and call them. Couple of menu button presses and I'm at technical support. A message suggests I may want to raise an email support ticket (which they say may be faster) but I'm thinking this should be a ten-seconds-to-fix problem, so I decide to wait for a human.

I wait. The opening bars of "Morning Mood" from Grieg's Peer Gynt waft plaintively over my phone, which I have on speaker in case it takes them a few minutes to get to me.

I wait. I notice that their on-hold music is *only* the opening bars -- the first four to be precise.

I wait, and wait, and ... ah! You can always tell when you're about to get through because the on-hold music tends to step and you'll hear a phone ringing. My internal Pavlovian response is always a giddy, "It's my turn! It's my turn!".

But no, not this time. After a couple of rings, we're back to Morning Mood. First four bars. Again, and again, and again.

5 minutes. 10 minutes. 15 minutes. The frustration builds. Not only does the phone keep ringing, tantalizing me that maybe this time I'm through, but I am driven nuts by the lack of progression on what I used to, until now, consider a delightful melody. Curse you Egnyte phone system! Who would have known what solace, what relief, what homecoming Grieg had built into that 8th bar. It may be that his genius is only fully appreciated when you experience the mounting despair at being deprived of the precious B, G#, F# sequence and instead repeatedly get fed bloody bar 4 instead!

18 minutes. Right! That's it! I mail their "support" begging for a phone call. Simultaneously I get an email from one of their customer satisfaction people. So I copy him too.

19 minutes.
20 minutes.

The phone rings! It's a (650) area code, so it looks like the customer experience dude himself has come to my aid. Oh frabjous day! Callooh! Callay! But no. Oh, no. What I've experienced thus far is a mere taster for the despondency I am about to face.

Now let me pause to make one thing clear. No, two things. First, I am a foreigner with a funny accent. Second, I have nothing against Indians, and in fact some of my guys are from India and they're as smart as they come.

But when I heard that accent on the phone, my heart fell. Why, because I knew -- I could feel it in my support-line-wearied bones -- I knew I was almost certainly facing a Script Follower. And how did I know that -- from hearing the Indian accent? I'll tell you why.

Companies do not outsource support work to India because although it is not cheap, it is world class.

No.

Companies outsource support work to India because although it is not necessarily world class, it is cheap.

Now careful here of taking that through a post hoc ergo propter hoc fallacy and inferring that India implies low quality. This has nothing to do with India or Indian workers. It has everything to do with American (and European) companies saying one thing about support ("It's important") and doing another ("Is it crap."). In other words:

Companies outsource support work to cheap places because they don't really give a shit about support.

Anyway, I gave up very quickly as the support dude requested that I let him access my machine using GotoMeeting to solve the problem. I don't have a problem with that in principle. I don't think he's going to drop some trojan on me and then steal my stuff. In fact I think it and things like it are a fine way to provide certain kinds of support. But, acchhhh, I just cannae be bothered. I don't have time for that kind of thing. I'd already been on the bloomin' phone for 20 minutes, all I wanted was to hear someone who was sufficiently knowledgeable they didn't need a script. Fulfill that requirement (and speak English at least as intelligibly as I do -- not hard). Exactly where they live is not a concern of mine.

So, I've said it before, I'll say it again. Charge me more money people and stop relying on low-grade scripted people to fix stuff. Money is not the only thing I think about; the more you share my priorities, the more likely I'll buy your stuff.

Annoyances

The swapping of positions of "Open Link in New Tab" and "Open Link in New Window" in the right-click context menu in Firefox 4.0.

Recently created documents in the PDF "Open" standard that can only be opened in Adobe's reader, and only in the latest version of that, at that.

The fact that MS Office's installer in OS X is too stupid to kill OS X's software updater despite the updater being smart enough to start the installer in the first place. (It's not the fact that the installer can't handle it per se -- it's the "Sheesh, would you shut down the updater already!" way it sounds like it's blaming you for the problem.)