Wolters Kluwer

Making it hard for developers to develop It seems to be very hard to create an environment as a developer that mimics the problem at hand. Often, your task is to take a bug in the development environment so that you can debug it. In fact, I would say that is normally what you do most of the time as a developer, period. A defect is reported to you, and you want to reproduce it so that you can put in logging and debugging and figure out what the problem is. The main challenge is to make an environment in your development environment that accurately depicts the environment in which the user experienced the bug. But they seem to make it as hard as possible for the developer to do that by using a deployment mentality. Speaking with Copilot, we discovered this: Why can’t you reproduce your bug Now we can say it very concreely : ❗ You’re running <your app>… ❗ But your Bar is from some other version That mismatch alone will cause: different HTML output different JS includes different beh...

Spending $$$ on software that one can get for free In this installment, we will look at the curious fact that large corporations tend to spend millions of dollars purchasing software and licensing when free, and arguably better versions exist. The case here is Docker Desktop, which is licensed, vs just plain old, free Docker CE. I hear Docker Desktop on Windows can require licensing. Is there a standard, open source, free version of Docker for Windows? You heard correctly. Docker Desktop is free only for personal use, education, open-source projects, and small businesses. If you work for a company with more than 250 employees OR more than $10 million in annual revenue , Docker Desktop requires a paid corporate subscription (Pro, Team, or Business). However, Docker itself (the engine) is completely open-source and free. The restriction is only on the Docker Desktop GUI application wrapper . If you want a standard, open-source, and completely free setup on Windows for commercial us...

Maintaining a stable environment Imagine this: You’re deep in the zone, fixing a bug, and you need a solid way to validate email addresses. You check your local environment, see Email::Valid it sitting right there, use it, and write some clean, beautiful code. Local tests pass. Life is good. Except life isn't good, because you just stepped into a deployment minefield. I just found out that our development Perl setup is fundamentally different from production. Not only are the core versions mismatched, but the CPAN modules are completely out of sync. That Email::Valid module I used? It doesn't exist in QA, Integration, or Production. If that code gets pushed, it’s an instant, catastrophic runtime crash on launch. But wait, it gets better. When I raised the red flag to the powers that be, expecting a quick "Oh damn, good catch, let's fix that," I got a shrug and a literal, "That's just how it is." Apparently, environment parity is just a myth we te...

  The Day I Couldn’t Answer the Simplest Production Question There’s a question every developer asks instinctively when something breaks: “Is this also broken in production?” It’s not a sophisticated question. It doesn’t require deep observability, distributed tracing, or a fancy dashboard. It’s the most basic sanity check in software development. And yet, in some environments, answering it is surprisingly hard. The Setup You’re working in a dev environment. You make a change—or maybe you just stumble into a bug—and something clearly isn’t working. Your next step should be obvious: “Let me check production and see if this already exists.” In a healthy engineering environment, this is trivial: You log into production (or a read-only version of it), or You hit the same endpoint in prod, or You use a staging environment that mirrors production and runs the exact same version Within minutes, you know: ✅ “Yes, this is already broken in prod” ✅ “No, this is something I just introduced” T...