Is debugging a lost art ?
-
Wait.. are you implying that posting questions in QA ISN'T debugging??
If it's not broken, fix it until it is
Kevin Marois wrote:
Wait.. are you implying that posting questions in QA ISN'T debugging??
With alarming frequency ... yes. :)
«Tell me and I forget. Teach me and I remember. Involve me and I learn.» Benjamin Franklin
-
I like this general discussion - and your post struck a chord - now, I'm not so good at this yet (because I know how to debug & use logging etc so to some extent I 'get away with it' ), but I believe using 'tests'/a testing framework appropriate for whatever dev toolchain is being used, would assist greatly - not sure where it fits in 1-6 but its another 'tool' somewhere in the mix
Unit, Integration, and Acceptance Testing is a whole other discipline with the aim to prevent errors and prove the code meets requirements and works. Debugging is what happens when something slips through the Testing. Both have the goal of creating bug free code, but Testing is proactive and Debugging is reactive. Testing usually has the pointy-haired manager complaining about all the effort the doesn't create new code. With debugging there is usually panic and pointy-haired managers demanding status every 10 minutes. Poor PMs will try and save time/money by doing a poor job of Testing and then blame the programmers when they more than pay for it with bugs, debugging, and large code update/rewrites. Ideally, when you are trying to fix a bug you should write a Unit Test to verify the bug, and validate the fix. Then fix the bug. The Test will tell you when you are done and the pre-existing Tests will tell you that you didn't break anything else.
-
The more I comment on, or answer, QA questions here, the more I think that, apparently, having no knowledge of how to debug seems a common feature of posters. Of course, that conclusion could just be an artifact of the fact that a major reason for the use of CP QA is because the posters are: 1. here because they are tolerated here ... in comparison similar questions on StackOverFlow would be quickly closed ? 2. they're not getting any education about how to debug ? no one showed them how to debug ? they just didn't think of it ? 3. for whatever reasons, they never bother to study the wonderful (to those of us who remember coding in the ancient days) tools in Visual Studio for debugging ? Of course, we could also take the most negative general view: CP QA attracts the lazy, the ignorant, gimme-codez beggars, and the homework-shirking; but, I choose not to take that view, although it's obviously true, to me, that some posters could be described that way. I think we, "older," programmers (from before ... 1991 ... the time of VB with an IDE) had no choice but to learn how to debug, because: we didn't have CodeProject, StackOverFlow. Although, remembering those early days of VB and the UseNet forum ... and the Microsoft UseNet forum for VB ... where people like the amazing Nicholas Paldino (back then's equivalent of OriginalGriff) seemed to be providing support 24/7, there certainly was some support, and community. Microsoft did start providing some MSDN content on how to debug about the time of .NET 3.0; for example: [^]. But, I would assert that valuable material on how to debug was available early on ... to those who looked for it. Well, what to do with/for/to people who do not have a clue about debugging ? I could fantasize there's a forum on CP that is really an on-line course on debugging that takes the user through a series of coding "challenges," demonstrating/educating-about debugging in Visual Studio. But, I doubt the people that actually needed it would use it. And, I'd estimate the "technical cost" to CP to implement that would be prohibitive. On the most general level, I wonder if the expectation of many new programmers ... an expectation driven by marketing that portrays programming as "easy" if you just get the latest whatever ? ... is that they simply don't need to know about debugging ? I'd call that: a "weak hypothesis." When I have students (private, th
I learnt debugging back in the early 80s for R/Basic, an interpretive language from an OS called Pick. There was no such thing as an IDE back then, pretty much a suck-it-and-see approach. That's where I also learned that what I really did was 85% plan, 5% code and 10% debug. I also learnt that I could move those goalposts to as much as 93% plan, 5% code and 2% debug. Debug back then was embedding print and input statements to step through the code throwing the values of variables to my screen (or lineprinter) as I went. Now, with all the wondrous tools I am probably doing 45% plan 10% code and 45% debug because the tools have made it easy. I think they try and rephrase what I do as 'Agile'. I simply call it lazy (and, yes, I know that infers I am lazy, lets remove the inference. I am http://codeproject.cachefly.net/script/Forums/Images/smiley\_wink.gif )
-
Member 11683251 wrote:
I think that debugging is something that is skimmed on when it comes to programming education.
Agreed! When I went through programming classes (98-00) we were never taught how to debug. I got a part-time programming job in my junior year and remember finding out about breakpoints and the magical F8 (now F11) key! I also remember starting in classic ASP and javascript and having to get creative on the debugging using alerts or response.writing variable values to see what was happening. It's sooo much easier these days! :)
"Go forth into the source" - Neal Morse
We did learn about break points but they are so basic that its almost criminal leaving them out of education. I think learning by doing is fairly important when it comes to debugging, having a small course where you learn about the most common tools and have to solve a few problems via finding bugs in code isn't something that's too difficult. I mean I could prepare several cases in a short order to be used. Similar with your experience with asp and javascript I did some programming with unity and monodevelop a few years back. We were having trouble getting the IDE's tools to work with Unity and was pressed for time so there was some creative logging and peak functions written to work around that. We also got a lot better at looking at the code more attentively.
-
Its not the art of debugging that is missing, its the whole process of problem solving for which debugging is a tool. Most programming quickie course teach how to write code, but not how to 1 methodically analyze problems, 2 review the evidence, 3 read the code, 4 formulate an hypothesis for the primary cause, 5 use the debugger and other available tools to prove or disprove the hypothesis, 6 repeat as required. This is stuff you had to do when compiles took many minutes and had to be submitted to a mainframe, possibly on punch cards. Now, with a couple of seconds to compile massive solutions, you see them hacking at the code and re-running to see if it is fixed, not checking to see if their changes have 'suboptimal' side effects.
That's a very nice summary and I fully agree with it! What a glorious time when we had to read memory dumps in order to find a bug that was caused by a module written in Assembler :-)
-
The more I comment on, or answer, QA questions here, the more I think that, apparently, having no knowledge of how to debug seems a common feature of posters. Of course, that conclusion could just be an artifact of the fact that a major reason for the use of CP QA is because the posters are: 1. here because they are tolerated here ... in comparison similar questions on StackOverFlow would be quickly closed ? 2. they're not getting any education about how to debug ? no one showed them how to debug ? they just didn't think of it ? 3. for whatever reasons, they never bother to study the wonderful (to those of us who remember coding in the ancient days) tools in Visual Studio for debugging ? Of course, we could also take the most negative general view: CP QA attracts the lazy, the ignorant, gimme-codez beggars, and the homework-shirking; but, I choose not to take that view, although it's obviously true, to me, that some posters could be described that way. I think we, "older," programmers (from before ... 1991 ... the time of VB with an IDE) had no choice but to learn how to debug, because: we didn't have CodeProject, StackOverFlow. Although, remembering those early days of VB and the UseNet forum ... and the Microsoft UseNet forum for VB ... where people like the amazing Nicholas Paldino (back then's equivalent of OriginalGriff) seemed to be providing support 24/7, there certainly was some support, and community. Microsoft did start providing some MSDN content on how to debug about the time of .NET 3.0; for example: [^]. But, I would assert that valuable material on how to debug was available early on ... to those who looked for it. Well, what to do with/for/to people who do not have a clue about debugging ? I could fantasize there's a forum on CP that is really an on-line course on debugging that takes the user through a series of coding "challenges," demonstrating/educating-about debugging in Visual Studio. But, I doubt the people that actually needed it would use it. And, I'd estimate the "technical cost" to CP to implement that would be prohibitive. On the most general level, I wonder if the expectation of many new programmers ... an expectation driven by marketing that portrays programming as "easy" if you just get the latest whatever ? ... is that they simply don't need to know about debugging ? I'd call that: a "weak hypothesis." When I have students (private, th
-
The more I comment on, or answer, QA questions here, the more I think that, apparently, having no knowledge of how to debug seems a common feature of posters. Of course, that conclusion could just be an artifact of the fact that a major reason for the use of CP QA is because the posters are: 1. here because they are tolerated here ... in comparison similar questions on StackOverFlow would be quickly closed ? 2. they're not getting any education about how to debug ? no one showed them how to debug ? they just didn't think of it ? 3. for whatever reasons, they never bother to study the wonderful (to those of us who remember coding in the ancient days) tools in Visual Studio for debugging ? Of course, we could also take the most negative general view: CP QA attracts the lazy, the ignorant, gimme-codez beggars, and the homework-shirking; but, I choose not to take that view, although it's obviously true, to me, that some posters could be described that way. I think we, "older," programmers (from before ... 1991 ... the time of VB with an IDE) had no choice but to learn how to debug, because: we didn't have CodeProject, StackOverFlow. Although, remembering those early days of VB and the UseNet forum ... and the Microsoft UseNet forum for VB ... where people like the amazing Nicholas Paldino (back then's equivalent of OriginalGriff) seemed to be providing support 24/7, there certainly was some support, and community. Microsoft did start providing some MSDN content on how to debug about the time of .NET 3.0; for example: [^]. But, I would assert that valuable material on how to debug was available early on ... to those who looked for it. Well, what to do with/for/to people who do not have a clue about debugging ? I could fantasize there's a forum on CP that is really an on-line course on debugging that takes the user through a series of coding "challenges," demonstrating/educating-about debugging in Visual Studio. But, I doubt the people that actually needed it would use it. And, I'd estimate the "technical cost" to CP to implement that would be prohibitive. On the most general level, I wonder if the expectation of many new programmers ... an expectation driven by marketing that portrays programming as "easy" if you just get the latest whatever ? ... is that they simply don't need to know about debugging ? I'd call that: a "weak hypothesis." When I have students (private, th
I can only speak for myself. I never really learned debugging, I just knew that debugging is that thing that pops up when you press "Go" in your IDE. This was my starting point. Now, I don't want to miss my debugger. I've learned everything on the go, I've learned how to watch values, set breaking points, watch memory (those pesky C coders in my team hate symbolic debugging and love calculating pointers instead of using them as references). I will never ever touch a development environment without a debugger again. Except Arduino, but this I do as a hobby, not during work. Debugging is, I think, never obsolete. All documentation out there won't help jack if my code misbehaves. As for what to do for them, well, if you enconuter a question answerable by debugging, don't give the man the fish, teach the man how to fish. That is, don't answer the question right away, but write a longer post about how to find it yourself. This isn't easy, first it takes much longer, second it will be shot down by people who just love giving hungry fish instead of teaching them to fish. But hey, if someone wants to learn, then he will read!
-
Unit, Integration, and Acceptance Testing is a whole other discipline with the aim to prevent errors and prove the code meets requirements and works. Debugging is what happens when something slips through the Testing. Both have the goal of creating bug free code, but Testing is proactive and Debugging is reactive. Testing usually has the pointy-haired manager complaining about all the effort the doesn't create new code. With debugging there is usually panic and pointy-haired managers demanding status every 10 minutes. Poor PMs will try and save time/money by doing a poor job of Testing and then blame the programmers when they more than pay for it with bugs, debugging, and large code update/rewrites. Ideally, when you are trying to fix a bug you should write a Unit Test to verify the bug, and validate the fix. Then fix the bug. The Test will tell you when you are done and the pre-existing Tests will tell you that you didn't break anything else.
This topic struck a note with me as well, as I find that most new developers have next to no skill in doing any sort of deep debugging. I find myself in the group that learned debugging in the "old days" - I actually honed my skills in the '70s on the early hobbyist computers, teaching myself machine language/assembler programming (side note - first processor I programmed on was an 1802 :-D ). Back then there wasn't a lot of good programming documentation - you were lucky to get a description of the ports/memory map locations and a brief description of each. And there was internet as such, so unless you were part of a user group or had access to a good local BBS, you had to figure these things out for yourself. So often, you would have to really think through how to solve a problem, find the write approach for the hardware you were using, and then write a test case you could work through in a debugger to see what was actually happening. You would learn something, update the code, and try again. This iterative approach was great in getting a deep insight into your computer environment, and it really made you think through the problem you were trying to solve. (side note - I remember loving Microsoft CodeView, and how you could bring up the application in your EGA display, and the debugger on your monochrome display). Yes, today we do have test frameworks to help catch problems before they occur. But it is next to impossible to anticipate every possible situation. Especially when you have to integrate 3rd party libraries and frameworks, which may or may not work precisely as documented. There will always be times when something goes awry, and you better know how to dig into the deeper levels of the code with a debugger, isolating the issue, and coming up with a reasonable fix. I don't think debugging per se is a lost art, but there are certainly degrees of expertise to debugging. I know that when I have an customer support issue that needs to be fixed, the first thing I do is not to pull up the debugger, but think about the problem, trying to think about what the issue is, and the approaches that might be required - in short, come up with a plan. I find that in doing this first, I tend to have a better idea of where in the code to look at first, and what hints at issues I should be paying attention to, and what approach I should take to debugging the code. A lot of this is simple experience. Those of us from "the old days" didn't have a lot of choice, and had a lot of experience in debug
-
OriginalGriff wrote:
Debugging isn't just a skill, it's a state of mind
Hi Griff, I like those words ! But, I keep thinking that the situation vis-a-vis debugging knowledge would be equivalent ... for automobiles ... to someone who only uses one forward gear in the gearbox, and tries to go backwards by making a full-circle turn ... then wonders why they get stuck in traffic.
«Tell me and I forget. Teach me and I remember. Involve me and I learn.» Benjamin Franklin
Griff's right, in that it's a systematic approach to finding the problem. That's not new or old developer, it's more of "does developer understand the problem, and approach a solution in a logical manner" versus "let's try to hack some stuff together, and see how it goes."
-
When I was in HS taking CS we had an entire section on learning to use the debugger. That was because we were taught by someone who knew it was important to understand the entire process no matter the language. Starting with Pascal, then moved into C++, Delphi, Java, etc. In college, one of the required courses for all CS majors was Logic. Imagine requiring someone know how to think through a problem! More often than not, when I get called over to help fix someone else's code because it won't run they have done zero debugging. If I ask if they have added breakpoints and stepped through the code all I get is a blank stare like I've grown a second head. Gotten some of them trained because I stopped helping them if they hadn't. Some of the logic I've seen just hurt my brain. Why on earth would you fire a request to get all the information for a record for each and every page during onload? If you don't need it or it doesn't change, why do you get it again? Are you worried that the database fairy decided to play a prank on you? Along with debugging, I question if orders of efficiency (Big O notation) are taught. It is like when computers got powerful, all the basics got tossed out the window. :sigh:
When I was in University I took a few Electrical Engineering courses (counted for credit towards CS degree). ELEC 256 was all about basic circuit design, using standard gates (AND, NOR, etc.). Beyond the fact it was a lot of fun, it taught me a lot about basic logic theory, and ways to optimize logic circuits (simplifying circuits through Venn diagrams and such). Since that time, I find I still apply those same techniques when programming, for example simplifying a complex set of logical conditions into a much smaller and simpler set of conditions. Do such things get taught anymore in schools? Especially tech schools (as opposed to University or College), where there might be less emphasis on topics and Logic Design, Linear Algebra and Calculus, etc.?
-
When I was in University I took a few Electrical Engineering courses (counted for credit towards CS degree). ELEC 256 was all about basic circuit design, using standard gates (AND, NOR, etc.). Beyond the fact it was a lot of fun, it taught me a lot about basic logic theory, and ways to optimize logic circuits (simplifying circuits through Venn diagrams and such). Since that time, I find I still apply those same techniques when programming, for example simplifying a complex set of logical conditions into a much smaller and simpler set of conditions. Do such things get taught anymore in schools? Especially tech schools (as opposed to University or College), where there might be less emphasis on topics and Logic Design, Linear Algebra and Calculus, etc.?
I was required to take an EE course for my degree, very similar to what you mentioned. By that time I had already taken my general Logic course and understood the theory but not how to optimize the paths. Complete agree with you about still applying those techniques on the job. The better I can filter down the initial dataset, the better the server handles that complex logic, the less data transfer back and forth and faster response times. At least most of the time. The answer to your question is "It depends", a friend of mine who attended the same Uni and went after a Management of Information Systems degree instead of a Computer Science degree did not have to take the Logic, Calculus, and other theory classes. He got a BB, I got a BS. He learned how to make a program run but he did not learn how to make it run well. He is really good at Copy/Paste.
-
BillWoodruff wrote:
Well, what to do with/for/to people who do not have a clue about debugging
An article describing/demonstrating the basics of debugging and I imagine OG would put in his database as a stock answer where appropriate. Debugging c# is simple, an article would suffice, I would not like to do the same for browser/asp.net/mvc/javascript/etc... there is a lifetime of wasted effort there!
Never underestimate the power of human stupidity RAH
