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...
Effective teams: know your code
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...
Effective teams: Good ideas take time
This is the sixth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
A lot of Scrum teams work Sprint per Sprint. They seldom look further ahead than a single Sprint.
While they really tackle problems just in time, define requirements as late as possible to eliminate waste, they still suffer from a big problem: Good ideas take time.
Finding a good solution to a hard problem takes normally more time than a single Sprint.
Effective teams: Always releasable
This is the fifth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. Your code prevents doing the right thing I often see teams that want to do the right thing but can’t. Their software won’t let them. This is caused by lots of loose ends in the source code. Everything is begun but nothing is finished. There are simply too many open tasks. Or there is a lot of technical debt present. Before the team can do what it...
Effective teams: Fits in my head
This is the fourth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
Not even remotely comprehensible
A lot of software is built today by adding feature after feature very quickly without considering understandability and maintainability.
The result is that new features find their way into the software slower and slower because understandability drops over time.
Effective teams: Start with minimal solution
This is the third post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. Big steps When we have a goal in front of us, we tend to think about how we can get there in a single fast step. However, most of the times in software development the goal moves while we are walking towards it. Either because our customer sees our progress and has a better idea, or because we understand the problem a bit clearer and find a better solution...
Effective teams: Plan the day
This is the second post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. Bad coordination Bad coordination within the team is a major reason why teams are not effective. Things are done multiple times (“oh, you already did this? Me, too!”). Unnecessary work is performed because we just assume that this should be done. We miss opportunities to go live early, to add the feature with a simpler, cheaper solution or to act...
Effective teams: Free Jazz
This is the first post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
In free jazz, improvisation is an important part. But the musicians don’t just play whatever they like. If the Saxophonist takes over from the Trumpeter, he (normally) takes over a little part of the melody and then starts to modify it.
We should build software the same way in our team. We should build upon what is already there.
Onion Architecture Article in Method and Tools Magazine
My article about Onion Architecture has just been released in the Method and Tools Magazine. The article contains even more insights into the Onion Architecture and how it compares to traditional Layered Architecture by analyzing code samples with Structure Studio. I highly recommend you read it. Methods & Tools is a free software development magazine on Project Management, Software Testing, Agile, Scrum, Lean, Kanban Requirements (UML, Business Analysis, User Stories), Programming (Java...
How we do the Daily Scrum in my team
In a typical Daily Scrum, every team answers the three questions about what was done, what is next and which impediments there are. We moved away from this form of Daily Scrum because it is not very efficient and not focused on Sprint Backlog items. It’s not efficient because we do a lot of pair programming and several team members work on the same User Story at once. Therefore, some team members could only say “I did the same as already said”. This way of doing the Daily...