Category Archives: Geek Culture

Developing as a Contractor in Belgium

My experience

As a software developer, I have been freelancing since 2010. Before that I was an employee for a consulting firm for 5 years. And one of the things that pushed me over the edge was when I found the invoice my employer had sent to the company I was consulting for at the time in the office printer. It said they “sold” me for 650€ per day, 13000€ or more per month. Given the fact that my net salary was 2500€ per month, and even if you factor in all the taxes and social charges and all the other benefits, that was still quite a huge gap. And in addition to that, I was not free to buy the car I wanted or the laptop I needed. When I needed vacation, I needed to factor in the “loss” for my employer. And when I wanted to attend a conference somewhere, I had to ask for permission. And I’m not even mentioning all the things I had to agree with (company pension plan, eco-cheques, etc.) that had simply no value whatsoever to me, but I was forced to take them because they were fiscally interesting for my employer.

For all those reasons, after talking with other freelancers to carefully evaluate the risks and constraints of having my own management company, it appeared obvious that it was the smart move given my experience. And the thing is I’m not the only one to make the same calculation. I know plenty of senior developers who have quit the rat race, stopped being an employee and taken matters into their own hands. Sure it’s a lot of administrative pain, with the accounting and all. Sure every letter you receive from the SPF Finance (tax services) makes a shiver run down your spine. Sure it’s stressful to have to find your own customers, deal with contracts, plan ahead for your periods of inactivity, negotiate your rate for each contract… but that is nothing compared to the incredible freedom you get. Being able to choose your customers and projects depending on how much you need to work. Being able to choose how you pay yourself, how you train yourself, the tools you work with. All of that is really satisfying.

The ecosystem

That being said, when you are a freelance developer, there are 3 big kinds of customers in Belgium (and I guess in a lot of other areas):

  • The big corporations, banks and public institutions (European Parliament and Commission) usually have framework contracts and Preferred Supplier Lists with big consulting consortiums and firms that force you to go through intermediaries who take a 15 to 30% cut on all your invoices, no matter how long the contract is, and often for very little added value other than access to those customers.
  • The small companies are the most flexible and you can usually work with them directly, but they are the hardest ones to find and you have to negotiate a lot with them.
  • And then there are the startups. When you are in the ecosystem, they are quite easy to find, you can also work without intermediaries, the projects are by far the most interesting ones, and you get to work in really cool teams. But that’s where the funding is often the most fragile (“no I can’t pay my bills with shares in your non-funded startup”)

The fears

Recently though, I noticed a really disturbing trend with startups refusing to work with freelancers, mainly for a few reasons:

  • Most are afraid that a freelance developer will be less “involved” in the success of the company
  • Some even fear that a freelance developer will combine several customers in parallel and thus will devote less energy to them than an employee, as if freelance meant part-time
  • I recently heard companies being afraid that freelancers would have a harder time integrating into their team
  • And I’m sure some really look at the cost and think a freelancer costs more than an employee

The reality

It’s hard to know where these fears come from, but let me bring some counter-arguments to those.

First of all, when you are a freelancer, your very ability to find work and the best work depends solely on your reputation. You can’t hide behind the reputation of a consulting company or the manipulation skills of your business manager. It’s just you and your awesome work. If you leave a customer on wrong terms, if your work is not impeccable, and if your involvement is not up to par with your customer’s expectation, no employment code, no firing cost, no prior notice is there to protect you. If you don’t show dedication, you will get fired, fast, and your reputation will suffer, making it harder for you to find a new mission in the future, especially in the startup world where everybody talks with everybody.

Second of all, most freelance developers I know hate switching between projects at the same time. It’s very inefficient and frustrating, so most of us prefer working for months or even years for one customer at a time.

As for integration time, it is of course completely the opposite: when you have to change project on a regular basis, you have to get comfortable finding your place very quickly in a new team. Practice makes perfect.

