I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In this part, we look at how to make manual testing easier and why it matters.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In this post, we look at what we can do to recover well even if a defect finds its way into production.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are. In this part: What would you do if you weren’t allowed to write automated tests? Take a moment and think about what you would do to still deliver quality software if you weren’t allowed to write automated tests. I...
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
When I open my social media feeds, it is obvious: the age of writing code with our fingers is ending. LLMs and agents can write code much faster.
But was it ever about the speed of source code creation? Was writing code only translating requirements into something the computer can understand?
I think not.
While I generate code with LLMs and agents, creating a piece of code by hand has its benefits. So, this is an ode to “slowly” handcrafted code.
Scrum, SAFe and Co., with their sprints, backlogs and masters, are now well known to us. It’s time to explore some of the latest developments.
Link to the talk on YouTube:
In this blog post, I describe the way we currently work as a team to deliver our product (TimeRocket) to our users and customers. This reflects our current understanding of working in an agile* way that matches our needs and skills. We are uncovering better ways of developing software by doing it and helping others do it. Manifesto for Agile Software Development (agilemanifesto.org) As the manifesto for Agile Software Development states, we continuously try to improve our way of working, so...
Target audience: developers Philipp’s comment: Effective Debugging contains 66 recipes that show you how to track, find and fix bugs with less headaches. The recipes are neatly grouped into chapters. Every recipe has a Things to Remember section at the end which wraps up the described technique. Some of the recipes are very basic and should be in every developer’s arsenal; at least after having read the book. Some recipes are meant for the hard to crack cases while some may seem...
This is the seventh post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. I’ve seen several projects that started well, but after about one year into the project problems arose. The developers started to do software archaeology before adding new functionality. They simply weren’t sure any more what happens inside their software. So they went from method to method and from class to class to guess what a change would do...