An Introduction to Domain Driven Design

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)


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.

Problem Solution
Fact The problem should be based on solid data, maybe customer feedback or some other data analytics A solution that arises from analysing the facts of the problem. A quantifiable improvement is preferable
Opinion What the developers believe the problem is An opinion about the solution may be a source of new problems or ideas

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.

PayrollHero Team at Domain Driven Design Workshop Singapore

PayrollHero Singapore Payroll Team

Continue reading

Private Polymer Workshop in Singapore

polymer google singaporeWe were fortunate to have Unbug join us today in Singapore for a private Polymer Workshop. Unbug is a front-end engineer at NetEase, the Creator of #MIHTool (iOS Web Debugger Pro) and a contributor to Polymer. His work gets recognized all over the world and it was great learning from him.

Our #AdventureEngineers have rotated and some of our Whistler team arrived in Singapore as well as some of the Manila team so it was a perfect opportunity to take some time on a Saturday to learn.

We are big on learning and are always looking for opportunities to expand our knowledge. A big thanks to Unbug for taking the time out to come chat with our team.

If your interested in joining our team, reach out.

polymer_workshop_1024 polymer workshop singapore

Adventure Engineers Scatter This Weekend

Our team has been full on the past few months so a few of them took this weekend to see the sights around the region. The timing was was a coincident, but we have PayrollHero #AdventureEngineers in 7 cities around the world today. They are in Hong Kong, Shenyang China, Whistler Canada, Singapore, Manila Philippines, Cebu Philippines and Squamish Canada. Below are a few pictures from their adventures.

Nico Suria is in Hong Kong along with Kieran Peppiatt and their girlfriends seeing the sights, doing a little shopping and taking in some of the local culture.

adventure engineer in hong kong

(Nico in Hong Kong)

adventure engineer kieran in hong kong

IMG_0539.JPG(Kieran Peppiatt in Hong Kong)

Bram Whillock, the very definition of #AdventureEngineer takes his outdoor time to the next level. Today, he can be found in the far off peeks of Whistler mountain in Canada.
whistler mountain ruby on rails engineer(Bram Whillock on Whistler mountain ~
photo by Bradford McArthur of

Aidan Sullivan is in Shenyang, China which is one hour north of Beijing. Shenyang is one of China’s very polluted cities as you can see from the picture below.
aidan in china

(Aidan Sullivan in Shenyang, China)china adventure engineer

(pollution in Shenyang, China)
vince paca in cebu(Vince Paca in Cebu, Philippines)
singapore payroll guys(Michael Stephenson and Adam Baechler in Singapore)

Are you looking to join a hard working team? We are looking for a few people to join our team. Roles available: Event Manager, Content Writer, Ruby on Rails Engineer, Customer Service Specialist, Business Development and Marketing Manager.

Watch our Adventure Engineering video below to learn more about us…

Going Open Source with our Singapore Payroll Gems

At PayrollHero we are proud of our work and want to share it with the business community of Singapore.  Over the coming months we intend to release the payroll aspects of our code for free to the public.

That’s right, we are going open source with our Singapore payroll code!  Any developer or interested party will be able to scrutinize the code responsible for Singapore Payroll calculations like CPF.  PayrollHero’s payroll transparency will allow anyone the opportunity to use our code . It will engage the software community to provide the best possible product to all our clients – this will result with furthering our mission to bring Payroll Accuracy for Singapore Employees.

We write our software using a language called Ruby on the Ruby on Rails Framework (we flew DHH to Whistler in 2004). The Ruby community is a passionate collection of developers who have helped us create the HR Platform we have today. This is our opportunity to give back to the community who helped us get to where we are today.

Not a developer but you are interested in learning more about the quality of our code at PayrollHero?  We use a program called code climate that systematically grades every line of code that we write.  It helps us to write the best code possible and gives a neutral and outside indication of it’s quality using a GPA system.  We don’t release anything less than a 4.0 GPA!

code climate singapore payrollSecurity important to you? Our code also receives a Security Scan performed every few hours for potential vulnerabilities. When anything is found we immediately act on the alert.

Here are the links you need for our Singapore Payroll CPF Gem:

Source Code:
Code Climate Score:

Singapore Payroll Software by PayrollHeroWant to learn more about PayrollHero Singapore? Head over to to find out more about our Charter Client Program.

Why You Should Hang Out With Like Minded Individuals

Some of our team members have started monthly round tables with people from other companies in similar roles. Our Chief Architect, Piotr Banasik is in a CTO Round Table and Brandon Strong is in a Growth Hackers Round Table. The idea is to get people in similar roles together to discuss what is working in their businesses, what is not, share experiences and learn new things together.

Piotr Banasik, Chief Architect at PayrollHero met with his CTO Round Table today for their initial meeting. The group so far includes Eran Kimhi, Director of Operations at Spot SolutionsDirk Reiubold, Engineer at WorkatPlay and Alon Sabi, CTO at FunctionPointAaron Hilton, CTO at Conquer MobileCarl Schmidt, CTO at UnbounceDavid Hobbs, CTO at Two Tall Totems and Numan Sachwani, CTO at 7Geese.

I enjoy sitting down once a month with other technology leaders that are outside of my company so that I can learn from their experiences and share things I’m working it. Having a fresh, outside perspective can be super helpful” – Piotr Banasik, PayrollHero

Are you in the Lower Mainland area and want to join? Reach out to learn more about the group and how you can become a part of it.

IMG_7447(Left to Right – Eran Kimhi, Director of Operations at Spot SolutionsDirk Reiubold, Engineer at WorkatPlayAlon Sabi, CTO at FunctionPoint and Piotr Banasik Chief Architect at PayrollHero) @ FunctionPoint Offices

We Are Hiring #AdventureEngineers – Are You Up For It?

Watch our video below that explains how #AdventureEngineers work and what makes PayrollHero different:

Our Engineering Best Practices – what are yours?

This blog post is not for the average PayrollHero user, fan or follower, and not for the faint of heart – we must warn you that it’s quite technical!

However, we would love feedback/comments from you developers/programmers/techies out there!

photoAs a bit of background, the PayrollHero Engineering team has a mandatory weekly meeting with every Engineer in attendance. We use that meeting as a forum to work out any issues we’re having, or discuss stuff that’s been bugging us, and even set policies.

We wrote out some of the best practices we already have in use, and some more that we may want to adopt, and then we voted them in as standards for the team, which will essentially becomes our constitution. Our goal is that these Best Practices will help us create higher quality code, and at the same time avoid some typical internal conflicts.

This list is a work in progress, and every other week we agree to add or modify items. I’ve pasted them here below the break since it’s quite a list!

We’d like to invite feedback on this list. Where this stacks up against stuff your developers/programmers/engineers do? Your comments are welcome, please let us know what you think.

Continue reading

GTD for Software Development at

We have been practicing different aspects of Getting Things Done (GTD) from David Allen at for the past year and in our previous projects at and for the last 10 years. It is a great way to manage all the different items that we have in our minds

I had an opportunity to get a refresher course in the basics from Tim Stringer GTD coach, entrepreneur and founder of We were hosted by the good people at The Office on August 29th, 2012.

Have you ever felt overwhelmed keeping track of all the things you need to do? If you do then you should consider reading Getting Things Done.

My main takeaway from GTD is your brain is great at thinking not at remembering. So you should develop systems that you can trust so that you can get all your ideas, dreams and projects out of your head.

In this article I would like to take you through process of GTD. This is our own particular flavour of GTD so feel free to tweak it for your own purposes. As I deal mostly with organizing tasks to be developed by our engineering team I will be drawing many of my examples from there.

The ideal usage of GTD will allow you to maintain your perspective on your goals and control of your tasks. This is done by making decisions on actions and outcomes and regularly reviewing work that you have taken on. We have 5 levels of perspective and do 5 things to do to remain in control of our tasks. Our goal is not do more or less here we want to do what is needed and have a trusted system in place so that we do not lose track of anything and take the appropriate action at the appropriate time.

How We Keep Perspective

  • Level 5 – This is our Big Hairy Audacious Goal (To coin an over used phrase) for PayrollHero. These are the 3 or 4 reasons and goals we hope to accomplish in the end with
  • Level 4 – The major theme within PayrollHero has five major themes Scheduling, Rollcall, Attendance, Payroll, and Human Resources. Here we try to define what the vision is for each of these themes.
  • Level 3 – Features are like a new project that is going to add some functionality to the  system. This is were we determine the overall purpose of the feature.
  • Level 2 – Enhancements are individual tasks that make up the feature
  • Level 1 – Tickets are similar to enhancements but are smaller in scope. These are usually Bugs, Tweaks, and chores.

How We Maintain Control

1) Collection

