Yesterday,  Following Foursquare’s announcement of their decision to switch to OpenStreetMap,  I had a long discussion on Twitter about the merits of open and “closed” map systems.

I am a big fan of Google maps. I like using the website both from my pc and my iPhone.
The only interaction I have had with OpenStreetMap has been through the Skobbler navigation app for the iPhone. I had even paid to get the offline maps. My experience was a thoroughly disappointing one. Partly because of the maps not being very accurate but mainly because of the frustration with the application. After spending the money to get the offline maps the app kept telling me to connect to the internet to navigate – which entirely defeats the purpose of paying for the offline maps.

Normally I’m a big supporter of openness. However, in this particular care, I find myself thinking that a “closed” system is probably better. I am using the word close losely here as what I mean is not a system unaccessible to developers but rather a system maintained and paid for by a private corporation.
My reasons are the following:

1. “Mapping” is an expensive business – A private corporation fully invested in this business is likely to spend considerable sums of money making sure its maps are accurate and reliable, globally. Globally here is a keyword for me. OpenStreetMap is not likely to get very accurate data in areas which are not easily reachable or don’t have easy access to the internet (and that’s where I like to travel and use my maps)
2. People are lazy – We see it all the time. Wikipedia (which I love) is updated only by a handful of users  while being consumed by billions – Creating content on Wikipedia requires relatively little (physical) effort, on the other hand creating content for OpenStreetMaps includes going out, driving and therefore spending money. Granted there will always be a handful of people eager to create and share this information, but is that enough to keep a world atlas up to date?
3. Being popular online is expensive – OpenStreetMap to keep growing in popularity will have to raise an ever larger amount of money to keep its hosting facilities up to scratch to deal with the demand. Of course a business has the same issue, but they make money out of it and this money is invested in keeping the facilities up-to-date.

I love the idea of OpenStreetMap being an open data source and API rather than a product (like Google maps). I love how customisable it is and how easy it is for developers to integrate. Nevertheless I am not sure it will be able to stay accurate in the long run. Yesterday Skobbler’s creator claimed that OpenStreetMap is already better than Google maps in Germany. Just out of curiosity I went to google maps, picked a random small town in the middle of Germany then went to have a look at it on OpenStreetMap – quite a few roads where missing (especially dead end roads) – Urgh.

What do you think?

Bookmark It

Last week-end I went to Brands Hatch for the British Superbike Championship.

I had a great time and loved hanging around the paddock and talking to drivers and mechanics. Also, a friend of mine was racing in the Harley Davidson XR1200 championship so it was a good opportunity to spend some time with him and cheer him on.

I loved the historic bike races and have taken quite a few pictures. Here’s some of my favourites.

And here’s a picture of my friend, Rhys Boyd, racing the XR1200 for the Rockforge GFI team.

Bookmark It

Over the past couple of weeks I’ve been interviewing candidates for a Java developer position.
I can’t find words to describe my feelings now so I’ll recycle something a friend of mine, who’s also hiring, said:

It’s next to impossible to hire anyone useful now.

My complaint with most of the applicants is that they behave – there’s no other way to say this – machines.

I did what I did because I was told to it. Never really thought about it.

This infuriates me beyond belief.

So here a few tips for your (and my) next interview:

1. Don’t make up stuff on your CV. Sounds obvious but you’ll be surprised by how many people list technologies they have barely used on their CV and when asked about it don’t have a clue. You have no idea how bad this looks. (The red bullshitter light starts flashing in my head instantly)
2. Show that you have passion for what you do. Being a Sun certified Java developer is all well and good but when I ask you what you have been looking into recently, or if you’ve worked on something on your own make sure to have an answer; or, if you don’t, make sure you have a good excuse.
3. If you have 1000 years of experience with something I expect you to have some thoughts about it. Once again, Sun certified Java developer, if I ask you where do you see java going in the next 5 years have an answer! There must be something you think needs improving in Java or that you’d do differently. I’ll go wherever Sun takes me is just not an acceptable answer.
4. Have an opinion! For God’s sake have one. I’ll even settle for half an opinion. If not about a technology you have used for 10 years at least about the coffee I just bought you during the interview. There’s no point in talking for an hour with somebody who has nothing to tell me other than “I’ll do everything you want, I always did.”
5. Know what the company you have applied for does! This sounds stupid but I have called people after 1 week of their application and after 10 minutes with them over the phone I found out that they have no idea what the company they applied at was doing. That’s an instant goodbye!
6. Fill the gaps in your CV, and proof-read it before sending it out for goodness sake. It’s fine that you have taken one year off to travel the world. If your CV does not list anything for the whole of 2009 I’m going to ask you about it. Give me a sincere instant answer and there’ll be no problem. Give me random excuses and it’s goodbye. As for proof-reading I had somebody applying who had listed “quick apprehension” as a skill. I’m not into hiring failed super-heroes. (I assume they ment quick comprehension)
7. Apply for jobs you are genuinely interested in. You are not likely to get a job if your interviewer notices you don’t give a toss about what you do and who you do it for, and it shows. So Unless you are applying for a position as a nut-packer make sure you’re going for a job you’d actually enjoy doing and are interested in.