Last but not least, about the cost issue, most companies, especially the smallest ones for which economies of scale are really small, only consider the salary cost. They don’t factor in the management cost of dealing with social secretariat, car leasing companies, medical insurance companies, training companies, buying and maintaining your own hardware inventory and so on. In my experience, unless you are a big company and you can make big economies of scale on these management costs because you have a lot of employees, there is little to no difference in terms of cost between an employee and a freelancer. In addition to that, you also have to factor in the cost of firing an employee with a lot of seniority, or keeping him around despite your non-satisfaction with his work because of this cost.

The benefits

But more importantly, I see plenty of companies neglecting the benefits of working with freelance developers.

  1. By definition, they have to manage their own company, find their own customers, negotiate their own contracts, so entrepreneurship is at the heart of everything they do. They understand what it means to manage a business, and they don’t expect to be told what to do: they take initiatives and think creatively.
  2. They come with an all-inclusive package: no need to worry about company cars, vacations, insurances, gear renewal costs or training. All of that is taken care of by the freelancer himself.
  3. If you are not happy with their work, or your budget constraints change, or simply your needs evolve, you can stop the contract very easily. Agreed, it’s the same on the freelancer’s side, so you’d better offer him the best working conditions possible to keep him around, but that shouldn’t be an issue, should it? ;-)
  4. Given the importance of their reputation and the desirability of their profile, most freelancers train on all the latest trends can bring some really cutting-edge tech to your company.
  5. A key asset for any freelancer is his professional network. So he knows a lot of developers, which can be incredibly powerful when you raise a new round of funding and need to grow your team quickly.

In addition to all those reasons, considering the fact that most experienced developers have already made the switch, if you don’t want to work with freelancers, you cut yourself from an important crowd of some of the best developers around. And don’t expect to bring freelancers back into an employee status: given how much it costs to kill a company in Belgium, and all the freedoms he would have to give up, I know very few freelancers who would come back to being an employee. It’s simply not worth it.

The future

As a futurologist, I also feel the need to mention the fact that in my opinion, the employee status as a norm and default situation is fading away. More and more people are realizing that they need to adapt to a changing work environment at an ever accelerating rate. You need to train for new skills, acquire new knowledge. The very notion of career is being questioned and revisited more and more regularly. And in some industries, software development included, it’s not uncommon to work for companies anywhere in the world, from anywhere in the world. This trend is pushing more and more people to be independent workers, and even though governments and administrations are once again incredibly late in adapting to it, it doesn’t prevent us (even though it makes it incredibly painful sometimes) from doing it. It’ simply the sense of history, and it’s always frustrating to see so many awesome companies resist it, especially when they are supposed to be at the forefront of innovation.

Let’s talk about it

Given all that, I would love to hear more about the reasons why employers, and especially startup founders and managers don’t want to work with freelancers. I’m sure there are plenty of myths to be busted in there, and I’d be really happy to help. Also, if you are a freelance developer, and would like to share some interesting experience to share, let’s get the debate started in the comments of this post.

Book publishing is dying? No kidding!

It’s been a while since I posted my last article here. But tonight I just can’t help it. For a few weeks I’ve been reading MongoDB in Action, from Manning, as an eBook on my iPad. And for a few days, since I started diving into the more complex parts of it, I’m struggling with errors all over the place. And I’m not just talking about typos here, I’m talking about massive errors that completely change the meaning of code samples and leave you wondering about your own sanity and stupidity. Here are a few examples coming from their Errata page:

Page 81, First code snippet

First off, how the hell am I supposed to match there erratas with my eBook? An eBook has no such pages, it depends on what you’re reading it on, the size of the font, etc. Now I know these erratas are designed for paper books originally. But these are technical books we’re talking about. How many technical people are still reading ink on dead trees around here?

Replace

category = db.categories.findOne({'slug': 'outdoors'})
siblings = db.categories.find({'parent_id': category['_id']})
products = db.products.find({'category_id': category['_id']}).
                            skip((page_number - 1) * 12).
                            limit(12).
                            sort({helpful_votes: -1})

with

