In these times of financial woe, people love to complain about all the big, nasty, faceless companies avoiding paying tax. They inevitably moan about it on Facebook, Google and Twitter (and sometimes even do something about it in the real, physical, world). But what about those companies themselves? The Web 2.0 behemoths are now some of the largest companies in the world, and they’ve decided – just like the evil old companies – that they don’t like paying all that tax. Don’t be evil… and don’t pay any tax if you can help it. But how do they do it?

The Numbers

An Irish Times newspaper article caught my eye the other day. It discusses the rapid growth of Facebook’s Dublin operation in 2010, whose accounts have just been published (as they must be by law, despite FB’s apparent reluctance). The headline figure is that:

[Revenue] is up from €15.2 million to €229.1 million

That’s a pretty significant increase! But that’s only revenue, how much of it was left over as profit?

Facebook Ireland generated a pretax profit of €1.9 million

What?! Where did the other €227 million go?

According to the article it mostly disappeared into a mysterious black hole known as “administrative expenses”:

Administrative expenses increased … to €221.6 million as a result of … royalties paid to other Facebook entities for services provided during the year.

How do they do that?

Is it me or does that sound suspicious? Well, it should do, because it is.

It turns out that Ireland’s significantly lower rate of corporation tax (12% vs 26% in the UK, and one of the lowest in the world) isn’t the only reason why companies like Facebook, Google et al move there. There’s also the very useful fact that, unlike most developed economies, Ireland chose not to introduce any legislation to prevent companies siphoning off their revenue to low-or-no-tax regimes like the Cayman islands or Bermuda.

So that’s where the “missing” €221 million has ended up: it’s been paid from the Irish part of the business to the tax-haven subsidiary, leaving only a small amount subject to corporation tax in Ireland. This practise is known in tax circles as the “double Irish”, and it (along with its Dutch equivalent) seems to be fairly widely used and well understood, even having its own wikipedia entry. Of course Facebook now funnels as much as possible of the revenue from the UK (its second biggest market) through the Ireland operation to get the most out of this arrangement. That explains the large increase in the numbers since last year.

There are many high-profile tech companies that have Dublin operations and may be avoiding tax in this way, including:

• Facebook
• Twitter
• LinkedIn
• Google
• Microsoft
• Oracle

That’s quite a roll call.

The Result

The result of all these shenanigans for Facebook? It pays a ridiculously small effective tax rate of less than 1%, even better than Google’s 2.4% rate. And given Ireland’s current economic state I can’t imagine their government will be introducing more restrictive tax legislation any time soon in an attempt to crack down on it. They can’t risk these big companies abandoning their new homes in Dublin’s Silicon Dock.

Of course, you should feel free to ‘like’ this blog post on Facebook, after all, what will it cost you?

(* Disclaimer: These are solely my opinions, not those of my employer or anyone else).

Dark Days

We should bear in mind that in some camps, C++ never went away. The financial, scientific and games programming communities have bravely kept the fires burning.

Why? Primarily performance. In these industries performance is a feature, it’s a key differentiator, and it will help you make money. Can you say the same for an enterprise app (there I go, using that term disparagingly again) that just displays a form interface over a relational database?

However, even in the C++ bastions, the language was getting a bad press. I can only speak for the finance industry, where I’ve been working for the past 10 years, but even here the focus briefly switched away from raw performance to complex (overly-complex, dangerously-complex, as hindsight tells us) trades where getting to market first with something new was key: developer productivity was key. Flexibility and generality was key.

In that case, you don’t want to be dealing with the vagaries of subtle errors, crashes and memory leaks that can easily creep in when you’re using a language as low-level as C++. You just want to be able to release quickly. You probably want to be using a managed language.

In fact, C++ was getting a bad press all over. The functional power that was provided in languages like Haskell and F# – and being hastily added to C# – was missing or awkwardly implemented in C++. The provision of things like the .NET thread pool provided programmers on the CLR an easy way to schedule asynchronous tasks, and it was being touted as the only way to survive in the highly-parallel near-future. Of course, it was possible to do this stuff in C++, it was just more difficult.

