The art of simplicity

I got contacted by someone from my team that INSERTs were failing on one of our database instances. A look at Application Insights showed the following error message in the logs: System.Data.SqlClient.SqlException (0x80131904): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. For an unknown reason, the transaction timeout before it could be committed resulting in a rollback operation and a failing INSERT.  Time to open SQL Server Management Studio and first take a look at the Resource Locking Statistics by Objects report: Indeed, multiple sessions share a lock on the same table. If you want, you can also check the User Statistics report to find out what these sessions are related to:   To fix the issue, I killed the sessions that were causing the lock: KILL 236 KILL 210 KILL 257 After doing that, I could confirm that the locking was gone by refreshing the report: More information Sql...

Yesterday on my way home, I was listening to the SoftwareCaptains podcast episode with Mathias Verraes (sorry, the episode is in Dutch). One of the topics discussed was technical debt and the  question was raised why (most) organizations manage very carefully their financial debt, they don’t apply the same rigor for their technical debt. This triggered a train-of-thought that resulted in this post. Financial debt is meticulously tracked, reported, and managed. CFOs provide regular updates to boards about debt levels, leveraging ratios, and debt servicing costs. Detailed financial statements outline current liabilities, long-term obligations, and repayment schedules. Financial debt is visible, quantified, and actively managed. Yet technical debt—which can be just as crippling to an organization's future—often exists as an invisible, unquantified burden until it's too late. What if we managed technical debt with the same rigor as financial debt? The hidden cost of techni...

A while back I talked about a memory leak we had in one of our applications. As a consequence, it brought the full production environment to a halt impacting not only the causing application but all applications hosted on the same IIS instance. Although we found the root cause and fixed the problem, we did a post-mortem to discuss on how to avoid this in the future. In this post, I'll walk you through the practical strategies we implemented to limit and optimize memory usage for our applications running in Internet Information Services (IIS). n this guide, I'll walk you through practical strategies to limit and optimize memory usage for applications running in Internet Information Services (IIS). Understanding memory usage in IIS Before diving into solutions, it's important to understand how IIS manages memory. IIS runs web applications in application pools, which are processes (w3wp.exe) that host your web applications. Each application pool can consume memory ind...

Today I had to make a fix in an old project that was still using Team Foundation Version Control (TFVC). It immediately made me appreciate GIT a lot more but that is not what I want to talk about today. After making my changes I had to check-in my changes (remark: commit my changes if you want to use the GIT terminology). One of the features that TFVC had to offer was the concept of check-in policies, rules that could be checked and validated before you can check-in your changes in the central source repository. This was a feature we used a lot to improve the quality of the code and capture some mistakes as soon as possible. This time when I tried to check-in my changes, I noticed the following warning in Visual Studio: Obsolete policies are being applied and should be updated. This is because the way that TFVC check-in policies are stored in Azure DevOps has changed. This migration is required for keeping TFVC check-in compatible with the future Azure DevOps versions. The good...

I don't see criticism and (a certain level of) conflict as unhealthy in an organization. The contrary! It is when people stop raising their voice and sharing their feedback that you need to start worrying. It could be a sign that people no longer care and have decayed from commitment to compliance. Beyond following orders As leaders we are constantly seeking ways to drive results. But there's a fundamental distinction worth understanding on how to achieve this:  If we collaborate, the result is commitment. If we coerce, the result is compliance. Commitment comes from within, whereas compliance is forced by an external source. When people comply, they're simply following orders. They do just enough to get by, meet the bare minimum requirements, or check the box. There's no personal investment in the outcome. Commitment, on the other hand, invites full participation, engagement, and discretionary effort. The language of Commitment L. David Marquet states in his ...

The Phi family keeps growing with the recent introduction of the Phi-4-Reasoning, Phi-4-mini and Phi-4-multimodal models. These new models introduce some great enhancements we'll discuss later in this post. But maybe let me start by introducing you to the Phi family. The Phi family The Phi family is a set of small language models created and maintained by Microsoft Research. They are designed to achieve strong performance while being much smaller and more efficient than their larger counterparts like GPT-4 or Claude. Phi’s evolution over the last year has continually pushed this envelope of quality vs. size, expanding the family with new features to address diverse needs. Where the original Phi models focussed mostly on chat and coding activitities, capabilities have now extended to multimodel (vision, speech), function calling and advanced reasoning. Function calling support A feature I’m especially happy with that it finally got introduced into the Phi models is funct...