category = db.categories.findOne({'slug': 'outdoors'})
siblings = db.categories.find({'parent_id': category['parent_id']})
products = db.products.find({'category_id': category['_id']}).
                            skip((page_number - 1) * 12).
                            limit(12).
                            sort({average_review: -1})

In the paragraph before this code sample, you can read that we’re looking for siblings of the current category, and then in the original code sample above, you see the code is looking for children, not siblings. So you start hitting your head agains the wall, reading the same sample over and over again, trying to make sense of it, and then you locate the errata and you see THIS!

But we’re not done yet, there’s more, there’s worse!

From the same errata page:

The line reading:

emit(shipping_month, {order_total: this.sub_total, items_total: 0});

should read:

emit(shipping_month, {order_total: this.sub_total, items_total: 0});

You can read it again… and again… no, there’s no difference between the original and the correction. It’s exactly the same fricking line! The worst part is that you can feel there’s something wrong with this line. It’s obvious that it seems odd to start a map-reduce with different starting points, but which one is the right one? Not so easy to figure out when you’re encountering your first map-reduce. So what, is there an errata page for the errata page somewhere?

But my favorite is definitely the next one:

The lines reading:

var tmpTotal = 0;
var tmpItems = 0;

tmpTotal += doc.order_total;
tmpItems += doc.items_total;

return ( {order_total: tmpTotal, items_total: tmpItems} );

should read:

var tmpTotal = 0;
var tmpItems = 0;

values.forEach(function(doc) {
  tmpTotal += doc.order_total;
  tmpItems += doc.items_total;
});

return ( {order_total: tmpTotal, items_total: tmpItems} );

Ah! So that’s where this “doc” variable comes from! How the hell could two entire lines be removed by mistake? And then I noticed something odd. The last line of what’s supposed to be the original is wrong. What I’m actually reading in my version of the book is:

return ( {total: tmpTotal, items: tmpItems} );

And not:

return ( {order_total: tmpTotal, items_total: tmpItems} );

So same question again… Errata for this errata?

So to sum it up: Manning is a technical editor, they publish technical books for technical readers. They release draft versions in advance for the community to review them on the cheap. Then they sell you eBooks for 30$ a pop, the final version is still littered with massive errors. And then they can’t figure out how to patch your book so they write an errata page that is simply unusable because A- you can’t match page numbers with an eBook and B- the errata page itself is full of errors.

And they wonder why their industry is on the decline? Seriously? I’ll tell you what, next time I’ll save a few tens of bucks and I’ll find “another source”…

And in the meantime, I just found out about Sigil. So I’ll see if I can patch the book and republish it, just as a provocation.

My Case for DTO’s

In many of my posts about Grails and Flex integration, I take for granted that I use Data Transfer Objects to transfer data between my Grails backend and my Flex frontend. Put simply, Data Transfer Object are pure data containing classes different from the domain entity classes used to store data in the backend. I take it for granted because I’m deeply convinced that it’s the best way to do things and so far, experience has never proved me wrong. But I often get this question in comments or by mail (this is for you Martijn): why bother create an entirely separate class structure and copy data from entities to DTO’s and back instead of just using entities?

I’ve expressed my arguments a couple of times across various posts but I thought it would be nice to sum things up in here for future reference.

Where does it come from?

When I first started to work on enterprise applications and ORM-based architectures, it was with a Model-Driven Architecture framework called AndroMDA. AndroMDA was absolutely key in helping me getting started with Spring and Hibernate and I was especially inspired by one paragraph in their “getting started” tutorial, which I quote here:

Data Propagation Between Layers

In addition to the concepts discussed previously, it is important to understand how data propagates between various layers of an application. Follow along the diagram above as we start from the bottom up.

As you know, relational databases store data as records in tables. The data access layer fetches these records from the database and transforms them into objects that represent entities in the business domain. Hence, these objects are called business entities.

Going one level up, the data access layer passes the entities to the business layer where business logic is performed.