Despite this, the programming community widely understood the power that C++ brings, but also that it has to be wielded carefully. Witness the oft-repeated jokes about the fact that when you shoot yourself in the foot with C++, you tend to blow your leg off. There were even tensions within Microsoft, with the pro-managed DevDiv vs the hardcore, native-favouring Windows division.

The New Order

So what’s changed? Herb Sutter’s recent talk covered many of the reasons why C++ is relevant again, and the most obvious reason is the emergence and importance of mobile devices and data centres.

They have a completely different set of requirements than the desktop: they focus on squeezing the best experience out of every available cycle (and corresponding minute of battery life), and the most performance out of every watt of data centre power per degree of cooling. We’re seeing the impact of the smartphone in your pocket and the data-centric web and social media reflecting back onto the languages we use to write software.

Managed languages fall down in some important areas here. They sacrifice memory efficiency to the god of garbage collection and they offer fewer opportunities for aggressive compiler optimisations, including, in the case of .NET, making use of chip-provided performance features like SIMD instructions.

Nowadays in more and more of the computing industry, it’s the hardware that’s driving the development choices, not the other way around.

With resource-constricted platforms, you want to be doing more of the heavy lifting offline, at compile time, not at run-time with a JIT compiler.

How the iPhone showed devs don’t care

While (parts of) Microsoft were busy pushing the managed languages hard, Apple was quietly producing game-changing pieces of hardware that the device-carrying public were buying in their hordes. And they weren’t just buying devices, they were buying apps to play on these devices – in their millions. Lots of developers wanted a piece of this action but – quelle horreur! – You had to use an obscure variant of C to create them.

But – surprise, surprise – developers did it anyway. Luckily, they weren’t on their own, but this time rather than a managed runtime, they had an API to use. And they had to use it; it was, and is, literally a condition of sale that your app uses only the APIs that Apple provide and in the way that they intended. Whatever your view on the fairness of this approach, having a restricted surface area and well defined set of libraries helps developers win back some of the productivity they might otherwise have sacrificed by using Objective-C.

Microsoft must’ve been looking askance at this, wondering how Apple had so effectively switched the model around. MS had been based on the idea of developer productivity being king and the hardware being utterly insignificant. Now developers were writing code in a language that was broadly derided by people in the programming community, yet they were in a virtuous circle where writing apps helped to ship hardware that increased the market for their apps.

We need libraries

Is it possible to find a good balance between the raw power of C++ and the productivity of managed languages? I think it is; and partly it comes down to having a good set of libraries. When I say good, I mean consistent, relevant, well-documented, easily available set of libraries. Can you see where C++ may have struggled here before?

For the low-level, programming task oriented basics, Boost is the answer. Seriously, Boost always seems to be the answer to questions of “how do I do X in C++?” where X is a modern programming technique. Smart pointers, lambdas, higher-order functions… they’re all there.

A few years ago if you were working in C++, you didn’t have many options apart from vanilla STL, Boost, and writing-it-yourself (again). Now, the STL and the language itself is richer and anecdotally, organisations are more receptive to the use of Boost. So hopefully, this combination gives us back access to most of the functionality that’s available to managed developers in their pre-packaged base class libraries.

C++ and Apps

But how is that going to help people use it to produce compelling apps and “experiences” (cough) and specifically, how is Microsoft going to use its developer productivity nous to keep Windows relevant in the new hardware markets?

They need something else; something like the Apple Core frameworks. It looks like this is what Microsoft is talking about with Windows 8 and the Windows Runtime. It’s suddenly not embarrassed to admit that, hey, Windows itself is written in C++, so maybe you shouldn’t have to go through a managed ‘interpretation’ of the existing APIs, one that’s exclusively available to managed languages.