Needless to say my search continues.

After reviewing more than 60 CVs I have almost completely given up on websites such as Monster and CWJobs and I’m going to go entirely through connections now.

Bookmark It

I have just stumbled on an article on Slashdot about Google Go. A programming language which was initially developed internally and it’s now been open-sourced.

Over the past few months I have been working with Erlang on multi-process distributed systems. Concurrency in Go is based on the same model Erlang uses: Hoare’s Communicating Sequential Processes, or CSP.

Go’s concurrency primitives derive from a different part of the family tree whose main contribution is the powerful notion of channels as first class objects.

The thing I appreciate the most of Erlang is how easy it is to distribute – even over a network – and monitor processes. After skimming through Go’s documentation I couldn’t help but notice the lack of integrated network-distribution of processes or goroutines, as they are called.

This for me means that while Go, exactly like Erlang and Occam, simplifies the approach to multi-threaded programming (at least from a developer’s point of view), it doesn’t go all the way and leaves developers to deal with distribution of processes over a network on their own.

This is a perfectly acceptable design choice in the name of flexibility, however it creates a whole new bunch of use cases for the developers to deal with, such as sending channels/channels-data over the network).

What I don’t like of Erlang is its handling of strings, which makes it unsuitable for a number of application that could benefit greatly from its multi-processing capabilities. Very few people would recommend Erlang as a high performance string manipulation language. To quote Sendmail’s case study in implementing their Sendmail load balancing “Client Daemon” in Erlang:

…But Erlang’s treatment of strings as lists of bytes is as elegant as it is impractical. The factor-of-eight storage expansion of text, as well as the copying that occurs during message-passing, cripples Erlang for all but the most performance-insensitive text-processing applications.

Go totally wins on this.

If you now asked me to pick one to use. I’d still go for Erlang.
Functional languages and CSP are changing the way big companies approach the development of business critical applications. In the last year alone I have seen the number of positions advertised for Erlang developers in the financial sector multiply.
Go, if it continues on this path definitely has a chance of making it there. Open-sourcing the language is the right decision to give it the exposure to real-life scenarios that tend to accelerate the growth and adoption rate.

Bookmark It

Those of you who have met me know that I’m a huge Top Gear fan.

James May – one of Top Gear’s presenters – has been working on a show about old toys, oddly named James May’s Toy Stories.

James with his lego house

You see despite being a computeroid I spent most of my childhood playing (ie assembling) car and airplanes models and generally reducing everything my parents ever gave me as a present to its basic components.

The first episode of the show has finally been broadcast and has now appeared on the BBC iPlayer.

James May is out to prove why traditional, old fashioned toys are still relevant by pushing them to the limit in spectacular, supersize challenges. From full-size Lego houses to bridges made completely of Meccano, he shows what they are capable of.

James takes model aeroplanes to a new level when he tries to make a full-size Spitfire out of Airfix. The venture soon hits problems when it becomes clear the giant 36-foot pieces may not be strong enough, and nobody knows how they will fit together.

James hopes he can enthuse a group of reluctant teenagers to help him pull it off – but he soon realises he has another big battle on his hands convincing them it is a hobby to be proud of.

Now the show, at least the first episode, is not that great. Unless you are me and love building models and love toys. Can’t wait to watch the lego house episode (Picture in this post).

Bookmark It

After much anticipation and hype the Gdrive seems to be on its way, or so the WSJ reports.

