• bvs23bkv33 (unregistered)

    who are we? we are programmers! what do we need? fix all the bugs!

  • Kev (unregistered)

    So why not just accidentally fix bug 2 as part of the work on bug 1?

  • Hasseman (unregistered)

    Bit surprised on this. I would just have fixed 2 and then 1 without asking. Nobody would probably even notice.

    Have never in 35 years of software development heard management not listening to people knowing.

  • Little Bobby Tables (unregistered)

    Comes to us all.

    I was once in a similar situation of having a prioritised list of things to do. Some were big major project-sized enhancements that needed lots of planning and concentration, not to mention input from other parties. Others were metaphorical one-liners (bugs or enhancements) that had an impact on usability that was more significant long-term than appeared on the surface. Naturally, if an enhancement in the first category was higher in the (somewhat arbitrary) priority list than those further down, I would get an ear-bashing at the weekly status meetings for having accessed a score of those issues in the second category without having managed to make any apparent visible progress on those of the first category. Just one of those things. You learn to keep quiet about what you've really been doing unless you have a built in BS generator.

  • Peter (unregistered)

    Re: test stations

    I recently got an email from someone whose job it was to repair a military aircraft. To do this, they used a diagnostic cart. As you might expect, the equipment was old. How old? Well, apparently, it used a Data General minicomputer. I used to work for DG. My first job out of school. I was on the team that designed their low cost terminal, the D200. Which, being cheap (and our first effort), was not particularly reliable -- certainly not what I would choose to put out on a piece of flight line diagnostic equipment. And this gentleman had a non-functional D200, and wanted some help to fix it. Because, without it, his diagnostic equipment didn't work, and airplanes didn't fly. This situation attracts the wrong kind of attention. He found my name and email on an old Usenet (!) posting...wanted to know if I could help him get his equipment running again, and no, they didn't have a budget for any repairs.

    Now, DG wanted to lock in their customers, so their terminals used different control sequences than the industry-standard products of their arch-rival, DEC. Which meant that 30 years later, you couldn't just replace the D200 with any random terminal emulator. Or any random terminal. However, there are a few companies that offer DG terminal emulators, and I steered him towards one of them, telling him that the flaws I knew of in the D200 made attempting to repair it a Bad Idea. I never heard back, so perhaps he solved his problem. Or changed jobs.

  • Wizard (unregistered)

    DAYS!!!??? Does no one fix bugs by reading code anymore or heaven forbid dry running? As its an off by one it sounds even more like the developers were one of those who frig the code until it works as opposed to understanding it.....TTRWTF

  • snoofle (unregistered) in reply to Kev

    Because we were 6 months out of school and still not-quite-sure of ourselves...

  • gumpy_gus (unregistered) in reply to Peter

    Hey, I had a D200! Bought it in 1985 from a bank fire sale. Literally, they had a fire. The D200 was a bit browned, but IIRC it worked just fine. Major peeve though, the "Enter" key generated a line-feed instead of the typical CR. It ran just fine for a few years until one day it just died.

  • Brian (unregistered) in reply to snoofle

    So one of the many WTFs here was sending two green devs as a Tiger Team. Although I guess that shouldn't be too surprising; back when I was still a young'un working for a government contractor (also doing military avionics, coincidentally), I was shipped off solo to a vendor site to debug a critical issue in their software that they just couldn't seem to fix. And was hailed as a hero when I managed to find and resolve the bug :)

  • snoofle (unregistered) in reply to Brian

    re: sending green devs to the customer: absolutely. We weren't hailed as heros, but we did get free pizza when we got back home. It was the first free pizza I ever got at work, so it seemed like a big deal at the time. Ah, youth.

  • Kashim (unregistered) in reply to snoofle

    So I'm a little confused; You were ordered not to divulge that you'd fixed any of the other bugs, but wouldn't they notice the distinct lack of 6+ hours of printing? I feel like that's something I'd notice.

  • Raj (unregistered) in reply to snoofle

    If to you the free pizza felt like a big deal, then it was a big deal. Life experiences are relative, not absolute. If we judge yesterday with today's information we become even more of a get off my lawn person.

  • Latengorica (unregistered)

    What is puzzling is that surely you could have temporarily added "stop after test N" functionality – not as a fix for bug 2 but as a tool for resolving bug 1 – and then removed it again once you had resolved bug 1. Thus you have not fixed bug 2 before bug 1.

    Then and only then, you would look at the bug list and see – surprise! – that you now knew how to fix bug 2 very fast. A mere coincidence, since you had, obediently, not looked beyond bug 1 before.

  • Grey no beard (unregistered)

    The part that will blow your mind is doing EXTRA work for the government for free is actually DEFRAUDING the government.

    Yup

    It goes like this... in addition to all your real work over the year, all the overhead gets totaled up and divided by the hours of actual work is used to compute your overhead rate. The government gets charged actual cost + overhead + profit (as allowable per contract). So if you bill 24 hours and have 16 of overhead but actually work 30...

    NEXT YEAR your overhead rate is higher than it should be and so you are defrauding the government.

  • Miles Archer (unregistered)

    If there ever was a case for doing the right thing and keeping your mouth shut about it, this was it.

  • PedanticAntelope (unregistered)

    As my uncle who spent decades in the Navy used to say, it's often smarter to ask for forgiveness than permission.

  • (nodebb) in reply to Hasseman

    What planet do you live on??

  • (nodebb) in reply to Grey no beard

    Unless you have a fixed cost contract - back when Bush Sr. became the POTUS, a lot of gov. contracts became fixed cost contracts and a lot of DoD contractors started losing money, or at least their profits went down significantly, or they learned to inflate their bids to cover their costs.

  • Peter (unregistered) in reply to gumpy_gus

    If you bought it, you paid too much :-)

    Fun fact: you can download Motorola S1/S9 files to it and run them on the internal 6802 processor.

    We had unpopulated 2102 RAM sockets to increase the RAM beyond the 2k for screen memory. One of the guys wrote a Space Invaders game, and another wrote a PacMan game. Both, sadly, lost. They required the extra RAM to run. We know, because we made a significant effort to get them to run in display RAM...just not enough space for the screen and the code. Had they fit, we would have put them in the firmware ROMs.

  • Peter (unregistered)

    Link to D200 user manual: https://www.scribd.com/doc/146282825/data-general-dasher-display-terminals-models-d100-d200-user-s-reference-series

    Re: the ENTER key sending NEWLINE instead of CR...that's DG for you. Intentionally incompatible with DEC, because we're better than them!

  • jay (unregistered) in reply to Latengorica

    Why not just fix bug #2 in the course of fixing bug #1, then put the old code back? i.e. break it again. Then when you get to item #2, fix it again.

  • B. Thompson (unregistered)

    Why not just write some temporary code to suppress all test reports except number 12K? This solves the problem of testing bug-fix #1, but does not solve bug #2 (and therefore averts the wrath of the pointy-haired gods).

  • Johnny L (unregistered)

    When I was young and innocent, I just want to fix everything as quick as I can.

    Now when I am old and learn/getting troubles on all the political stuff, I realize no one will appreciate if you try to make things better but they will beat you till dead if you do not follow the procedure.

    Since I get the same paid either way, I now just stick to the procedures, We call this growth up right? LOL

  • (nodebb)

    Perfectly agree with all those saying the bug 2 could have been easily fixed before bug 1 (and then possibly reverting the fix for bug 2, and then fixing it again). Looks like common sense. Why did it not occur to snoofle? He answers it himself in the post:

    At the beginning of my career, ...
  • Dinis (unregistered)

    You are lier dinis and your crazy girl

  • TerryK (unregistered) in reply to Peter

    The Dasher CRTs were an immense improvement over the previous terminal DG supplied - the Infoton Vistar (1973-ish), which DG re-branded as the 4010i (4000-series stuff was badge-engineered, like the 4234 disk drive which was a Diablo 44). Perhaps they chose 4010i to confuse people into thinking it was compatible with the Tek 4010 graphics terminal. Anyway, the case on the Infoton was thin cheap cream-colored plastic with a faux-leatherette embossing. Since the terminal needed a good thumping every now and again to get it working, the cases sometimes had cracks on the top, but almost all of them had cracks where the cover was screwed to the base.

    And "not compatible with anything else" was pretty much standard back then. Hazeltine had one set of codes, Lear Siegler another, MAI/Basic Four yet another (even though they were re-badged LS units), and so on. DEC didn't come out with the VT100 until 1978, the year before the Dasher D100/D200 - before then it was VT52. By the early 80's there were a number of terminals that could emulate the Dasher, for example the Visual 330.

    By the way, if you want to see some (perhaps the only ever) product placement of Dasher terminals in a movie, look at "Meteor" from 1979.

  • (nodebb)

    Something something simultaneous multi execution paths something...

  • James (unregistered)

    Hmm, couldn't redirect the printer output to a text file and grep it huh? Or even better, just fix the 2nd bug to make fixing the 1st bug faster. Or look at the flipping code and figure out the logical flaw. I mean you are working on a portable external disk, locked in a room alone so nobody is watching you nor any source repo commits. So who is to know what in the heck you are doing in the first place being in the field as well? Oh well, funny story, green newbie developers and all. Government red tape is terrible.

  • (nodebb) in reply to Johnny L

    Seeing comments like that make me glad that everywhere I've worked at has had management sane enough to understand the relevance of end-of-the-day and friday-afternoon bugs and accepted that occasionally fixing lower priority trivial/minor bugs could be done for "free" in time intervals that would otherwise be largely or entirely wasted by end of the day/week context breaks.

  • DV (unregistered) in reply to PedanticAntelope

    I remember a Navy wave that was put in charge of the first computer, Grace Hopper. She was the one attributed to that saying, back in the 1940s; "It is better to ask for forgiveness than permission." n reference to 'bugs', she found a moth in a relay contact, and that's how we got the word 'bug' for computer problems.

  • radarbob (unregistered) in reply to DV

    You remember?!

  • radarbob (unregistered)

    Giving too much detail to program management seems to be a common thing in govt, especially military, software contracts. We weren't even entering bugs in our in-house bug tracking system because it was visible to our customer. That was just one symptom in an somewhat adverserial process that ultimately did not fix problems but only very specific, explicit, isolated, bugs. At times we wrote around otherwise functionally related bugs in the same class or methods in order to not fix them.

  • YoJambo (unregistered) in reply to Hasseman

    @Hasseman "Have never in 35 years of software development heard management not listening to people knowing."

    Have you been working in magic land? You've never seen a manager not listen to someone? In 35 years?

  • YoJambo (unregistered) in reply to Tsaukpaetra

    @Tsaukpaetra Something something you've got no idea of the context and no idea what you're talking about, and your writing style is truly atrocious.

Leave a comment on “Politics Rules! Common Sense Drools!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article