Of course, Microsoft can’t do anything as radical as forcing all developers targeting a mobile or tablet platform to use C++. For them, programmers, rather than any particular hardware, are the bread-and-butter, so they tend to have a slightly less dictator-style relationship with devs than Apple does.

Judging from what I’ve seen from Build, Microsofts chosen approach is to provide language-specific “projections” (their term) from the Windows Runtime layer into a variety of languages, including C++. The native C++ types are mapped into corresponding concepts in the vernacular of the higher level languages; Javascript, C# etc. They’ve gone to some lengths, it seems, to ensure that transitions between levels are efficient. Using C++ at both levels should be the fast path, and of course you can mix it freely with code that, for example, uses Boost or other C++ libraries.

Additionally and importantly, as well as basic types, collections etc, the Windows Runtime also contains all of the rich APIs for accessing app-level functionality; things like image capture, sound and geolocation. So suddenly, all of this stuff is available in all its glory directly from C++ – and other languages too via cheap bridges. What they’ve essentially got is an identical copy of the architecture that exists in the iOS world, while still attempting to keep non C++ developers on-side.

The Return…?

So, have Microsoft managed to bring C++ in from the cold? They seem to have admitted, at least to themselves, that developers will need to use it in order to effectively target some platforms, and they’ve used their tooling experience to make it look and feel like a managed language in their IDEs, as well as leveraging their compiler technology to do some additional useful performance tricks. It feels like C++ was a fundamental concern in the redesign of the new alternative to the creaking Win32 API.

But will the transition be something to make current developers switch to C++, especially those who’ve been used to living in the cosseted managed world? Perhaps, if the Microsoft-based tablet market becomes as compelling – read, large – as Apple’s. Otherwise I don’t see any reason why developers who don’t have specific platform or other runtime requirements would move; for the majority of environments, developer time is still the dominant cost, so developer productivity will still be paramount.

The gap between managed and unmanaged languages has certainly narrowed in that area, but it still exists. C++ is still proving surprisingly relevant, despite its 30+ years, and hopefully its use in new and different areas of computing will feed back into improvements in the language and libraries for everyone’s benefit.

How can you screw-up creating an electronic version of an existing sign?

Here’s the offending item:
It’s a replacement for a combination of magnetic labels and hand scrawled messages that convey the current state of each of the London underground lines. They’re generally one of “good service”, “minor delays”, “severe delays”, or “oh no, you’ll never get to work”.

For the majority of people, their only interaction with this system is walking past, early in the morning, when they’re not at their sharpest, and trying to figure out if their tube line is working. As such, if there was a magnetic label stuck on your line, you knew things weren’t good. Given the lines themselves are colour coded, it’s easy to determine which line you’re interested in. Bear in mind that people aren’t going to get closer than about 2 metres to the board.

And herein lies the problem: by replacing the analogue board with a digital version, it’s no longer possible to ascertain by the physical presence of a label or writing, what state the line is in.

Let me say that again. It’s virtually impossible to tell, even from relatively close, if there are delays. Take a look at that screenshot (dodgy quality as it is) and see if you can tell which line has “minor delays”. Yeah, not easy is it? Now try doing that as you’re briskly walking past at 7.46am.

Underground line status (detail)

I’m surprised that they’ve relied solely on text and haven’t used any other means of distinguishing the significant information. Some other things that could’ve been used:

• Colour (of the text itself, the background, or some indicator. Need some inspiration? How about taking a look at something way out there, like, say, traffic lights)
• Size
• Weight (using font weight to indicate relative importance)
• Icons (or some other kind of visual indicators, nothing flashy)

I’m sure there are a whole load of advantages to having this digital system; most notably that it’s connected, and can be automatically and centrally updated. If only they’d spent any time on thinking about how people were actually going to use it!

Harry Beck would be turning in his grave.

A quick google reveals some of the funny, interesting and downright weird things that people have compared programming to. Let’s take a closer look at some of them…

