How to know what is a business-rule is and what isn't?

14.1.2025

I'm currently extending our game, and I'm facing an interesting problem: I need to figure out whether I should extend a business-rule or implement the change in some other way.

I first started changing the business-rule. I stated that the existing rule is only true when the game is in a specific state (I added an early exit). Soon after, though, after showing the change to our UX-designer, I noticed that the change didn't quite result in what I was expecting. It turned out that the states of our game are less granular than I originally thought. What I then did was, yet again, go back to change the business-rule. I stopped, because that didn't feel quite right. I realized that the rule I was meaning to add would've been very presentation-specific: "the business-rule is only true when in this or that state _and_ when state is in this sub-state", and that sub-state even existing is very much a detail of the presentation, and could as well not be there. Yeah, not doing that.

So in this very specific case the "when should I apply this business-rule" is a presentational concern, not a business-rule, and so it shouldn't be applied in the business-rules, but rather somewhere in the presentation-layer. For some reason I didn't realize that first, but it would be beneficial to build that muscle. I'm not sure how though. What are the things that distinct a business-rule from a presentational concern? Maybe the "when should I show" is one. Thoughts?

Diary: Changing a Critical System

9.1.2025

I was tasked today at work to implement a change in design in one critical game-system in our game. At first, I thought I would've gone in and modify the existing systems to support the new requirements, but after thinking about it a little bit I decided not to. I remembered that a couple of months ago,the same game-system was just modified due to a similar change in its feature's requirements. Now I was tasked to basically revert those changes.

I thought that what I would do instead would be to implement the change in a modular fashion, where I wouldn't lose the existing code and its integration-details. I extracted the existing system into a component and hid it behind an abstraction. After that I implemented the change as a separate component, following the same abstraction, and swapped it in the place of the current one.

This kind of refactor-first kind-of change makes a lot of sense, because I made the system extensible in the place that I witnessed being changed regularly, but when would this approach not be viable? That's something I'd like to discuss with someone.

AI Agents and Being Uneasy

19.1.2026

Being certain about the changes I make in code is very important to me. That’s reflected in the way I work, from writing simple and easily reasonable code to structuring commits in a clear way to have visibility on what I have changed. This way of working is deeply rooted in me and I benefit from it greatly.

However, that mentality causes issues when using AI for coding. I have been wondering why I get the feeling that something’s off when asking AI to solve some problems. This is the reason. I know deep inside that I’m entering a dangerous territory. I know I’m sacrificing understanding for speed. It’s simply impossible for me to reach the same level of understanding, and with that confidence, of a problem or the solution when using AI. Not even if I read all of the code it generates. I have to play with code to gain it.

This doesn’t mean that I wouldn’t use AI for anything, but it does give me a better sense of the problems to use it for. Problems that I have already solved a million times, or problems I already know the exact solution to, I will use AI to solve. I will use it as a super-powered auto-completion. However, I will not ask it to write new code or to fix an issue that I don’t yet understand.

It’s clear that with AI we’ve entered a new realm to learn to live in.

Extension-Methods and Flat Code

21.1.2026

I worked on a team using object-oriented programming a few years ago. We had a convention of implementing our business-logic as rich objects. Sometimes those objects got really deep. Sometimes they had a hierarchy of close to ten levels deep, containing sub-models within sub-models within sub-models. Figure 1 has an example of one such object.

Those objects were a nightmare to understand and maintain, since business-logic was scattered all around the different levels of hierarchy. In addition to making the code harder to read (because of all the jumping around required), it essentially locked the hierarchy of the code into a specific form, which was hard to change when new requirements came in.

In another project I worked on later, we had a different convention. We didn’t have rich objects. Data was kept in really barebones objects without any logic in them. Our business-logic was then implemented elsewhere, outside the classes. One of such places was extension-methods

I never really understood the difference in using extension-methods vs methods of a class, but now I found extension-methods to have great benefits in keeping code shallow.

Since extension-methods don’t have access to the internals of the classes they’re extending, it’s impossible to create deep hierarchies within them like rich objects. Therefore, extension-methods, when written correctly, can be used as a guiding force in keeping code shallow. What do you think about this?