Forecast: Cloudy

So everyone is talking about cloud computing. Too bad most of them don't understand what it is, how it works, the benefits and pitfalls. Let's make it clear: with cloud I mean some kind of service or application that runs outside your network, is multi-tenant and scalable, and that you access over the Internet, ideally over HTTP. Accessing your on-premise mail server via a web browser is not cloudy, Google Apps is.

Anyway, the real point is not whether the cloud is useful, reliable, cost-effective or cool. The point is that it's inevitable, at all levels.

If you're a consumer, you're already using it, and you might not even notice it.
If you're a non-IT enterprise and are not using the cloud already, then you'll soon be because your partners, customers, suppliers and competitors will make the switch, and you'll be forced to conform.
If you're an IT company, then... well it's up you to decide whether to provide cloud-based solutions. I guess you are already because many of your customers are demanding it.

Some food for thought: cloud-based solutions are moving complexity from the end user to the supplier, which is great, but also calls for unprecedented software architecture challenges. And weird data migration projects.

That "CEO Friday" Post

In the last few days there has been a lot of discussion about this post by the CEO of Expensify, explaining why .NET developers tend to be somewhat dumber than others because Microsoft's tools make it easier to bang out a working program with all bells and whistles.

I'm not going to argue on that, even if I'm a .NET developer, but I can't avoid to observe that that single blob post has created thousands (or perhaps millions) responses, comments, tweets over the whole Internet.

Well, I call that a successful marketing campaign. Now pretty much everyone on the planet working in IT knows about Expensify.

My Take On The .NET Reflector Story

Quite a while ago Lutz Roeder transferred (sold?) his free .NET Reflector project to Red Gate. The point is not him transferring the project to Red Gate. That was a wise move and I believe he made quite a bunch of money which he deserved, because the tool was excellent (BTW, Lutz now works for Microsoft - if you want to get noticed by cool companies, build something awesome and give it away for free).

The problem is that Red Gate, a couple of months ago, made .NET Reflector a commercial product. To make things worse, the .exe self-deleted itself after users refused to upgrade to the paid version. That is, to put it mildly, outrageous.

That produced at least two results:

  • developers are enraged to Red Gate
  • a number of free alternatives, many based on Mono, popped up in no time (mushrooms come to mind).
I perfectly understand that a company must generate revenue out of a line of business, and that was the official reason why Red Gate made .NET Reflector commercial, but that decision was, in my opinion, bad on so many levels for the entire company:
  • Red Gate's customers are developers and developers tend to be extremely egocentric and paranoid, and won't forget about even one single bad decision
  • I guess Red Gate is not selling that many licenses of .NET Reflector because of the free alternatives (free+mediocre wins 99% of the times over paid+excellent)
  • sales of other products have possibly decreased a bit
  • to justify the price tag, Red Gate had to bloat .NET Reflector with some mostly-useless features, which affect the original simplicity of the tool.
Or perhaps I'm wrong and Red Gate is making tons of money.

[Note to Self] Forcing Firefox 4 to Save Open Tabs on Exit

Firefox 4, released today, does not seem to ask to save open tabs when shutting down. It always asked that in version 3.x, so I consider this a regression. To restore the previous behavior:
  1. Navigate to about:config and accept the warning
  2. type quit in the filter box
  3. Make sure that the browser.showQuitWarning key is set to true.
It's surprising how Mozilla slipped on this seemingly trivial setting, which should be enabled by default. On a related note, very much like in Google Chrome, you can now pin tabs as Apps (right click on the tab, Pin as App Tab).

The Common Assumption That Building Software Is Easy

Colorfultext

So you build software, and every time you meet someone who does something else, like pharma, building software becomes like playing with Lego (with all due respect to Lego, which is awesome). It's seen as a kid's amusement. After all, who is playing with colorful text all day? You (and me).

Sure, curing cancer or designing rockets feels harder than building software, but the truth is that it's as complex.

Building software means dealing with math, logic and abstractions. It requires good memory and the ability to think inside and outside the box at the same time. It demands a good understanding of electrons, principles of user interface usability and everything in between.

Take Facebook. Many think it's a toy, the reality is that developers at Facebook struggle every single day with tough challenges like, uhm, handling terabytes of data on 60,000 servers while 500 million users hit them with thousands requests per second. That's way far from being easy.

</rant>

TechHub London

Techhub-london

Last Wednesday I visited TechHub London, a sort of social IT/web startup/entrepreneur incubator. The place is quite spartan, but its purpose is not being cool, but being useful to its users. It has a main shared area where members just drop their notebooks and work, network and share ideas. Another area is reserved to some selected startups.

The shared area idea is not new, however the TechHub implementation has some interesting aspects:

  • sharing and networking is encouraged (much more than in normal incubators)
  • every Friday afternoon there's a sort of pitch slam that is also streamed live
  • coffee is free (yay!)
  • there's a symmetric 100 Mbit/s Internet connection (double yay!)
  • you get exposure to investors.

There are some downsides too:

  • you can't talk too loudly or for too long, or you'd bother other people
  • there are no whiteboards there are whiteboards in meeting rooms, but obviously you cannot bring them away with you!
  • you must work with your laptop (and I'd hate it - I want a terrific machine with lots of screen real estate).

I would not consider TechHub (or The Hub here in Milan) a startup incubator, as the term implies something that makes you grow as a business. It's more like an idea incubator, where you should spend time exchanging ideas and views with peers, hopefully growing as an entrepreneur, developer, geek. Perhaps that's the entire point.
When you must focus on business other than mere ideas, I believe a proper startup incubator is probably better. Actually, a mix of the two would be best.

Metawork

There's nothing worse than metawork, or work and tasks that are necessary for the real work to go on.

The thing that drives me crazy is that metawork is intrinsically able to multiply itself. When you're almost done, something new pops up, in an endless sequence of paperwork and phone calls.

Understanding Developers: An Insider Look

Developers are easy to manage. You just shovel intriguing problems towards them, and they're fine. They just don't want to even hear about anything else (professionally speaking, at least). I'm just like that.

We developers tend to have two different functioning modes. The first is called, more or less by everyone, The Zone. Whilst we are in this mode, we write 10 kloc per day and we seldom take breaks.

The second mode is much different. I'll call it Brainstorming, but the word doesn't really describe it in full. Brainstorming happens when a developer has an idea and starts building some structured plan around it, preferably taking peers on the discussion (possibly disrupting their Zone). This usually involves drawing on whiteboards (and windows when whiteboard space is completely used), talking loudly and simply assuming that users will love it, how-can-they-live-now-without-this. It's almost crazy, but it's when the magic happens and sensational things come to life. (BTW, if your developers are not like that, then you're in trouble.)

The problems start when your company is mostly run by developers (like mine) and non-developers never take part to Brainstorming sessions because, well, they're technical discussions. They'll not understand why a particular feature ended up in production, or another one was removed. Or what the entire product you're building is about.

The main point here is that Brainstorming can start at any time, without any advance notice. It could be at 8 in the morning, or 6 in the afternoon, or at lunch. And you can't stop it, or plan it, or repeat it, because it just doesn't work like that. It's a passionate, down-in-the-guts, collective thing. You just have to be there, otherwise you'll only see the final results. Which are seldom perfect, and that's the entire point in being there too if you're not a developer and want to have a word in what's happening.