The Classics

“Programming is like sex”
The most common version of this is, of course, that “One mistake and you have to support it for the rest of your life”. Very true. Unless you can manage to change jobs every six months, and then it’s more like “You can have lots of fun and then leave somebody else to clear up the mess”. There are lots of other variations too, including the controversial: “Sometimes you have to pay a lot of money to get someone who’s good at it”.

“Programming is like LEGO”
Hmm. As far as I can see this just means that, yes, you can put the pieces together in any way you like, but nothing you make will look quite as good as the thing you make by following the instructions. The impression of infinite freedom is an illusion. And if you’re not careful you’ll end up losing important bits down the back of the sofa or hoovering them up.

And, hang on, if it is like Lego, then how come we’re always talking about programming “glue”?

“Programming is like chess”
Not sure about this one. The biggest similarity I can see is that a lot of Russians are quite good at it.

Or maybe you could compare the interminably long games with the average duration of an enterprise software project? In fact, maybe having a chess clock would make pair programming more fun; you get 30 seconds to write a line of code before it’s the other’s turn.

The Outliers

“Programming is like Ice Sculpting”
What?! This has to be one of the most bizarre comparisons. I mean, yeah, it makes my hands really cold too. And my coworkers keep asking me why I bring that razor-sharp ice pick into the office on code review days.

“Programming is like a dream”
Unfortunately sometimes it’s like a really bad dream, the kind that you get from falling asleep on your keyboard during your afternoon sugar-low, dribbling on your mouse and getting an imprint of the enter key on your forehead. The kind where you wake up screaming after a nightmare about finding a bug in a 600-line long function with one-letter variable names and no comments. Only to find it’s not a dream after all, but where you will spend the majority of your waking hours for the next six months.

But of course, it can also be the kind of dream where you’re so far in the zone that you feel like you’re flying, effortlessly gliding over the terrain, appreciating the bigger-picture before swooping down into the details and watching how everything meshes beautifully together. Ahhh.

But it’s probably not the, erm, y’know, other type of dream.

“Programming is like an adventure game”
Yes indeed. I often find myself having to go back over ground I’ve already covered, in order to perform repetitive and mundane tasks purely so I can level up (I think it’s known as “getting promoted”).

Sometimes I think that compiler writers treat their error messages as some kind of sadistic text-based game:

You are in an open field west of a big white house with a boarded front door. There is an unterminated string constant to the west, and an undefined external symbol to the east. There is a header file on the floor in front of you.
> include header
You include the header. You are in a forest with incredibly long STL error messages all around.


On a serious note, I think part of the reason programming is so difficult to pin-down is because it requires such disparate skills; a combination of creative, intuitive right-brainedness and the logical, analytical left. People can take a lot of different things away from it depending on where they start from.

Anyway, that’s my selection of gems. Got any other interesting ones?

But what they seem to have missed is that something very different, but equally significant, has replaced it: the instantaneously-shared TV experience, enabled by Twitter. With the omnipresence of laptops, broadband and Twitter, the sofa’s now connected. It’s possible to sit at home on your own and discuss, berate and dissect whatever’s on RIGHT NOW.

Most of us have experienced shared TV viewing at some point in our lives. People my age would’ve probably sat in the living room with their parents, before every kid over the age of 6 got a TV in their bedrooms. Shared living, like student accommodation, is also a common way to experience it. As we get older our social circle tends to shrink, and television watching can become a more isolated affair.

Of course, the “old” ways of discussing TV still exist; we still enjoy vitriolic printed reviews in books, newspapers and magazines, we can still call someone and discuss a program over the phone. But these off-line methods are bandwidth-limited (we can only call one person at a time), slow (with a lead time of days or weeks for printed media) or uni-directional. Fundamentally, they lack immediacy.

In contrast Twitter enables us to connect with lots of people simultaneously; lots of people who are all sharing the same TV experience. It’s like having a load of sarcastic, funny mates in your living room. Ones that you can get rid off just by closing a laptop lid.

