How a software engineer fell in love with logistics
For almost 5 years now, I’ve been responsible for developing logistics software at Digitec Galaxus. I’d never dreamed that I’d suddenly become so passionate about logistics. But it just kind of happened. Let me try to explain.
When I started at Digitec Galaxus right after my studies, receiving an offer for a junior software engineer position in a newly set up logistics team, my inexperienced self didn’t quite know what to expect at first. The world of logistics was foreign to me, my course had barely touched on it. At first, I didn’t think it could get as diverse as being with an online store team. And certainly not that I’d ever publish an article about it.
My first encounter with logistics
That all changed quickly. During my very first week, I already visited our warehouse in Wohlen. A Process Engineer guided me and a small group of new employees through the facilities. We were allowed to lend a hand at every link in the chain ourselves. This way, we got to know the people and processes involved. The team leaders who introduced us to the processes learned very quickly that I was a new software engineer. Of course, they couldn’t resist giving me some first suggestions and ideas for improvement. The tour left a lasting impression that I was still processing late in the evening. I was amazed at how people and technology work together in such a coordinated way.
With so many new impressions, I wondered initially what we actually were responsible for. To answer this question, we chose the following team mission early on, appropriately naming ourselves Lords of Logistics: «Products, to distribute them all, to find them, to bring them all from the warehouse and to our customers bind them.» Basically, we’re responsible for the heart of logistics – storing products.
I’d like to introduce you to three of my favourite initiatives (projects) which I was allowed to work on in the last 5 years.
In a flash, my first project: flash delivery
Soon after I started, I was allowed to get involved in a larger initiative: the flash delivery pilot in the city of Zurich. Like many customers, I often want my purchase to be on my doorstep as quickly as possible. Flash delivery is supposed to deliver this (pun intended). Such a feature combines many wishes and expectations, quickly making the solution very complex.
The initiative cut across many areas in our large software landscape and accordingly required good cooperation between all teams involved. Starting with the online shop, where we had to expand availability. Initially, the test applied only to certain postal codes. During checkout, availability also needed to be used to block the dispatch option «flash delivery», as customers expect their order on the same day and don’t want to be suddenly surprised by a lack of availability. Here, we had to provide stable REST interfaces for our online shop teams and meet the required performance and SLA.
Of course, there were a number of additional logistical challenges to overcome. The biggest one, in my opinion, was coordinating all the time-critical processes. We had to make sure orders were processed in time to be picked up by the deadline or they’d miss the truck departure time. And if something goes wrong, we wanted to be able to react quickly by means of good logging, monitoring and alerting.
Moving on to the actual delivery with our partner notime. They needed all the correct data early, only this way can a delivery take place on the same day. However, for notime the process wasn’t quite the same as for their other customers, either. We wanted to send our products unpacked, which meant that notime was required to bundle products per delivery address and enclose the power adapters, if applicable.
And boom, I’ve got my new AirPods which I only just ordered at lunchtime. I look forward to music listening sessions and am proud to have been part of the flash delivery initiative.
The narrow aisle warehouse: the dictionary definition of claustrophobia
Last year, for a similarly large initiative, I had the privilege of taking on the role of Solution Architect. It’s our software development point of contact responsible for software design and implementation. Our mission was to develop an in-house solution for a narrow aisle warehouse, up and running for the 2022 Christmas shopping season.
A narrow aisle warehouse, as the name implies, has narrow aisles. Narrow aisle trucks must be guided accordingly within the aisles, otherwise there’s a risk of collisions with the racks. Furthermore, it’s very difficult to spot free storage units or even find the right storage unit number.
For these reasons, we had to develop processes so that automatic aisle and storage location selection takes place as efficiently as possible. The vehicles should also know about the respective aisles and storage locations so that they can guide employees to the next storage location quickly and in a controlled manner.
We also immediately used this opportunity to bring our team’s code one step closer to the target architecture. For us, this meant that for the first time we were building warehousing software separately from our monolith in a module (= microservice). How the module fits into the overall architecture is something we worked out, as is common at our company, using the strategic Domain-Driven Design Patterns. An example of this can be seen when visualising high-level architecture.
As far as possible, we apply the principle of one module, one team, so we were allowed to give free rein to our desires within our module. We opted for the Onion Architecture with Vertical Slices and CQRS. At the heart of our module, the domain, we also use tactical DDD patterns, such as Aggregates, Value Objects, Domain Events, and Domain Services. At the persistence level, the repository and unit of work pattern make our lives easier.
We’re very happy with the final product as we can now integrate new features relatively quickly and test them with our test suite consisting of NUnit, FluentAssertions, AutoFixture, Moq and Playwright. Of course, there’s still potential for optimisation. One particular example is the integration events that communicate with our monolith and synchronise inventories. However, we’re constantly working to improve our solution.
From Hackfest to warehouse visualisation
Fortunately, we have a developer with a Master of Arts in Game Design on our team, Christian Sami, who saw potential in my prototype and knew exactly how to optimise and expand it. Together with another engineer, he worked on my prototype at Hackfest 2022 and turned it into a useful solution.
They were able to solve the performance problem using several techniques: server side caching of the storage bins, a central texture for all storage units, and a large mesh containing all the boxes. They also included other useful features right away, such as one of my favourites: the fill level as a gradient from green to red. The advanced visualisation from Hackfest is now used daily in our warehouse. It helps staff fill the warehouse more easily and visually identifies problems, such as when there are too few storage units available.
What does the future hold?
There are just as many exciting projects on the horizon as there have been in the past. Currently, we’re busy with expanding flash delivery, to allow 60% of all Swiss households to enjoy faster or even same-day delivery times in the future. At the same time, we’ll also address many technical depts that were somewhat neglected in the pilot, such as migrating as much code as possible from Monorepo into the module.
Does this blog on logistics makes your heart skip a beat? At Digitec Galaxus, you’re sure to find your passion.