Change is the enemy of perfect design

When I was working as an infrastructure architect, I regularly had interesting discussions with stakeholders related to change. To start off, change is something that is different from flexibility when it comes to designs. With change, I refer to changes in requirements or goals during a project. With this explanation, it is probably clear that change is an enemy of a perfect design, simply because project timelines usually don’t change, even while changes are imposed on a project....

<span title='2023-05-28 16:00:03 +1000 +1000'>May 28, 2023</span>&nbsp;·&nbsp;2 min&nbsp;·&nbsp;399 words&nbsp;·&nbsp;Me

Naming of Services

This is the eternal discussion, should services be functionally named, or given abstract, possible descriptive, names? Personally, I think that (micro)services should be given abstract names. From experience I do see that it has quite some advantages, which I will try to illustrate with simple examples. It frees one’s mind of unconscious biases. What I mean with this, is that if you call a service to its initial functionality, my mind tends to limit the functionality to something that is part of the domain the service is named after....

<span title='2023-05-23 16:43:07 +1000 +1000'>May 23, 2023</span>&nbsp;·&nbsp;3 min&nbsp;·&nbsp;489 words&nbsp;·&nbsp;Me

Carpenter or Cabinet Builder

One question that each developer should ask himself is: “Am I a carpenter or a cabinet builder?”. It might seem a silly question, but there is a difference. It isn’t the case that one is better than the other. This question isn’t about quality of work. When asking this, we also don’t worry about any compensation that one might get. So let me illustrate what I see as the difference....

<span title='2023-05-21 14:47:05 +1000 +1000'>May 21, 2023</span>&nbsp;·&nbsp;2 min&nbsp;·&nbsp;304 words&nbsp;·&nbsp;Me