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, and we are still ahead of Facebook here. Draugiem was started in 2004 – at the same time as Facebook began 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 the Latvian market only. Draugiem has around 500,000 daily active users in Latvia, and probably around 800,000 monthly active users.
I am a 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 tiny. We have historically kept a development team under ten people – we currently have nine developers and two system administrators plus a couple of mobile developers. It is the commitment of the people that have taken Draugiem so far. We also do not have separate positions of back-end developers and front-end developers, and every developer is doing both front-end and back-end. The only area 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 well managed, so 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 deploy – and that’s it.
Are there any downsides to such a rapid deployment process?
One of the downsides of the process is that less attention is paid to testing. If something goes wrong, you can fix it and push it again in 5 minutes. The methods 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 use buggy software daily.
So far, we have managed to work this way, and we feel that it is still the way to go. We can move very fast, and as far as I have seen in presentations at some conferences, other companies are also heading towards this direction. For example, Odnoklassniki, which is also a social networking company based in Latvia and has a vast 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 thousands of servers, there is an entirely 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 more substantial infrastructure is a significant 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 critical 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 testings are done by developers and by other employees of the company.
Is it automated?
We do not do unit testing, but we use a 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 instructions on development. It is quite hard for developers to understand and accept that. That’s some 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! I am reading a book right now, Management 3.0 by Jurgen Appelo, I believe it’s one of the best albums 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!