We collect all ideas into a central repository for task. For this we use a web app called and we use Googles Drive to share assets like pictures, mock ups, and drawings.  All these ideas are organized into the perspective levels so they can be evaluated later. Anyone form the team can submit an idea.

2) Processing

All this stuff needs to be processed and evaluated. We set aside a specific chunks of time our different task boards depending on the needed frequency. For example: We process bugs daily but Enhancement, Tweaks and Chore get processed weekly.

3) Organize

We normally do this at the same time that we process new items. This is where we prioritize our Backlog and usually happens right after we have processed all the new tasks.

4) Review

Next we review the other tasks in the list to make sure that we have everything needed so they can be worked on by the appropriate people. This can be done at the same time as you organize all your tasks. This is also made a lot easier if you are able to brake your tasks into chuncks that will only take at most a day to complete.

5) Do

Now that everything is processed, organized, and reviewed the appropriate team member can start to do work. This is our pre-defined work. We have a pretty strict ticketing system so there is very little unplanned work. When it does come up we have to say to ourselves. This is going to distract us from our my main goal today do I have to do it now or can it be deferred until later. 99% of the time it can be deferred until later and gets ticketed. Otherwise it gets incorporated into the ticket that was already being worked on. Lastly it is really important to schedule time into your day and week to define work this is were you can review your tasks

If this looks like work that is because it is, my position is pretty much dedicated to doing this day in and out, but it pays out huge dividends in what we get done and having the trust that we haven’t forgotten anything

Thanks for reading. Do you have any best practices for completing work?

Amazon’s “Architecting with AWS” at PayrollHero Manila

Amazon’s AWS ASEAN team, based in Singapore, was looking for a location for their 3 day “Architecting with AWS” event that they were planning on holding in Manila.  We offered the PayrollHero offices, and this morning 35 engineers from some of the Philippines leading organizations showed up for three days of learning from Amazon’s AWS technical team.

Attendees needed to have some existing knowledge or experience with AWS and have a conceptual understanding of the key infrastructure services (EC2, S3, RDS, etc), their features, and how they are used.

Over the next 3 days, attendees will be immersed in all things AWS and will walk away with a great knowledge of what Amazon’s solution is truly capable of.  Here are a couple of pictures from this morning.  Looks like it is going to be a great few days!!