Representative comments



  • I have anonymised the people responsible and a few other vital details but I'm sure you will recognise your own work.

    //DANGER WILL ROBERSTON< DANGER!!!!
    //Do NOT attempt to increase the font size of the display strings...
    //BAD THINGS HAPPEN. XXXXX XXXXX suggests it is down to YYYYY being
    //too small to handle the address of the font. So even though the Arial_24
    //has all the characters, we cannot display them ... great. Just great!

    And anyway, I thought it was Robinson?

    //Yes, it is a goto label...live with it

    Thank you, I will and we will raise a family of little GOSUBs together in our country cottage.

    //using the (x*y)/z definition, the unit will self reset ... using the
    //one below ... it did not. Of course, this is based on a sample of one ...

    That's what we at this company call 'Rigorous Testing'.

    //the following line makes no sense...

    ...so I said to the project manager, "INTERface, I thought your said IN HER FACE" and that's how I lost my second job.

    //I know xMax and xMin are swapped ... they are swapped
    //in the original code!
    //IF you unswap them ... the YYYYY stops working for the small
    //YYYYY. YOU HAVE BEEN WARNED!

    That sounds like a challenge.

    //The idea behind the following code was to have dynamic text
    //field ... it did work, in the snese it wrote to the screen, just not
    //at the same time as the buttons ... oh dear

    So it did work in the didn't work kind of sense of working?

    //DO NOT OPTIMISE THIS CODE ... bad things happened on the calculation

    I'm scared.

    //alas calling these routines causes the screen flash
    //to go r-e-a-l-l-y s-l-o-w

    The classic "Please, I know its bad, I don't like it either, don't think badly of me for it! I'm a good guy, I love my kids, its not that I'm a bad programmer you know its this company!" comment.

    //XXXXX NN May 20YY -- do not optimise these lines of code, otherwise SPI_adr is not
    //properly calculated

    Okay.

    //blowing screen...

    Lucky screen.

    //write to permanent data, or something

    I'll take something, I like to live on the wild side.

     

     



  • @EncoreSpod said:

    ...so I said to the project manager, "INTERface, I thought your said IN HER FACE" and that's how I lost my second job.
     

    I hardly know 'er face!



  • @EncoreSpod said:

    //DANGER WILL ROBERSTON< DANGER!!!!

    One of my co-workers liked to put this in his comments to get people's attention. Though, to give credit where credit is due, he did spell "Robinson" correctly.

    Currently I'm doing his job and my job, because he got fired a few weeks ago.



  • Yay embedded device code!?

    I've maintained projects with this type of defensive commenting, and let me tell you it's no laughing matter. With projects like this, any change requires full regression testing.



  • @EncoreSpod said:

    //DANGER WILL ROBERSTON< DANGER!!!!
    //Do NOT attempt to increase the font size of the display strings...
    //BAD THINGS HAPPEN. XXXXX XXXXX suggests it is down to YYYYY being
    //too small to handle the address of the font. So even though the Arial_24
    //has all the characters, we cannot display them ... great. Just great!
     

     

    Misspelled name aside, this sounds like a legitimate "don't do <thing that you'd think would be OK> because it triggers a WTF in component YYYYY".  Depends on whether YYYYY is developed in-house, and (if not) how much trouble it would be to replace.

     @EncoreSpod said:

    //I know xMax and xMin are swapped ... they are swapped
    //in the original code!
    //IF you unswap them ... the YYYYY stops working for the small
    //YYYYY. YOU HAVE BEEN WARNED!

     

    Depends on whether the WTF originates in the function that calls this code (in which case this code should do "if xMax > xMin { temp = xMax; xMax = xMin; xMin = temp; }") or in the function that this code calls (in which case see the above notes on YYYYY).

     @EncoreSpod said:

    //The idea behind the following code was to have dynamic text
    //field ... it did work, in the snese it wrote to the screen, just not
    //at the same time as the buttons ... oh dear

    So it did work in the didn't work kind of sense of working?

     

     

    No, no, no, no, no!  It "worked" in the "got it partly correct" sense.  Goddammit, if I had a nickel for every time a client said something "didn't work" and I had to hunt down specific symptoms.

     



  • @frits said:

    Yay embedded device code!?

    I've maintained projects with this type of defensive commenting, and let me tell you it's no laughing matter. With projects like this, any change requires full regression testing.

    Agreed. A project I worked on was somewhat like this. Big big codebase of OO code done by people new to OO and 0 comments. I would have killed to have comments this good. You'd get side effects akin to turning a light on in the basement and the front door falling off the house. After two+ years of working with the code I had a really good feeling for where to be careful about tickling. Of course there "was no time to refactor" because we had to implement "super important" customer features. I thought the #1 feature customers wanted from an embedded device that sits miles away from civilization is reliability, not the ability to graph data on a 3" lcd.



  • @emurphy said:

    No, no, no, no, no!  It "worked" in the "got it partly correct" sense.  Goddammit, if I had a nickel for every time a client said something "didn't work" and I had to hunt down specific symptoms.

     

    I've started to respond to vague "It doesn't work" bugs with nothing but "Yes, it does". That forces the person that filed the bug to plead his case. If they push it back to me, then I make up my own set of steps to reproduce that demonstrate that it does work (for my definition of "it"). Eventually they try to fight the fact that the bug has become about something other than their problem and the only way to get it on track is to describe the problem better.



  • @Someone You Know said:

    @EncoreSpod said:
    //DANGER WILL ROBERSTON< DANGER!!!!

    One of my co-workers liked to put this in his comments to get people's attention. Though, to give credit where credit is due, he did spell "Robinson" correctly.

    Currently I'm doing his job and my job, because he got fired a few weeks ago.

    They sacked him for putting "Danger Will Robinson danger!" in a comment? What's the sanction if you actually introduce a bug in the code?



  • @Severity One said:

    They sacked him for putting "Danger Will Robinson danger!" in a comment? What's the sanction if you actually introduce a bug in the code?

     

    No, they sacked him for even spelling the name wrong. What do you mean poor research skills?

     



  • @Severity One said:

    @Someone You Know said:

    @EncoreSpod said:
    //DANGER WILL ROBERSTON< DANGER!!!!

    One of my co-workers liked to put this in his comments to get people's attention. Though, to give credit where credit is due, he did spell "Robinson" correctly.

    Currently I'm doing his job and my job, because he got fired a few weeks ago.

    They sacked him for putting "Danger Will Robinson danger!" in a comment? What's the sanction if you actually introduce a bug in the code?

    Bugs can be fixed. Lost In Space references can't be unseen.



  • @Jaime said:

    I make up my own set of steps to reproduce that demonstrate that it does work (for my definition of "it").
     

     

    And "work".  Yeah, this is how a lot of them end up shaking out, followed by "but I (also did X / didn't do X / shouldn't need to do X / also expected Y / didn't expect Y)".




  • @EncoreSpod said:

    //XXXXX NN May 20YY -- do not optimise these lines of code, otherwise SPI_adr is not
    //properly calculated

    Really?  Not MMM DD, 19YY?  Because that1 looks a lot like a comment I saw and notified management about back when I was doing Y2K work.  Admittedly, I suspected that not much would be done, because the author was the team lead who was never my boss (the group had several teams; I was shuffled between all but one of them.)  His partial lip service to proper process was near legendary.  (Basically, as near as I could tell, he was for as much good process as one could reasonably have without having any chance of getting a benefit from it.  So, for example, by all means have someone check off a box saying they reviewed your code, but don't actually have them review it, and if they do actually review it, don't bother fixing anything they identified as a problem.  Not that he said those things in that way...)  If making that report had any bearing on my being dismissed from the contract about six weeks later, I'm glad I reported it.

    1 I mean the whole of the comments you were reporting, not just the pair of lines I quoted.



  • @emurphy said:

    @Jaime said:

    I make up my own set of steps to reproduce that demonstrate that it does work (for my definition of "it").
     

     

    And "work".  Yeah, this is how a lot of them end up shaking out, followed by "but I (also did X / didn't do X / shouldn't need to do X / also expected Y / didn't expect Y)".


    I usually play it straight and make them do all the work.

    Typical interchange:

    QA: Self-service feature doesn't work.

    Me: Yes it does.

    QA: I just tried again, it doesn't work.

    Me: It works.  Steps to reproduce:
    1. Log in.
    2. Open self-service page.
    3. Page loads successfully.

    QA: <here they actually fill in the proper steps that they should have put in the original bug request.>



  • @Jaime said:

    QA: <here they actually fill in the proper steps that they should have put in the original bug request.>

    Sounds like your QA need... Quality Improving, if that's the quality of their incident report.

    Don't they have some policy or procedure governing how they log and communicate this info back?

    You ought to print out a few of Blakey's bug reports and nail them to QA's forehead until they get the idea.



  • Print copies of [url=http://www.chiark.greenend.org.uk/~sgtatham/bugs.html]this document[/url] and leave them in the QA break room. If that doesn't work, then start nailing them to foreheads.



  • @Cassidy said:

    @Jaime said:

    QA: <here they actually fill in the proper steps that they should have put in the original bug request.>

    Sounds like your QA need... Quality Improving, if that's the quality of their incident report.

    Don't they have some policy or procedure governing how they log and communicate this info back?

    You ought to print out a few of Blakey's bug reports and nail them to QA's forehead until they get the idea.

    I wish it was that easy. I had a project last year where I had an example of every QA horror story that I can think of. My favorite was when a bug report was put in to change a behavior back to the original behavior that had been changed in response to an earlier bug report from the same person. The first one was because he didn't like the behavior and the second was because it didn't meet the requirements exactly. As a bonus, he had originally written that requirement.



  • @Jaime said:

    My favorite was when a bug report was put in to change a behavior back to the original behavior that had been changed in response to an earlier bug report from the same person. The first one was because he didn't like the behavior and the second was because it didn't meet the requirements exactly. As a bonus, he had originally written that requirement.

    At the risk of sounding slopey-shouldered, if they can't articulate the work packages then you've got no work to do, really.

    Are you still getting paid for their lack of clarity?


Log in to reply