The last thing to discuss is the propagation of data between the business layer and the presentation layer, for which there are two schools of thought. Some people recommend that the presentation layer should be given direct access to business entities. Others recommend just the opposite, i.e. business entities should be off limits to the presentation layer and that the business layer should package necessary information into so-called “value objects” and transfer these value objects to the presentation layer. Let’s look at the pros and cons of these two approaches.

The first approach (entities only, no value objects) is simpler to implement. You do not have to create value objects or write any code to transfer information between entities and value objects. In fact, this approach will probably work well for simple, small applications where the the presentation layer and the service layer run on the same machine. However, this approach does not scale well for larger and more complex applications. Here’s why:

  • Business logic is no longer contained in the business layer. It is tempting to freely manipulate entities in the presentation layer and thus spread the business logic in multiple places — definitely a maintenance nightmare. In case there are multiple front-ends to a service, business logic must be duplicated in all these front-ends. In addition, there is no protection against the presentation layer corrupting the entities – intentionally or unintentionally!
  • When the presentation layer is running on a different machine (as in the case of a rich client), it is very inefficient to serialize a whole network of entities and send it across the wire. Take the example of showing a list of orders to the user. In this scenario, you really don’t need to transfer the gory details of every order to the client application. All you need is perhaps the order number, order date and total amount for each order. If the user later wishes to see the details of a specific order, you can always serialize that entire order and send it across the wire.
  • Passing real entities to the client may pose a security risk. Do you want the client application to have access to the salary information inside the Employee object or your profit margins inside the Order object?

Value objects provide a solution for all these problems. Yes, they require you to write a little extra code; but in return, you get a bullet-proof business layer that communicates efficiently with the presentation layer. You can think of a value object as a controlled view into one or more entities relevant to your client application. Note that AndroMDA provides some basic support for translation between entities and value objects, as you will see in the tutorial.

Because of this paragraph, I started writing all my business services with only data transfer objects (what they call “value objects”) as input and output. And it worked great. Yes it did require a little bit of coding, especially as I had not discovered Groovy yet, but it was worth the time, for all the following reasons.

The conceptual argument: presentation/storage impedance mismatch

Object-relational mapping is what Joel Spolsky calls a “Leaky Abstraction“. It’s supposed to hide away the fact that your business entities are in fact stored in a relational database, but it forces you to do all sorts of choices because of that very fact. You have to save data in a certain order in order not to break certain integrity constraints, certain patterns are to be avoided for better query performance, and so on and so forth. So whether we like it or not, our domain model is filled with “relational choices”.

Now the way data is presented involves a whole different set of constraints. Data is very often presented in a master/detail format, which means you first display a list of items, with only a few fields for each item, and possible some of those fields are calculated based on data that is stored in the database. For example, you may store a country code in your database, but you will display the full country name in the list. And then when the user double-clicks an item, he can see all the fields for that item. This pattern is totally different from how you actually store the data.

So even though some of the fields in your DTO’s will be mere copies of their counterparts in the entity, that’s only true for simple String-typed fields. As soon as you start dealing with dates, formatted floats or enum codes, there is some transformation involved, and doing all that transformation on the client-side is not always the best option, especially when you have several user interfaces on top of your backend (a Flex app and an iPhone app for example), in which case you’re better off doing most of these transformations on the server.

In anyway, if you change the way you store data, it should not influence too much the way you present the same data, and vice-versa. This decoupling is very important for me.

The bandwidth argument: load just the data you need

In the master/data use case, when you display the list of items, you just need a subset of the fields from your entities, not all of them. And even though you’re using Hibernate on the backend with lazy-loading enabled, fields are still initialized and transferred over the wire. So if you use entity classes for data transfer, you will end up transferring a whole bunch of data that may never be used. Now it might not be very important for hundreds of records, but it starts being a problem with thousands of records, especially when there is some parsing involved. The less data you transfer the better.

The security argument: show only the data you want to show

