The PayrollHero offices are buzzing with new energy. This week, the entire team flew in from Manila and Whistler to Singapore and worked through two days of intense training on Domain Driven Design with Kiro Harada. After the rigorous learning retreat, the team emerged with renewed perspective and restless enthusiasm. In an endeavour to contribute to our community, we want to share with you what Kiro taught us.

The learning retreat was conducted by lean and kaizen expert Mr. Kiro Harada. Kiro flew in from Japan and spent time with us both as part of the workshop and to guide us after it.

Domain Driven Design is all about communication. The gap between what developers want to create and what stakeholders in the company understand can be massive, potentially detrimental to the company. Even between developers, it is hard to maintain a common language as domains grow larger. This makes it tougher to model a problem which leads to further miscommunication.

Blind men and the elephant

For you and me, miscommunication sounds like an obvious problem. But what does it mean in a tech company for people who are not familiar with domains and modelling? To give us an idea of what he meant, Kiro told us about the 5 Blind Men and the Elephant. Each blind man gets a part of the elephant: like the leg, the trunk or the tail. Individually, the blind men know everything about their allotted parts. But when they regroup, one man calls his part a tree, the other man calls his part a snake, and so on.

Different perspectives colour reality and computer programmes cannot distinguish between the two. So what can you do to ensure that everyone is on the same page? The solution to the Blind Men and the Elephant problem is for each blind man to observe his part, regroup, model (or draw) what they observed, go back, make observations and repeat the process till they finally put it all together. You collect information and switch positions to ensure that everyone’s perspectives are clearly understood. The idea is to move from a state of –

Not knowing what you don’t know (or alternatively, knowing what you know)

to

Knowing what you don’t know

DDD is intended to take you back to the drawing board, where you design incrementally. The model must constantly evolve – from building a scenario that describes a model which is written into code that creates new scenarios, and the loop regenerates itself. Exploring models with creative collaboration while consciously focusing on the core domain is what DDD helps you do.

DDD in Practice: Modelling a Vending Machine

The concept of DDD can be vague unless you put it into action. Kiro chose to do just that by splitting us into teams and giving us a problem to model. The only instructions were to code for a vending machine.

Round 1: True to PayrollHero’s style, my team decided to code for a machine that vends beer. We got down to writing all components involved in the machine: beer, a tray to hold the beer, a coin collection box, refrigeration involved (liquid nitrogen, of course), landing tray, the works. We then wrote down all the actions involved, inserting the coin, choosing a brand, waiting for the beer. Then we wrote down all possible scenarios: what if too many coins were inserted, what if the power ran out, what if the machine go stuck while vending the beer, what if the beer wasn’t cold, what if… and we went on and on.

Till Kiro came up to us and said our time was up.

We got no coding done. We barely opened a laptop screen. There was no product, just a bunch of ideas. Round one was an epic failure. We had a brief discussion on what to do. Kiro told us we needed to start small. Create a scenario, build a model, implement it and then go back to the drawing board to create another scenario.

Round 2: We needed a fresh perspective. We started from scratch, this time making sure that the developer in the room coded while we built the model. The process seemed slow but was far more efficient. Every non-developer would review the code to make sure everyone understood what was going on. When time was up we had our minimum viable product. By making our core domain small, we had a flexible model that we could work around. It was evident that Domain Driven Design helped us create our MVP within 45 minutes.

Timeboxing: The Bomb

In theory, DDD now seems like a simple idea. Even when you are modelling a vending machine, applying DDD to one problem is easy. What if you are dealing with 20 different problems at a time? Kiro showed us how multi-tasking can wreak havoc on a team. We were made to stand in a circle and pass around a “bomb” in alphabetical order. We were just getting good at it, when Kiro threw in another bomb that we were supposed to pass around in height order. A few seconds later another bomb was introduced that was to work its way around the group in order of birthdays. As you would imagine, we took ages figuring out how to pass three bombs around simultaneously. It was inefficient, messy and absolutely hilarious.

The idea of multi-tasking is just not sustainable. It wastes time and does not capture anyone’s complete focus. Timeboxing is far more effective. Getting work done one at a time allows you to apply DDD, keep everyone involved on the same task and thereby get everyone to focus their energies on a single plan.

Day 1 ended on a high note. Kiro threw ideas on modelling different problems at us and the developers enthusiastically practiced on them. The team was exhausted but an idea was borne out of a full day’s worth of training. We had big plans for the future, with new features in the pipeline.

Day 2 picked off from the previous day’s final tip – timeboxing. When you do tasks one at a time, it’s important to prioritize which feature from your backlog should be worked on. At PayrollHero, developers choose a bunch of issues and then vote on them. After ranking the issues, Kiro suggested we vet through what the problem really is before we go deeper into solving it.

Fact vs Opinion

Once you have identified a problem, it’s worth evaluating whether the problem is relevant or even real. Differentiating fact from opinion is another one of those obvious steps but everyone often misses out on it when you are deep into the process of solving a problem. It’s worth hitting the brakes and breaking down the problem and solution.

Moving from the problem to a solution is what Kiro calls a Hero’s Journey. Using the facts of the problem, developers need to use their imagination to model the solution. The next step is to design the model and then implement the solution. Often the implementation brings up new problems and the cycle begins again. (If you were wondering, the name comes from the Star Wars protagonist, Luke Skywalker, who was faced with the problem of saving the galaxy, then he met Yoda, and finally used the Force to save Princess Leia and bring freedom and peace to the galaxy. Kiro is quite the sci/fi fan).

This marked the end of the learning material that Kiro taught us. After this, we talked about models specific to PayrollHero and practised tackling them. An interesting exercise was to build a simple model, say a delivery system, and throw scenarios at it to see where the model breaks. The entire team enjoyed the brain teasers but more importantly, it helped us look at our product with fresh eyes and a different angle to approach our pipeline ideas.

The next few days are all about using DDD for some rigorous introspection and using the new learning as a foundation for future ideas. We also got the entire team to spend some time together with each other and our new interns. We went out for lunch, dinner and drinks. It was a great experience for both developers and non-technical members of the team. Overall, we learned that modeling can and should be used to make decisions, both for R&D and sales and marketing. It was not just about app development, it was a new way of thinking and building on ideas and executing them. While we are constantly improving our methods and changing our approach, we want the PayrollHero team to stay on their feet and continue being awesome consistently.

Continue reading →