In article ,   
   Stephen Pelc   wrote:   
   >On 23 Mar 2024 at 10:30:31 CET, "mhx"  wrote:   
      
   >   
   >1)   Make the problem repeatable. This usually involves   
   >       finding out which inputs cause the problem.   
   (-; I worked in train software. Repeating train crashes is not   
   an option.   
   >2)   Gather data about the problem. Observation is crucial,   
   >     so take this stage slowly and carefully. I have seen people   
   >    immediately dismiss exception displays and crash-dumps   
   >    which contain vital clues.   
   This is vital is the problem occurs once in a blue moon.   
      
      
   >Programmers are very rarely taught how to debug. The   
   >problems they face are almost always in their source code.   
   >So why don't they read it more carefully? In particular, why   
   >don't they write a line or two describing the whats and whys   
   >of of a routine before they write the code? The poor relation   
   >who maintains your code for the next 10 years costs your   
   >employer a fortune because you could not be bothered.   
   >As a sidenote to this potential rant, my company has been   
   >using literate programming for 10 years and we believe   
   >that it has increased the quality of our code. Whenever   
   >we incorporate third-pary code into our code bases we   
   >document it to our house standards. This process nearly   
   >always reveals bugs. To produce stable software the golden   
   >rule is to fix the bugs first.   
      
   Never expand buggy code.   
   Hugh insulted me as being a maintenance programmer. Being a   
   hired gun I was frequently involved in fixing defects of others,   
   mostly poorly documented.   
   The first thing to do write comment about what a procedure is   
   supposed to do. Then check the places where it is used against   
   that documentation, hopefully documenting that procedure.   
   Make a testset, and clean up a bit, using the testset.   
   Slowly you gain control of the software. Now look at the defect   
   again. It is gone!   
      
      
   >   
   >Sorry, that turned into something of a diatribe, but the importance   
   >of project management and debugging is one of my buttons.   
      
   Worthwhile article, reflects my own experiences.   
   >   
   >Stephen   
   --   
   Don't praise the day before the evening. One swallow doesn't make spring.   
   You must not say "hey" before you have crossed the bridge. Don't sell the   
   hide of the bear until you shot it. Better one bird in the hand than ten in   
   the air. First gain is a cat purring.            - the Wise from Antrim -   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)