Let’s say you’re displaying a list of users, and in the database, each user has a credit card number. Now of course when you display a list of users, you might not want everyone to see the list of credit card numbers. You might want to expose this data only in detail view for certain users with certain privileges. DTO’s allow you to tailor your API to expose just the data you need.

The error-prone argument: argh! Yet another LazyInitializationException!

Of course there are associations between your business entities, and by default, those associations are lazy-loaded, which means they are not initialized until you actually query them. So if you just load a bunch of instances from your entity manager and send them over to your client, the client might end up with null collections. Now of course you can always pay attention, or use some tricks to initialize associations up to a certain level before you send your data, but this process is not automatic and it’s very error-prone. As for using things like dpHibernate, I think it just adds too much complexity and uncontrolled server requests.

The laziness argument: Come on! It’s not that hard!

I think that most of the time, the real reason why people don’t want to use DTO’s is because they’re lazy. Creating new classes, maintaining code that does “almost” the same as existing code, adding some code to service implementation to copy data back and forth, all of that takes time and effort. But laziness has never been a good reason for ditching a design pattern altogether. Yes, sometimes, best practices force us to do more stuff for the sake of maintainability and robustness of our code, and for me the solution is certainly not to shortcut the whole practice, but just to find the best tools to minimize the added work. With its property support and collection closures, Groovy makes both creating, maintaining and feeding DTO’s as simple and fast as it can be. AndroMDA had converters. There are even some DTO-mapping frameworks like Dozer to help you. No excuse for laziness.

For me, all the reasons above largely overcome the added work to maintain a parallel DTO structure.

Now of course, this is a very opinionated topic and you will probably have a different view. So all your comments are welcome as long as they remain constructive and argumented.

Mac Runtimes, What a Mess!

First of all, let’s make things clear: I’ve been a very satisfied Mac user for the past 4 years or so, but I’m also a Java and a Flex developer, which means I have interests in all three of those technologies. And yes, I’m also a big fan of Steve Jobs, but despite all expectations, I try to be lucid about him and some of his weirdest choices/decisions/open letters ;o).

The problem I have at the moment is that, in the name of sensationalism, a lot of blogs post with titles like “Macs won’t have Flash anymore”, or “Java is dead on the Mac”, as if it was just an evil continuation of the “no Flash on iPhone/iPad” fuss that started at the beginning of this year. Now it’s certainly a great way to draw attention to those sites who only live thanks to advertisement, and hence number of visits. But let’s try to reestablish a few realities here.

First off, let’s talk about what everybody has at the back of their head when they think about Apple and runtimes: iOS. Yes, iOS doesn’t support any alternative runtime. In fact, besides Javascript, iOS doesn’t support any virtual machine. Flash and Java work on virtual machines and they’re not supported on iOS. There are 2 major reasons for that. The first one is performance, because a virtual machine, that is a software execution environment on top of a hardware one, will never be as performant as the native one. Despite all the optimization efforts that Adobe has done with Flash on mobiles, first experiences on Android tend to confirm that there’s still work to be done. Even though they have improved a lot in the past 3 years thanks to the iPhone impulse, mobile devices still run with very limited hardware capacities. And they still haven’t reached the point where they have a lot of free resources to spare, like personal computers have. So the official reason makes sense. But of course the less official reason is also important for Apple: iPhone’s number one sales argument is apps. When you think about it, it’s almost funny because when the first iPhone came out without an SDK, everybody complained about it, and then Steve Jobs answered that there was no use for a SDK. And obviously at that time, Apple was already working very hard on the App Store and the iPhone SDK. But when you know you have something huge in the pipeline, something that will make your device even more frightening to the competition, what is the best thing to say to the competition? “Don’t worry, this is just another one of our silly shiny gadgets that will just convince our existing fans”. And then a mere 18 months later, Apple comes out with not only an excellent SDK, but a whole new sales and distribution channel, and a marketing strategy that is based solely on all the apps your can install. I’m sure that there must have been a couple of WTF-moments at Nokia, RIM and others. So when your whole marketing strategy relies on your controlled and polished SDK and distribution channel, you have absolutely no interest in letting others in, be it J2ME crap (I’ve done J2ME development too, iark!) or the more threatening Adobe AIR. So let’s deal with it: no virtual machines on iOS, and whether we like it or not, it makes sense.