I’ve identified 5 major groups of TV twitters:

Schedulers
These helpful individuals post tweets about things they find interesting and are intending to watch themselves, normally along the lines of:
Guy Richie's Revolver is starting now on Channel 5 - the most confusing film I've ever seen!

The usefulness depends on the type of people you follow and on where in the world they are. @aplusk and @courtneylover79 are not going to be posting much about what’s on BBC 1 on a Sunday evening.

Crowds
This accounts for the vast majority of people twittering about telly. They tend to congregate around large “event” programmes, Eurovision, Derren Brown, X-Factor etc, or geek-oriented watching such as Charlie Brookers recent (and excellent) Gameswipe. Of course any reality-TV type programme presents significant opportunities for Twitter-enabled sniping. We all know how much the internet loves this kind of “look at that!”, “lolwut”, “OMG!”, “loozer” stuff, but it’s often combined with genuinely funny material too.

Hangers-on
This groups consists mostly of spammers, and people outside of the country where the program is being broadcast. They spot trending hashtags and either piggyback whatever they’re selling onto it, or tweet something along the lines of “What the hell is #nnn…?”. They don’t add much. Enough about them.

Celebrity Friends
If you follow celebrities* – and lets be honest, who doesn’t? – the chances are they have some friends. And celebrities friends are quite often celebrities themselves (keep it in the family, eh?) so you’ll often see tweets like:
my friend on bbc2 newsnight right now! go sister!


Try to contain your excitement. Unless it’s you of course, and then you’re welcome to tweet OMG!1!! I'm on TELLY!!
(* of course, by celebrity I mean anyone with more than 500 followers).

Commentators
Some twitterers take it upon themselves to provide blow-by-blow, often eloquent and vaguely fantastical coverage of certain programmes. This can feel like having someone on LSD on the sofa next to you whispering in your ear. So probably not for those of a sensitive disposition.
Gregg keeps saying "I would happily eat that." To be fair, he would happily eat an old Big Mac out of a tramp's shoe.

This type of companionship can brighten even the most mundane viewing. It tends to be the product of “resting” writers or comedians, writer\comedians, or comedian\writers.

Will TV ever be the same again? For me it won’t.

(The @names have been changed to protect the innocent. Well, some of them…)

1. Exclamation marks in dialog box messages
Look, it’s probably the 50th time I’ve seen this message today. The fact that this application “Cannot connect to database!” is no longer a surprise. You may have noticed that most professional software uses a neutral tone for its communication with the user. Try that. Also:
1a. Double negatives in confirmation dialogs
“Are you sure you don’t want to lose your changes?” Err… what? No. I mean YES. Oh sh*t. Any dialog that requires you to stop and try to parse the question in order to work out if you’re about to destroy several hours of work is not doing its job. It’s getting in the way of you doing your job. In fact, convoluted messages are such a serious issue that Microsoft even tried to help developers to help their users by introducing a whole new kind of dialog box in Vista: the question/task dialog. Good luck with that.

2. No tab ordering defined\mouse only navigation
Because no-one’s ever going to use the keyboard to navigate the zillion controls in your data entry app, are they? This one actually surprises me, because I’d have thought that developers would’ve needed to navigate quickly through the application while they’re writing it. Well, that doesn’t seem to be the case. Pretty much all commercial apps are good counter examples. I don’t mean to hold up Microsoft Office as a paragon of UI virtue, but they definitely do the “alternate way of navigating everything” thing well. Everything you need can be reached by both keyboard and mouse. Unplug your mouse and try that with your favourite piece of in-house software and see how you get on.

3. Group boxes around everything
This is a bit of a WinForms specific one. The clue is in the name: group boxes are for grouping logically related controls, not for providing a kewl recessed border around every single one of the controls in your dialog. Don’t kid yourself that this is doing anything other than using up some valuable screen real estate. (See if you can spot another pet peeve in the example dialog, too).