A Google spokeswoman declined to comment on any specific online storage plans beyond what it already offers as part of its email and other services. But she said in a statement that “storage is an important component of making Web [applications] fit easily into consumers’ and business users’ lives.”

Most companies, from small businesses to big giants are moving their environments online to make documentation/presentations or whatever else may be needed available to their employees, wherever they may be whenever they want.

As I said in a previous post Google is pushing its online productivity suite and a shared online storage could definitely give an additional boost to the entire system.
The online storage is one of the few reasons why I use .Mac, the second rationale behind the choice is that the interface is just brilliant, the iDisk is mounted as a file system and directly accessible from my Finder.

In my opinion if Google really wants to make the Gdisk a must have for small/big businesses a client software to access the data is vital – not because it works better, but because it is a step final users have to go through to get used to online storage solutions. Most people don’t, and won’t for a while, use Writely or Google’s new PowerPoint-ish software – they’ll keep creating documents in their local environment and the sensation of accessing a local drive to save their work will make them feel somewhat more secure.

For its office components to attract big businesses Google still has do a great deal of work on the corporate accounts handling side – being able to organize accounts in groups and set different access permissions on a Gdisk’s folders would be a great start.
Another useful additional feature, which as I understand is due sometime soon, is offline availability of the applications. An internet connection is not always available and an entire company can’t just stop working because IT people in the basement are messing around with routers.

Having said that it’s not only functionality-related issues Google has to address but also privacy and security questions. If they want more of our data to be stored on their servers, and with Gdisk it wouldn’t only be images and documents but all sort of data we may not want other people to see, we expect Google to have some pretty satisfactory answers ready – Especially when we’re talking about reserved and potentially vital information its business customers save in the cloud.

Bookmark It

Another post about my experiences with startups.

The one important thing I have ascertained about programmers during my career is that good ones are hard to find. Furthermore skillful developers tend to be ego-maniacs (I am no exception). The people generally portrayed in films as shy “nerds” are really expansive, loud and boastful persons. After all why shouldn’t they be; a startup’s most important assets are its people, and developers are a vital part of the organism. On the other hand it is also true that everybody is important but nobody is necessary.

In all the startups I’ve worked for, particular emphasis was put in the recruitment process, especially whilst hiring members of the initial core team. Which doesn’t mean only finding smart competent people, but also making sure that they’ll fit in with the rest of the team. Therefore it is very important to have every member of the initial team meet the candidate and make sure that they will be comfortable working with them; even people from different departments, marketing directors should meet programmers before an offer is made.

The other thing you have to make absolutely sure of is whether your newly-hired programmer can accept the technical leader’s style. The manager/CTO (call it whatever you want) has to be flexible, but at the end of the day he/she is still running the show and you can’t really afford to have a small team destabilized, especially when the disturbance undermines the leader’s authority.

I have had to interact with quite a few managers, each one with a different approach to the development process. The two most common and distinguishable modus operandi are certainly the autarchic and the unconstrationist (new word I just came up with).
The autarchic wants to be in full control every step of the way and put a two cents in every decision. The “libertine”, on the other hand, will take care of the big picture and leave the individual programmers to make decisions regarding the piece of functionality they have been assigned.

Neither attitude is wrong. However, I generally adhere to the more liberal approach, hence the title of the post. Being in charge of something every step of the way certainly helps prevent bugs from being introduced, if not because of a CTO’s superior experience because two brains are generally better than one. Anyhow if you try to be involved at every level of the development, from the requirements gathering and analysis to the practical development you’ll quickly end up being overwhelmed with work and with a crew perhaps not prepared to scale and be in charge of new hires themselves.

Contrarily leaving developers some independence in their restricted realm helps boost you team’s morale and prepares a normal programmers to be in change of somebody in the future as the company grows. Admittedly this approach will leave the whole system more exposed to potential bugs, introduced either for a technical mistake or lack of wide-angle-view-to-future-developments of the programmer in charge. The second drawback of this method is that you’ll most likely end up with a code library written with very different styles, hence harder to maintain and get used to for new people. Be that as it may, I still stick with “Celebrate Diversity”.
There’s always going to be a better tool or programming style than the one used when developing something. However, asking a proud programmer to change his code and do whatever you asked for exactly your way is worse than a punch in the guts.