So are recent news just a continuation of that? Is Steve Jobs trying to eliminate all competition on the Mac too. NO! He’s not! It’s a completely different story!

Let’s start with Flash on the Macbook Air. Yes, the new Macbook Air doesn’t have Flash pre-installed. Actually, Safari does not have the Flash plugin preinstalled anymore. But nothing prevents you from installing it yourself. As nothing prevents you from installing Firefox and its Flash plugin as well. On iOS, it’s not pre-installed, and you can’t install it yourself. On MacOSX, from now on, it won’t be pre-installed but you will still be able to install it yourself. Huge difference! The Flash community has complained enough about the outdated version of the pre-installed Flash plugin. Of course Apple will not change their systems every time Adobe fixes a security or performance bug. So the best way to avoid any remanent hole, is to allow no hole at all by default. And if you need Flash, you just install the latest version and you’re good to go. That’s for the official reason. But as always there is… one more thing! One of the main marketing arguments for Flash is that, unlike any other cross-platform runtime, it’s installed on a crushing majority of machines, somewhere above 95% of them. But that is partly thanks to those integration deals that make Flash ship with every new PC or Mac, independently of the popularity of Flash as a development platform. Apple’s bet is that with the advent of HTML5, users will use the Flash plugin less and less often. But if they pre-install it, this drop in usage won’t reflect on Adobe’s marketing. Once again, whether we like it or not, it makes perfect sense for Apple. And it even makes sense to me: even if I’m a big Flash advocate, even if I think the HTML5 fuss is just oversold, I think Adobe has been a little too slow to react lately, as if they were resting on their dominance of the cross-platform runtime market. So everything that makes them fight harder to build a better development and runtime environment is good. And I’m sure they will fight. They just need to invest more in it. Mobile Flex development only in early 2012 (and that’s the first estimates, the ones that are always wrong) will just be too late for the show. So that’s it: no Flash plugin preinstalled in Macs means no Mac shipping with outdated security holes built-in and no built-in popularity bias either, which is good for competition. But nothing will prevent your from installing Flash yourself.

Let’s talk about Java now. When you read the news, you tend to feel like Apple’s war on competition is nothing personal against Adobe, that  it’s targeted at everyone else, that Java will be Steve’s next victim. But that’s just so untrue! First off, contrary to what happens with Flash, Apple never said that they would ship Macs without Java built-in. They just said that it would enter a pure maintenance phase and that they would stop supporting it… themselves! But once again, they won’t prevent anyone else to take over support for Java on the Mac. In fact, that’s probably why they took this decision: there was a time when Apple had their own interests in Java, when there was a Java-Cocoa bridge in the development environment, when Java was even a great way to make the Mac ecosystem richer, because a lot of developers would write their desktop applications in Java to support all platforms with a single code base. But of course, with the deprecation of Java-Cocoa bridge and the advent of the iPhone and what it means in terms of popularity for Objective-C and Cocoa native environment, Apple’s stake in Java has decreased dramatically. So much so that today, those who have the most interest in Java on the Mac are… those who support Java developers. And since Steve Jobs and Larry Ellison are known to be big friends, I’m sure Oracle and Apple are perfectly clear with who is going to take over. Maybe the community can help with Soy Latte and OpenJDK, but I can’t believe that Oracle won’t step up themselves, given the overwhelming Mac install base amongst java devs. And still, whatever the solution, Apple won’t prevent any one else to support Java and offer a Mac installation package for it.

