simple is harder

Challenge

Today I am talking about a coding dojo that my younger and older self are carrying out against each other. A developer is active in the coding dojo all the time. The active developer is free to decide what to develop. But he must explain his thoughts to the other developer.

The company they work for has developed a donation system. People can donate some money and see the total amount of all donations. The challenge for the Coding Dojo is now to develop this system further. The sample application is available on GitHub.

My older self will take on the role of the active developer in this article. Read my other article to find out what my younger self would do instead.

Coding Dojo

Older self: Let’s analyze what the service does first.
It adds the donated money to the project. Then it selects the total amount of donated money. So it does two things.

Order self: Not in general. Maybe you address this because of the the single responsibility principle. In my opinion it adress more code design. In this service two methods are called after each other. But the service and the code must serve the business first, not the other way around.

But I don’t think this service meets the customer’s needs. The donor has to donate money before they can see what other people have donated before them. Maybe it would be better to first show them the money that has already been donated, even without them having to donate money. This might motivate them to donate more money. A second use case for this new query option would be for the project owner to see how much money has already been donated.

Younger self: Which framework do you want to use to solve this problem?

Older self: I don’t need a framework to do this. It is just a matter of rearranging the current code. This is a simple task.
I remove the query part of the service method and add a second method that just selects the total amount of money. I now have two methods in the service.

public async Task<int> GetTotalDonations()
{
  return await Database.GetTotalDonations();
}

public async Task UpdateDonation(int donation)
{
  await Database.AddDonation(donation);
}

I also need to modify the user interface. The user interface can now initially fetch the amount of money donated.

if (firstRender)
{
  await GetTotalDonations();
}

private async Task GetTotalDonations()
{
  Total = await Server.GetTotalDonations();
}

After the user has donated some money, we also need to update the amount. The user needs immediate feedback to feel that their money has been received.

private async Task Donate()
{
  await Server.UpdateDonation(MyDonation);
  [...]
  await GetTotalDonations();
}

Younger self: This will introduce more overhead when we deploy this as a real service. Each call introduces network overhead.

Older self: Yes, you’re right. But separating the functionality into two methods makes our system more flexible. It is more likely to fit business use cases just by combining the calls. So it improves maintainability. If it were really performance relevant, we could just copy the code and both methods could ask for the total amount of the donation. But I don’t think performance is relevant for us in this use case.

Younger self: I see that we separated the query and the command that updates the donations. This is CQRS, right?

Older self: Not really. CQRS is for more complex services where we have multiple services with different databases. And also in these cases you add it only in a later stage when you really want to optimize for more complex queries. But for small projects in early stages it is overkill.
There’s a pattern called CQS, but I did this to add business value to the application and not just to use a pattern.

Younger self: Interesting. Product owner, we are done.

Product owner: I listened to your discussion and it was really interesting. The approach may be interesting. But I want to discuss it with our customers first. We should keep the code in a feature branch for now. Maybe we can also add some more motivational words based on the amount of money already donated.

Conclusion

I realize more and more every day that implementation is not about personal satisfaction. It is about delivering business value to the company, and that is what the company pays me for.

After years of developing and maintaining existing code, I realized that maintenance is the most time-consuming and expensive part of software development. That’s why I prefer simple solutions these days. This includes refining concepts to keep the code as simple as possible. Because simple is harder.

Don’t forget to leave a reaction at this article and then hopefully read about my younger self’s approach.