As I said before neither approach is wrong and it’s purely a personal decision of the person in charge. It is a very difficult balance to strike. Ego-feeding is good, keeps the spirits up and developers are more likely to work harder and better. Unfortunately, programmers are human and as you leave somebody in charge of a single piece of functionality there might be nobody to find that stupid bug which could have been caught in a second by an additional brain.

Bookmark It

I have a few things to post but no strength to do it. I figured another one of those trademark Bird and Fortune videos would do just as well.

[youtube=http://www.youtube.com/watch?v=3pcePHasv5w&rel=1]

Bookmark It

During my short yet intense career I have worked for quite a few startups and small businesses. I want to talk about a phase most startups go through – Our application is crap, lets trash it and rebuild it from scratch.

Hindsight is something few people have and wisdom is just a myth, just a fancy name we have come up with to call our mistakes.
Nevertheless when a company outgrows the chrysalis stage and starts producing revenue and growing accordingly hindsight is one of management’s favorite words. It’s widely abused in every meeting. Who hasn’t heard at least once “With the benefit of hindsight we could have…”.
This special word makes the eager-developers brain click. There’s our chance to build the perfect application. We know what to avoid, we have wasted countless hours solving all the problems we found in our path before and we’re now ready to whip out the ultimate system.

Perhaps with a bit of hindsight, wisdom, or a wee little bit of both, our developers would realize that every time they start developing an application from scratch a whole new bunch of complications will crop up and will have to be solved. While this happens the management team who has promised to deliver in time to the big bosses is obviously breathing heavily down the programmers’ skinny necks.

This happened to me once, although we didn’t go as far as actually begin the development a countless amount of hours was wasted in meetings to trying and figure out what we were going to do and how.
The issue for many startups is that very often the software is developed hastily for lack of funding or time constraints. This generally leads to a structureless applications patched together at the last minute. That’s how it is and always going to be – and in my personal experience it’s definitely better this way than running out of funding because the entire process is managed by a megalomaniac-developer with serious ego-related issues.
Once the application is ready and the product is launched there’s never going to be time to stop. Look back. Amend emissions and non-blocking bugs until it’s too late. That’s just the natural process.

After 1 year of life the initial product will most likely be completely unrecognizable and changed/badly-patched in many of its core components. This will make keeping track of what’s exactly going on inside the software harder.
So now what.
The approach I’ve found most feasible and realistic is to gradually fix and produce documentation as the development progresses. A software, especially a website, will never stop evolving and the amount of feature-requests and bugs to fix will only increase with time, stopping the entire machinery to go back and fix is just not an option. However, whilst new functionalities are being added, they will probably have to be integrated with old ones. This is where wisdom can assist you. It is definitely worth spending a few hours more on each new piece of code to patch up the old part it has to touch. Gradually your development process will fall back on track and there won’t be any more wild panic because of obsolete or faulty routines and functions.

If, on the other hand, your software is rotten to the core and cannot be rescued, well, tough sob, you should probably have thought it through more carefully before putting your hands on the keyboard.

Having said that I’d like to add that rewriting an application is not entirely impossible, but it’s most likely going to be a colossal process which will require large sums of money.

Bookmark It

So it turns out very few people agree with what I said about the kindle just two days ago. In fact, according to Amazon, the gizmo sold out in five and a half hour (source: Engadget)

Regardless I stick to my initial opinion. 399 bucks is allot of dough to cough up for something that has neither the charms nor the solidity of a book, I can throw a big book to make a big noise but if i throw a kindle it’ll just make me 399$ poorer – a futile point but I thought that with my incredible ability to knock books off my bed-side table had to be mentioned. Moreover I don’t recall ever having to plug a book to recharge it for a few hours to be able to read, if I want to read I want to do it right now.

Jeff Jarvis makes a very good point in his post today about the much advertised blog content availability on the kindle. Why would I pay for something that is free on the net?

I violently agree with him. As I said already I’m very passionate about my book collection and a kindle would be of no value for me from that point of view. Either you give me a device capable of accessing any kind of content on the net (for free) or you provide me with a cheap e-book reader – Not a stupidly expensive internet-impaired Frankenstein.

At least this is my view, but it would seem that there’s a generation out there who is still not used to free blogs on the net and is quite happy to pay for the device and the content. It’s a cultural fact, they just don’t know any better.

update: Arrington bashes the Kindle 

Bookmark It