So Flash and Java are not dead on the Mac! At least not based on existing statements and choices from Apple. But we can’t know what Steve has in mind, and I can’t help worrying about the end game of all this. Given the huge success of iOS, which makes perfect sense in the mobile world, I’m really afraid that Steve Jobs won’t know where to stop and will want to reproduce the same model on desktop. And I certainly don’t want that. I’m not ready for it yet. And I think a lot of people are not ready either, so if Apple moves too fast in this direction, they could loose a lot of customers in the process, especially if Steve Jobs starts this transition and then leaves this for others to deal with. But we’re not there yet. So please bloggers, keep your heads cold and please avoid feeding fear, uncertainty and doubt.

How To Introduce Yourself… I Mean Practically

For years, I’ve been using a very simple but very effective technique to introduce myself in job interviews, and I’ve always got some excellent feedback about it. I’m not talking about the content here, but the format. It can always be a bit tricky to introduce yourself without diving too much into irrelevant details, or losing yourself along the way, or boring the interviewer to death. To avoid all that, I’ve learnt this technique at Axen, but since Axen doesn’t exist anymore per se, I might as well share it with you guys, because it’s always a shame to miss a good recruitment because the candidate wasn’t clear enough during his/her interview. So here you go…

Continue reading How To Introduce Yourself… I Mean Practically

Apple Store: The Worst (Non-) Buying Experience Ever!

I feel like I’m just waking up from an awful nightmare. Actually “waking up” might not be the right expression since I haven’t slept in 30 hours but you get my point. Let me tell you my little story.

2 years ago, when the iPhone 3G came out in Belgium, I had been waiting for an iPhone for so long that I simply couldn’t help being there on the first day. So when Mobistar launched a small marketing stunt by starting selling the iPhone at midnight, I decided to wait in line. And I did. From 4pm the day before until I received the iPhone 3G number 50 for all Belgium at 2am in the morning. The experience was painful at the end, especially because I had totally forgotten to bring a chair. But overall it was very rewarding and I was very positively surprised by the way Mobistar had organized the whole thing.

Last year, I completely missed the iPhone 3GS launch so I had a few hard weeks trying to find one.

That’s why this year, for the iPhone 4, I decided to go wait in line in the biggest Apple Store in France, in Paris, at Carrousel du Louvre. Oh my! What a disappointment! Just to sum it up so you can imagine what mood I’m in: one sleepless night, more than 300 euros in train and parking tickets, 15 hours in line including 8 hours standing, hence 2 feet hurting like hell… and not one single iPhone 4.

I was there at 9pm yesterday. Everything started nice. I was only the tenth in line. I had just bought myself one of these very comfortable and robust camping chairs. I had my iPad and some WiFi. I enjoyed it. And then things progressively but rapidly went very wrong. In front of me, there was a bunch of Russian guys who started drinking uncontrollably, and since there was simply no organization whatsoever, nothing prevented their Russian friends to join them late in the night, without any respect for the guys who had been waiting here for long hours. Then the rumor started to spread that the Carrousel galleries would open at 4am exceptionally. So when 2 security guards approached the door, no barrier, no Apple guy, nothing or no one prevented the line to turn into a big compact crowd where last come became first served. And we waited there for nothing to happen, standing, from 4am to around 6am. Eventually the security guards ended up opening the door. In fact not THE door we were all anxiously waiting in front of. No! Too easy! Another door on the side of the gallery, resulting in a chaotic and unbelievable crowd movement that finished up the last bits of line order there was.

So it was around 6am when other security guards started to appear, and those guys obviously had no clue how to handle a crowd, let alone an international one (have you ever tried to reason with a drunk Russian guy?). They just yelled at us, ordered us to move backwards and then forwards again, a couple of times, and at 7 am we had yet another differently ordered “line”, standing. But at least the security guards managed to maintain some sort of discipline by filtering who could enter the queue right in the middle for some reason. An Estonian guy behind me successively introduced his wife and his girlfriend. Of course, once they were in the line, they couldn’t care less about the dude.

And then around 7:30am, guards started disappearing again, obviously called to greater ventures down in the galleries, and chaos came back until they started letting people in, in small groups, a little before 8am. We thought “that’s great, they’re letting people in at the rate the Apple Store can process their purchases.” There were around 150 people in front of me (remember, I was 10th in line at the beginning), so I figured I might be able to execute my plan and catch my train back at 9:25am. How foolish of me!

