Owlly Debugging: Debugging Like an Owl

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:

       FACULTY = 'Computer Science'      -- Can not put a breakpoint here
           SELECT ID

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

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.

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

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.


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.


At the end, I want to thank the folks at Atra VisionSedighe, 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!



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!

This is Owlly Debugging!

About the author

Mehran Davoudi

A former technology geek! Currently a mentor and software architect, working as a consultant for companies with large scale software development.
Why dvd? Read about me (uɒɹɥəɯ)!

View all posts


  • Thanks for your good writing , There is one problem with the tools like LINQ when you are debugging LING you are not directly debugging SQL and what supposed to run finally is SQL and sometimes tools generate final SQL in different way as you expected,But I agree about that it is better than "Owlly Debugging"!

  • @Mehdi Mohammadi, yep you're right. But by LINQ, I mean LINQ to Objects, not LINQ to SQL which is not capable of debugging features as you said. I've just corrected the post to mention LINQ to Objects.

  • we are having a similar situation with Python, i see pycharm has debugging functionality but programmers are not willing to use them(difficulty might be an issue) and they prefer what is known as "statement print debugging", meaning instead of putting breakpoint, they just print variables to the console using print command to see which part of the cod is buggy. it is time consuming and not really practical but i can not get them to use debugger, they think coding with a language like Python means they shouldn't rely on technology too much and not to be spoiled like .net developer. most of them even don't use and IDE, and they prefer more notepad like environments. what do you think about that?

  • Well I think it's a matter of flavor! Some people like dark chocolate, although it is bitter! Sometimes people find joy in doing something in a more difficult way, but it's fun. IMHO, we should separate our business career and personal one. Professional work and tools are required for a high quality product, at the other side, fun and joy is a must for personal joy and fun.

  • I totally disagree with your example, a problem can be broken and tested (and of course debugged) in smaller sections. in your sql example can check maryam records and see what condition is denying the record to appear, in more complex queries you can comment sections by sections and see which one is making more problem. it's all about troubleshooting skills to narrow down your problem to a certain level.
    putting a break point is totally depends on the tooling around a programing language. some programming language like php or python that doesn't have strong tooling like .net is suffering from this, but still, people are able to debug skillfully and successfully by putting echo/print and var_dump here and there.
    I personally do owlly debugging, but if i'm lazy to debug because i feel i'm faster in this way, not because it's hard to debug or there is no way to debug. always there is a way to debug if you are professional enough. at least your RAM is there, go and read the bytes! personally, if I see my juniors are doing this I don't hesitate to scold them because at their level it only means I don't know how to debug.
    there is another kind of owlly debugging that it happens when you write an algorithm base on what you were thinking is right and you don't know any better, but still it doesn't work (again it shows you are not professional enough). owlly debugging, if it takes more than 10 minutes to me means only one thing, you didn't serve your junior years right!

    sadly for your colleagues, if he was here in Europe, he had very hard days

Leave a Reply

Your email address will not be published. Required fields are marked *