Behind the scenes at Coolblue
Matthias Noback
Leaving Qandidate, off to Coolblue
After I had a very interesting conversation with the developers behind the Broadway framework for CQRS and event sourcing the day wasn’t over for me yet. I walked about one kilometer to the north to meet Paul de Raaij, who is a senior developer at Coolblue, a company which sells and delivers all kinds of - mostly - electrical consumer devices. Their headquarters are very close to the new and shiny Rotterdam Central station. The company itself is doing quite well. With 1000+ employees they keep needing more office space.
Paul showed me around all departments and offices, which nowadays span three floors. There’s developer teams everywhere. It’s not a PHP-only company. Though PHP is well represented, there are also .NET and Delphi developers. Coolblue runs on quite a lot of software and hardware.
Heritage
Developers at Coolblue have learnt to call the legacy software they maintain “heritage”. “Legacy software” often has a negative sound to it, while in fact, it’s what enables the company itself to be so successful, so it doesn’t really deserve that negative image. I don’t fully agree with this approach since most of the relevant literature about this subject speaks of “legacy software”, which, to me personally, doesn’t mean anything bad. I’m well aware that anything I write today will be “legacy” tomorrow, because, literally, other people inherit that piece of code and need to maintain it. In my dictionary, “legacy software” isn’t a bad thing (though I know that it often is, so I understand this little play of words).
New things: microservices
Paul mentioned that there is an ongoing struggle amongst developers who rather want to try “new” things, while they feel stuck in the “old” way of doing things. Paul argues that it’s always possible to try something “new” in an older project as well. The infrastructure may not be there for it yet, but introducing it might therefore be even more challenging, as well as more satisfying. I fully agree with Paul on this, and I also like to work on an older code-base and introduce new concepts to it. Anyway, in my personal experience, thinking that you’re better off working on a green-field application, because you can do everything “the right way”, often turns out to be quite a fallacy. I’m sure you’ll recognize this sentiment as well.
At Coolblue, “new things” currently means event sourcing and microservices. They have introduced several microservices so far. Microservices are one of these things Coolblue developers have been wanting to introduce for quite some time. It turned out to be not that hard, but, according to Paul, the key was to keep it small at first. They started by extracting several smaller and less crucial parts from the main application into microservices. You can read about some of their experiences on devblog.coolblue.nl.
New things: event sourcing
Paul and others have done quite some research with regard to event sourcing as well. They haven’t taken the step yet to implement it in their software. Take a look at this slide deck to get an impression of what it might look like for them when they do.
Paul made an interesting observation with regard to “new things”: there is often a mismatch between what a developer thinks of themselves, and what that same developer thinks of other developers. When listening to meetup or conference talks, you may start thinking that you’re way behind on current developments in the world of (PHP) software development. Paul at first felt the same, but noticed that when you actually talk to developers about what you’re doing, it might just as well turn out that you’re doing fine.
Teams
Developer teams at Coolblue are separated based on the features they work on. There is a team working on “pre-cart”, i.e. everything related to the presentation of the products, their categories, etc. Then there’s a “post-cart” team, which works on actually making the sale, payment, etc. Paul himself is moving from team to team mostly, helping everyone solve any issues that they may be facing. This way, he gets a nice overview which enables him to take knowledge from each team to other teams. This also helps preventing the same mistakes from being made in different teams.
Walking through the corridors, we pass a lot of “team rooms”. Walls are made of glass, but each team is still nicely separated from the others. They can see, but not hear each other, meaning that they can focus on what they’re working on, while still feeling part of the organization. It appears that each team consists of about 6 people. This is the right amount, according to Paul; when you add more people to a team, it doesn’t become any easier. Each team has a nice poster attached to the outside wall, showing the passer-by what the goals of this team are for the current quarter.
Operations
Although Coolblue has an “operations” department, developers are supposed to take responsibility for the deployment and functional correctness of the work they deliver. Pull requests need to contain any changes required for configuration management (Puppet) as well as logging and monitoring. Developer teams monitor the runtime performance of the software and any problems that occur in production environments.
Paul says that gradually the organization is moving towards a “devops” culture, where developers are fully able to deploy and configure the code they produce. I’m curious how this works out. I think it’s a great idea. However, I’ve also noticed that many developers are quite reluctant to learn all the subtleties of all the available “operations” tools. They may prefer to do what they’re already good at: developing software (for which they already have to learn so many tools).
On the other hand, creating a working software product doesn’t end with merging the pull request. It has to work on a production server as well, so you have to think about what’s required to run the software and keep it running. So it’s definitely justifiable to ask from developers to learn about “servers” as well.
My current hypothesis is that growing a devops culture is easier when the tools have been selected, and you don’t have to learn to work with Ansible and Puppet, Linux and Windows, etc. It looks like Coolblue is lucky to be in this situation: its developers only need to learn to work with a small number of operations-related tools.
Learning and sharing
Coolblue regularly hosts “behind the scenes” meetups. Paul himself and Victor Welling regularly speak at these as well as other meetups and conferences. Developers are also encouraged to participate in public speaking, but when they don’t want to, there are also regular opportunities to present something internally only. I agree with Paul that this is very valuable for development teams, and of course it’s good for the “attraction factor” of the company. Coolblue itself is growing very fast and that’s why they currently use the slogan “Looking for 100 Developers”. To me this sounds like a pretty big effort, since every company I know of struggles with attracting and keeping new (and good) developers. I wish them the best of luck of course, knowing that developers will be in good hands.