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 very obvious. I like the completeness of Diomidis Spinellis’ approach. It reminds us that successful debugging starts with mastering the basics. If you’re already familiar with a technique, you can always jump ahead to the Things to Remember section and continue with the next technique.
If you’re a .NET developer like me, you will appreciate the tooling you get out-of-the-box even more after having read the book. Though for some of the recipes in the book I would like to see a sample for the .NET universe.
To have a more complete list of Debugging Tools in the .NET Universe and insight on how to use them I’m going to post more articles in the next couple of months.
The book is definitely worth a read and serves as a reference for the more advanced, rarely used techniques.
Go grab your copy today and let me know what you think about the book. Which technique did leverage your debugging skills the most?
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 (or possibly break).
Their software had become a black box.
Once the team cannot predict the impact of a change, estimations are impossible. The change may take one day when everything just works out fine. Or the change may take several weeks because the change results in a cascade of follow-up changes (also known as bugs). If the team can not even roughly estimate what a change costs, the team cannot plan anymore. They cannot say whether a certain feature is worth building (value is bigger than cost). Therefore, they cannot decide anymore what to do to make a profit.
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.
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 needs to do, it has to pay back a lot of technical debt. And there is often not the time for that. A third cause is lack of automation. Everything has to be done by hand. This is error prone and slow. And all takes too much time to do it right, so just add a shortcut more to get it done. But this makes things even worse the next time a decision has to be made.
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.
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.
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.
When the goal moves and we wanted to get there in a single big step, we invested a lot:
- we designed the whole solution up front and
- we probably implemented code that is no longer needed and needs to be removed again (resulting in additional costs)
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 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 on a good idea. Or we simply build the wrong thing because of a misunderstanding.
Plan the day
In Scrum we have a great opportunity to coordinate within the team on every day at the Daily Scrum.
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.
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
Open Source Tools, Software Process Improvement (CMMI, SPICE), Software Architecture, Software Development Jobs
Subscribe to Methods & Tools if you are not afraid to read more than one page to get smarter!
The newest spring edition contains the following interesting articles (including mine):
- The Principles of Done – How to Get Done Done in Scrum
- Doing Valuable Agile Retrospectives – Why, When and How to Perform Retrospectives in Scrum
- Chop Onions Instead of Layers – for a Better Software Architecture
- Ranorex – Automated Testing Tool for Desktop, Web & Mobile Applications
Download the article directly and for free on their website! I suggest you also click the subscribe button to get notified when the next magazine is published. I would like to thank Franco Martinig for giving me the possibility to publish my article in his magazine!
Remember: Chop onions instead of layers and turn your tears of sorrow into tears of delight.
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 Scrum makes it hard to plan the next 24 hours as a team, too. Planning the next day is a team task and cannot be answered by a single team member for him- or herself.
So, what do we do then?