Have you ever seen a developer, staring thoughtfully at the monitor for a long moment, not even touching the keyboard and mouse, and still claims that he is debugging some piece of code! It is true, there is some kind of code that could not be debugged line by line. Therefore, in case you can not do anything to debug, you have to sit in front of the computer, stare at the monitor, just like an owl, and try to find a suspicious line in the code. This is what I call 'Owlly Debugging'

Owlly Debugging is when you look like an owl, and spend hours to find a suspicious part in the code.

Owlly Situations

Let's look at this SQL query:

SELECT NAME, AGE
FROM   STUDENT
WHERE
       FACULTY = 'Computer Science'      -- Can not put a breakpoint here
AND    ENTRANCE_YEAR > 2015
AND    ID IN
       (
           SELECT ID
           FROM FOREIGN_STUDENT
       )

Let's consider a bug, reported like this:

A student with name 'Maryam' should be appeared in the list, but unfortunately it is not.

What could you do to check this bug? What are the possible causes?

• Maybe 'Computer Science' is misspelled.
• Maybe ENTRANCE_YEAR > 2015 is the problem.
• Maybe the FOREIGN_STUDENT table has some wrong data.

How could you debug this code other than looking at it!?

Rather, consider this code in a language like C#:

var selectedStudents = new List<Student>();

foreach(var s in students)
{
    if (s.Faculty == "Computer Science" && 
        s.EntranceYear > 2015) &&      // Can put a breakpoint here
        foreignStudents.Contains(s))
    {
        selectedStudents.Add(s);
    }
}

In this case, you can simply put breakpoints and check why some s doesn't match with conditions and is not being added to selectedStudents .

Wouldn't that be great to be able to put breakpoints at following SQL query line to check the value of FACULTY for missing student?

FACULTY = 'Computer Science'

Although it would be great, but it is not possible in a language like SQL. This is one of many situations you feel like disabled to debug the code. Aspect Oriented Programming (AOP) is another well known situation. When you add functionalities by adding aspects to your code.

[DefaultValue(20)]
public int Age { get; set; }

As you see in this example there is no way to debug why [DefaultValue(20)] doesn't work.

Some Solutions

As you see, most of these situations are happening because of the technology being used. I believe that such technologies should be designed with more appropriate debugging solutions in mind.

For example, the designers of LINQ (as a more modern query language) delivered an appropriate debugging approach too. Here, the above SQL query is rewritten using LINQ and lambda expressions?

var selectedStudents = students.Where(s =>
        s.Faculty == "Computer Science" && 
        s.EntranceYear > 2015 &&      // CAN put a breakpoint here
        foreignStudents.Contains(s)
    );

It looks like SQL, but it is not, in fact  it is LINQ. If students is an array, it will be executed as LINQ to Objects. As you see, you CAN put breakpoints in lambda expression bodies (not working for LINQ to SQL scenario). So, although it is a declarative way to query the array, but it has some practical debugging solution.

Conclusion

However, there are lots of situations you have to do 'Owlly Debugging'. Some of well known situations are:

• Declarative languages: like SQL
• Aspect Oriented Programming: When you add functionalities by adding aspects to your code.
• XML configurations: Having lots of XML files to configure the software

Absolutely I am not against the AOP (as a matter of fact I love it and I'm using it in widely) and the other items above. But here, I'm just criticizing their debugging capabilities.

Hence, If you are designing a framework or software using lots of declarative or AOP parts, you should also think about and design proper utilities to make debugging process much easier.

Acknowledgements

At the end, I want to thank the folks at Atra Vision: Sedighe, which her work inspired me in a way that this idea came into my mind. Zohre and Maryam supported the idea and their efforts spread the idea. Also Afshin, as someone absolutely against Owlly Debugging, he always picks another solution: Deep dive into the code!

 

UPDATE:

Recently Afshin found one of our colleagues (Saeed) trapped in such situation and sent me the picture instantly! So, I decided to add it to this post. This picture is Saeed while he is in some Owlly debugging situation!