On February 1, 2002, I started my journey at Zühlke as a junior software engineer. Twenty years later, I am still here. In this post, I want to share what those 20 years looked like, what kept me going, and why I plan to stay for at least another 20.
Does test-driven development work with legacy applications? That is a question I get a lot, and the short answer is yes. In this video I take a big, ugly WinForms application and walk through how I use TDD to add a new feature without touching the messy parts of the existing code. The goal is simple: show that the test-first mindset works even when the surrounding codebase has no tests at all.
What exactly is TDD or Test-Driven Development, and why do so many experienced engineers swear by it? In this short video I explain where TDD comes from, how the red-green-refactor cycle works, and I walk through a simple C# calculator example that shows the process in action. TDD is not only a development technique, it is a mindset that shapes how you approach every line of code.
Continuous Deployment is the final, most aggressive step in the CI/CD progression. CI proves the code builds and the unit tests pass. Continuous Delivery proves the artifact works in a production-like environment. Continuous Deployment removes the last manual checkpoint: if every test along the way is green, the change goes straight to production. No “deploy” button, no Friday-afternoon release window, no human in the loop for the final step.
Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.
In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.
At first glance, a DevOps transformation seems to be a major undertaking for any company. But with the right approach, you can keep the process lean and agile.
Insight in brief # Start small with a small to medium sized project or product. Select the right people to ensure sufficient credibility and influence. Continuous improvement is key to success.
