Work


Me and my work

I've been working in the internet business since 1999 and I think I will never stop. I like it so much because it is always changing and there's new problems to solve. I also like to do things simple. As my good friend Tobias said:

How hard can it be? No, the question is "How easy can we do it?"

Keeping things simple and easy is always the best!

When it all started

Me & my computer

It was a Commodore 64 that changed my life in the 80′s (thank you mom and dad!). I wanted to play the latest games (Gary Linekers soccer still hunts me as the best game ever), and started reading computer magazines.

Hmm you could actually program the computers? I discovered the wonderful world of Basic. After a while I moved on and started doing assembler, upgraded to a Atari ST, trying to learn the dos and dont’s.

Spray

Spray

Ten years later, I started to work at Spray.se (a dot-com company that survived and I think still exists). Spray was Swedens version of Yahoo, a portal that was supposed to be the internet.

The economy went down and Spray was purchased by Lycos Europe. Lycos of course wanted our development center in Stockholm called Spray Labs, lucky for me I have already started working there.

Spraydate@Spray Labs

Spray Labs was approx. 40 people, developing different products: A webmail product, a messenger client and of course the dating service, called Spraydate. Spraydate was the biggest dating site in Sweden at that time, and also existed in seven more countries (where it was called Love@Lycos).

The internet economy was still not doing good, so alot of people had to leave the company, and I was luckily one of the people that wasn't sacked. We become a small team (less than 5 people) that was responsible for the dating service, and I become tech lead/architect for Spraydate.

The code was a mess, there was about 200 000 lines of code and the performance was bad, the site could only have a couple of 1000 simultaneously users, until it completely overloaded the database. It didn't scale at all. The Java backend had been developed by more than 30 different people over the years and it was really a learning experience to go through the rows of code and try to find the biggest design flaws/bugs.

Spraydate was built with a three layer separation in the Java code: the Platform that hold the functionality to create Java applications, like a log system and a connection pool (the kind of things that you today don’t code yourself), the Community Platform that hold functionality specific for communities (a message box etc) and specific Spraydate code, the code that did the matchmaking.

I discovered two interesting design issues at the beginning: The user object was separated into two different objects. One small with only the information that was going to be displayed when user was showed as links, linking to the users profile page. The object had information like the alias of the user, the unique id, the gender and the age. The other object contained the rest of the information of the user. The objects was populated by two different database queries and contained in two different object caches.

All over the site, users was displayed by the first small object, one page could easily display 50 user objects. The backend had some functionality to collect information of which users to collect for each page, so when 50 users should be displayed, it usually ended up in 5 database queries to get hold of the user information.

One day some project manager decided to show one field more of the user, when showing the user link. The object structure wasn’t changed so for the page that displayed 50 users, it generated the usual 5 queries + 1 query per user to get hold of the extra information, ending up in 55 queries for that page. There was a couple of problems: The requirements was changed but the design wasn’t, the design wasn’t robust from the beginning and there where no way to measure the increased number of database queries.

The other design issue was the use of the connection pool. Every function of the application had their own connection pool, meaning if there where 30 functions, there where 30 pools configured. 30 pools, with max connections set to 5 would then generate maximum 150 connections to the database, per front end server.

If a function got a boost of requests, it would take the maximum of 5 connections and wait until the pool got a new one free, even if the rest of the pools wasn’t busy! This design couldn’t take so much load and it really slowed down part of the system. There wasn’t any separation of read and write connections and there was no way to see how many connections that was used by each function.

What did I learn? Well, always make sure that you can see exactly what happens with your application (metrics!), add good logging and ways to measure how your application is doing. And working in a small, very skilled team is the best!

XCAP & Josh

I started working at Josh, a company with a Java community engine called XCAP. It was a small startup company with people that all have worked at Spray. The product have (it stills exists today) social media functions like forum, blog & comments, you know, the normal social media stuff.

The thing with XCAP is that we developed some really cool features for managing heavy load (it is not perfect, but a good start). The bad parts was that it was too hard to use & understand. I've learned that lesson now.

The platform was used by the biggest media comapnies in Sweden & Finland (see my cv for a complete list).

Sony Ericsson, Sony Mobile shop & Cybercom

Trying out life as a consultant at Cybercom, I started working with SonyEricsson.com (now Sony mobile), being in teams both in Stockholm & Mumbai. The site sonyericsson.com supported 40 different languages & almost 80 different countries, however it was static content & not the same dynamic user generated content as I worked with at Spray/Josh.

Now I work partly with the Sony mobile:s internet shop, with a team located in Mumbai, India (I love it!) and doing web performance things for other customers.