Draugiem is one of the few social networks that compete with Facebook heads on – and are still winning. We are very lucky to speak today with Ingus Rūķis, their development team lead, about the way development process works at Draugiem.
Tell us about Draugiem. What does your company do and what is your role?
Draugiem is the largest social network in Latvia, we are still ahead of Facebook here. Draugiem was started in 2004 – at the same time as Facebook was started in the United States. We used to have a decent market share in Hungary as well, but we have lost that market and we are currently focusing on Latvian market only. Draugiem has around 500,000 daily active users in Latvia, and probably around 800,000 monthly active users.
I am software development team lead and I have been doing web development for seven years at Draugiem, after which I moved to this management position. I am also responsible for the social gaming part of Draugiem – talking to game developers, making contacts, and so on.
How big is your development team?
The development team is very small. We have historically kept development team under 10 people – we currently have nine developers and two system administrators plus a couple of mobile developers. It is basically the commitment of the people that has taken Draugiem so far. We also do not have separate positions of back-end developers and front-end developers, every developer is doing both front-end and back-end. The only position that is separated is the dedicated C developer, who is only doing the social graph and various other serverside services. Everyone else is multitasking.
Draugiem has been acting quite long as a startup, thus we did not have any project managers, and the team was self-organized and self-directed – the developers used to decide what they want to do and just did it. In the past couple of years, however, we have moved a bit away from the startup culture and introduced a couple of project managers who are working to direct the team.
What is your development process? How often do you deploy?
We ship as soon as something is ready. We do deployments multiple times a day – and the infrastructure is managed so well that we can do changes in a couple of minutes in the test environment and then publish it to the live system. It is so simple that even when new developers start working at Draugiem, they do their first deployment in the first working week. A couple of clicks and it’s deployed.
We do not have any formal Scrum process of timed iterations; our development process is more similar to Kanban. When something is ready, we just deploy – and that’s it.
Are there any downsides to such rapid deployment process?
One of the downsides of the process is that less attention is paid to testing. If something goes wrong, you can just fix it and push it again in 5 minutes. The processes that have weekly deployment have to focus more on the quality before the launch as you can’t deploy a bug fix within 5 minutes. However, it does not mean that we deploy buggy software on a daily basis.
So far we have managed to work this way, and we feel that it is still the way to go. We are able to move very fast, and as far as I have seen in presentations in some conferences, other companies are also heading towards this direction. For example, Odnoklassniki, which is also a social networking company based in Latvia and have a huge user base in Russia, is working to minimize the release cycle. We are right ahead in this release management.
For larger companies the problem is that if you have hundreds or thousand of servers, there is a completely different release process. We need to copy the changes to around 20-30 servers, so it is quite easy and fast. For companies like Odnoklassniki or Facebook, it is way more complicated just because of the volume – 10 times or 100 times larger infrastructure is a big technical challenge. We’re speaking about orders of magnitude here, even multiple orders of magnitude.
Did you make any changes to your approach recently?
We recently introduced a Kanban board for bug fixing. We used to have some bugs hanging around for months, and it was mainly a problem of keeping track of the important bugs and making them visible. As soon as we put the Kanban board on the wall, some of these bugs were fixed in days.
What about testing?
Tester is also one position we do not have. All of the testing is done by developers and by other employees of the company.
Is it automated?
We do not do unit testing, but we use quite heavy service monitoring. I mean checking if the service is working, and what is the result of the service calls, but we do not do any unit testing in the classic sense.
Can you tell us what are the biggest challenges in terms of organizing the development process?
One of the biggest challenges is changing the mindset of developers from self-directed to an organized and directed team. We used to have a culture of developers being the ones who are making the direction of the company. But at some point the management has to step in and put some directions on development. It is quite hard for developers to understand and accept that. That’s some sort of organizational change, and organizational change is never easy.
OK. And what changes to your process do you plan to implement in the future?
We are trying to implement some bits of agile. We have introduced the Kanban board for bug fixing as well as weekly meetings with developers, so the communication and knowledge sharing is improving. Most likely we’ll do some experiments with pair programming, probably will try to implement some bits of Scrum process.
What would be your advice to other companies on managing their development processes?
Hard to choose one! Actually I am reading a book right now, Management 3.0 by Jurgen Appelo, I believe its one of the best books so far on team management. There are a lot of useful insights on team management, leading agile developers and managing agile teams, so the suggestion would be to read that book.
Thank you very much!