There was another line inside the gallery! So the small groups who were let in all started running in order to win a few precious ranks (remember, I had not slept in 24 hours at that time, very practical to run like crazy!). But wait, it gets worse, there was not one line inside the gallery. There were 2!!! One for us fools who hadn’t reserved our precious little one. And one for those who reserved it online and just came to pick it up. Wait! What? Pick it up! Why aren’t those guys just waiting at home for the postman to come by and bring them the precious little one in the comfort of their home? What the heck is this pick-up thing? And soon we realized that they were letting people inside the Apple Store in a proportion of 8-9  reservations for 1-2 people without reservation. Wait! What?! What the hell is the rationale about that? At most, reservation is supposed to guarantee that you will have one, not that you will have one before everyone else!

But wait, it gets funny too. Remember those proportions? I said nothing about the rate. According to our estimation, it took somewhere around 15 to 30 f***ing minutes for a blue-shirt-guy to process one customer. 30 minutes! So guess what happened? The line of reservations grew longer and longer with fake reservations, the line of non-reservations turned into yet another big chaotic pack, security guards kept yelling at us, ordering us to move backwards. Yes, backwards! All of that while the Apple store seemed to be able to process somewhere around 20 persons per hour. So the pack I was in moved 10 meters in 4 hours, I kept seeing people without reservations suddenly changing lines magically and getting out with 4 iphones at once. And yes, at 12pm, I gave up!

I decided my body had taken enough stress. I stepped back and realized that an iPhone was not worth that! Especially not a black one anyway! So I just left the queue, went back to the train station, bought another train ticket at an indecent price hoping that I would get back home as soon as possible to spit out this bad nightmare and forget everything about it.

And here we are. It’s 4pm. I don’t have any iPhone 4, I’m frustrated and I’m pissed. I’m so pissed at Apple right now. If someone from Apple is reading this, read it carefully! Not only am I a basic fanboy of yours, but I’m also an iPhone/iPad developer and my 2 modest apps on the App Store participate in the great ecosystem that allows you to sell all those magical devices. And even without all of that, I really expected from you a buying experience at least equal to the one I had with the little Mobistar 2 years ago. And in the end, no organization whatsoever, no one from Apple to handle the logistics in the queue late in the afternoon, no one to give clear and consistent instructions to those security guards, no communication about why things were so slow. And slow they were! And chaotic too. Several people fainted in the line, a lot of people cheated, everyone was pissed off to a point you can’t even imagine. Now let me tell you this and read my lips: if that’s the only possible outcome of your corporate ego going through the roof, if all you can do is treat your most loyal customers like this (check my recent purchase record), then I SUDDENLY FEEL LIKE BUYING AN ANDROID PHONE (and developing for it!). But you don’t care, right? Because so many people are buying it anyway…

I’m exhausted. I’m starving. I’m frustrated. And all I can do right now is spit it out on my blog and laugh at myself for being such an overly optimistic fanboy consumerist. And all I want to do is forget about this day. Apple, you just created the new worst day of my life so far as I can remember. And I don’t thank you for that.

WWDC 2010 Review

Still one session to attend about closures in Objective-C, and I’ll call it a week. A little bit of shopping this afternoon in order to spend my last dollars and I’ll be ready for take-off tomorrow afternoon. So it’s time for a little summary of this week.

Overall, it was my first WWDC and I’m very glad I did it, but I probably won’t do it again. San Francisco is definitely a very nice city, and seeing Steve in live, even from very far away in the audience was an interesting experience. I also learnt a few very interesting things and psychologically a conference like this always has the same side-effect on me: first I’m depressed and humbled by all the ambient intelligence, but then it motivates me a lot to move forward, learn and do something about it. So it has definitely been a very positive experience.

Now was it worth the budget I put in it? Continue reading WWDC 2010 Review