4. Icons created in the IDE
Look, Visual Studio’s a really good integrated development environment, but it ain’t no Photoshop. Don’t try and use it to create icons. And while you’re at it, please don’t make icons consisting solely of the name of your application (inevitably an acronym) in pixel font and primary colours. Oh, and don’t just steal various icons from another application, unless you’re going to steal the whole lot; one of the key visual aspects of a good UI is consistency. Mixing your hand-drawn 4-bit icons with the glorious 32-bit shiny ones you borrowed is going to be jarring. In fact, why not go the whole way and get someone who can actually draw to create your icons for you? After all, you wouldn’t have someone who wasn’t a programmer writing the code, would you…?

5. Data grids
Otherwise known as the “Excel is the pinnacle of user interface design” disease. Break the habit. Generally, the more types of controls that are embedded in your grid, the less likely that it’s the right kind of interface paradigm. Yeah, I’m looking at you, person embedding a calendar control, drop down box, graph, slider and checkbox in each row of a data grid. And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.

6. Not implemented message boxes
Ahh, the GUI equivalent of source code TODO comments. Of course, it’s an in-house software give-away; no commercial (desktop) software would be brazen enough to ship with bits of functionality dangling from the stumps of buttons and menu items. Would it? Feel free to provide counter-examples if you have them.

7. Excessive use of dialog boxes
Warning: dialog boxes are considered harmful (to usability). They’re the equivalent of restraining your user by force and preventing her from moving until she answers your question. That might be OK for matters of life or death (i.e. data loss), but not otherwise. Every time you find yourself about to add a new message box, stop, take a deep breath and consider whether it’s really necessary.

So, if you’re a victim or one, many, or all of these user interface faux pas, all I can say is: sorry. I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins.

Why? Well, because it’s too easy to use them as an excuse for not defining your shared library interfaces properly.

The reason this is on my mind recently is that several hundred, yes, you heard that right, several hundred DLLs have been released by my group over the last, ooh, 10 years or so. They are all still in use. Each of them has burned into it a copy of the library that deals with interfacing with Excel. That means each of these has it’s own little internal copy of the current state-of-the-art. The problem with that is; the state-of-the-art moves on. And how do you go about updating the DLLs that are already in production? You have to re-release them. In an environment where thes DLLs are used for marking the profit and loss on a large derivatives trading book, that’s not a small undertaking. And it’s made worse if, say the DLL in question was last released with a different version of the compiler.

My approach would be to refactor this shared static library (.lib) into a stand-alone DLL.

At this point, people start saying “oh, but then you’ve got a single point of failure, if you release a broken version of that DLL, everything will stop working!”. Not exactly a compelling argument. If the functionality of the DLL is well defined, and there are well known entry points it should be easy to put together a comprehensive black-box test suite. In fact we already do that with all our other DLLs (COM servers). The fact that this shared library *isn’t* a DLL has meant that it’s fallen through the testing cracks; another good reason to refactor it.

The internal interface to the shared library is already relatively well defined. It has a set of header files that define all of the functions and classes that are consumed by others. It’s a relatively small step to compile it as a DLL, rather than a static library. The problem then becomes one of maintenance, dealing with the inevitable changes to the external interface in a backwardly compatible way.

And that’s the problem. It requires some effort. Elsewhere in our codebase we use COM as a magic cure-all for avoiding having to deal with versioning: interface immutability rules. All interfaces are public, no published interface ever changes, object identity is based purely on interfaces supported. If you haven’t got these crutches to rely on, then you have to enforce the rules yourself, which can be both logistically and technically difficult when you’re dealing with C++.

But it’s not impossible. And I really think it would be better than having hundreds of DLLs all containing subtley different versions of the same code, and being unable to change behaviour across the board without having to build, test and release them all.

Maybe you’ve got a different opinion?