• martinl (unregistered)

    Ah, it all makes more snese now. ;-)

  • Anita Tinkle (unregistered) in reply to martinl

    Sometimes the root causes of defects are so mindnumbingly dumb.

  • David (unregistered)

    Third! errrr i guess...

  • (cs) in reply to David

    But...the code is 10x longer now, which by my calculations makes it 6.33 (repeating of course) times BETTERER!

  • Ragnaros (unregistered) in reply to Manni

    Is this where Java was born?

  • (cs)

    This story almost makes me wish that code quality was measured in terms of how few lines are used to accomplish the given task.

    As long as the code is still readable, of course.

    Using things like, oh I don't know... SUBROUTINES...  really helps cut down on the number of lines of code used.

  • (cs)

    <o:p></o:p>Why change the code just because the manager will *presumably* be upset because there aren’t a lot of lines? To me, that is a bigger WTF than the manager who uses LOC as a metric. Maybe he should sit down with the manager and talk about some other metrics that could be used. If the manager is still a knuckle head, then start shopping for a new job.<o:p></o:p>

    <o:p> </o:p>

  • Colin (unregistered)

    Oh, dear God. The very idea that KLOC would be anything near a measure of productivity for hardware modelling strikes fear into my heart. That being the heart of a reformed functional verification engineer.

  • diaphanein (unregistered) in reply to Manni

    Ah, verilog.  How I miss thee. Many a night I spent plugging away back in college. I think my crowning acheivement was the multiplier I wrote in 2 hours over a bottle of bourbon.

  • Bourbon's drinker (unregistered) in reply to diaphanein

    Ahh, The multiplying Bourbon

    I also remember seing multiple things after a few glasses.

     

  • Anita Tinkle (unregistered) in reply to Anita Tinkle
    Anonymous:
    Sometimes the root causes of defects are so mindnumbingly dumb.


    If I were going to be a PHB use a metric to track developer performance, bonuses would be factored off of a merit ratio like this:

    [(defectX & severityY, n...)/(#of features implemented + #tasks completed)] == Defect Level

    The closer you are to zero, the better you look.  The manager can then also see the total of items you've been involved with to see if you're trying to flex the system by avoiding difficult work or simply not working on a lot of items.

    KLOC is such an ancient metric that was only useful in the days of COBOL and batch programming where there was no end in sight to the amount of work to be done and purposely padding your code wasn't that important.  I don't know about other older systems, but on IBM System/390 (where the KLOC metric was very popular), any SYSOP could see if you were working or not just by looking at what JCL you've been submitting and members (that's files to you PC people) that have been pulled and added.

    You can run into an inverse problem with programmers where you have an low level of trust and constantly overscruitinize them to the point they will hesitate to code anything (do it often enough and they'll quit).  They'll start to work on design or other miscellaneous tasks and avoid working on your software simply because there is too much negative pressure applied to them when they DO write anything.   Who really wants to live in Visio/Umbrello for an entire day and then sit in a 6 hour long design session to talk about what is the most architectually elegant way to update 3 tables in a database?


  • (cs) in reply to Ragnaros
    Anonymous:

    Is this where Java was born?

    No, Java was born at Sun Microsystems.  Moon microsystems was responsible for the less famous "Coffee" language.

  • Willie (unregistered)

    LOC metrics are so old school, REAL managers use CodeFeet.

  • uncool (unregistered) in reply to Willie

    I work with a guy that copies 10% of my code unravels everything (or atleast the stuff he "understands"), then uses the almost equal line count as proof that his stuff is 'better' than mine...

     

    still trying to figure that one out

  • (cs) in reply to Anita Tinkle
    Anonymous:
    Anonymous:
    Sometimes the root causes of defects are so mindnumbingly dumb.


    If I were going to be a PHB use a metric to track developer performance, bonuses would be factored off of a merit ratio like this:

    [(defectX & severityY, n...)/(#of features implemented + #tasks completed)] == Defect Level

    The closer you are to zero, the better you look.  The manager can then also see the total of items you've been involved with to see if you're trying to flex the system by avoiding difficult work or simply not working on a lot of items.


    When would you measure?  If a bug is not found until six months later, what happens?

    KLOC is such an ancient metric that was only useful in the days of COBOL and batch programming where there was no end in sight to the amount of work to be done and purposely padding your code wasn't that important.  I don't know about other older systems, but on IBM System/390 (where the KLOC metric was very popular), any SYSOP could see if you were working or not just by looking at what JCL you've been submitting and members (that's files to you PC people) that have been pulled and added.


    I say it was not useful even then.  I took a couple of courses in COBOL as part of my diploma program.  I remember one assignment where the shortest turned in was 350-400 lines.  Mine was around 2000.  Mine was documented in the code rather thoroughly, and I do use blank lines as part of my coding standard.  My code had approximately 200 blank lines, and each one had a reason.  I got the top marks by far in those classes, and my instructor (who had heavy industry experience) once handed an assignment back with a compliment on the professionality of my code (which counted far more to me than the grade).

    You can certainly disagree with my coding style use of whitespace, but the wide variation means that KLOC is not very useful as a measurement.

    You can run into an inverse problem with programmers where you have an low level of trust and constantly overscruitinize them to the point they will hesitate to code anything (do it often enough and they'll quit).  They'll start to work on design or other miscellaneous tasks and avoid working on your software simply because there is too much negative pressure applied to them when they DO write anything.   Who really wants to live in Visio/Umbrello for an entire day and then sit in a 6 hour long design session to talk about what is the most architectually elegant way to update 3 tables in a database?


    I can handle some questioning or suggestions of alternative ways.  I can handle being told to use x coding style (at the beginning of the project).  Nitpick, and my dander rises.

    Sincerely,

    Gene Wirchenko

  • John Hensley (unregistered)

    Oh god it burns...

    Somebody needs to stamp this manager "return to IBM." And the lead programmer too, since he was willing to do the manager's dirty work.

  • (cs) in reply to Gene Wirchenko

    Gene Wirchenko:
    I took a couple of courses in COBOL as part of my diploma program.  I remember one assignment where the shortest turned in was 350-400 lines.  Mine was around 2000.  Mine was documented in the code rather thoroughly, and I do use blank lines as part of my coding standard.  My code had approximately 200 blank lines, and each one had a reason.  I got the top marks by far in those classes, and my instructor (who had heavy industry experience) once handed an assignment back with a compliment on the professionality of my code (which counted far more to me than the grade).

    Hear, hear. I'm a great believer in the aesthetics of computer programming. Simply stated, if it looks good, it probably is good. My reasoning is that if someone takes the time to do all the indentations in a consistent manner (whatever style, it doesn't matter), if there's plenty (but not too much) of white space, and if it subscribes to "make it as simple as possible, but no simpler", the quality is probably high.

  • (cs) in reply to loneprogrammer
    loneprogrammer:
    This story almost makes me wish that code quality was measured in terms of how few lines are used to accomplish the given task.

    As long as the code is still readable, of course.

    Using things like, oh I don't know... SUBROUTINES...  really helps cut down on the number of lines of code used.

    Someone should write a program - let's call it LOC++ for now - that automatically expands subroutines at every possible oppertunity to increase the LOC count in their code. (Possibly not applicable here, though; I don't know very much about this area...)

  • How many hardware engineers does it take to write a... (unregistered) in reply to makomk

    Can someone explain how this change worked.

    I assume the : 

      32'h0000202F;
    is to allocate 32 bits, set to the value 202F in hexadecimal.  This works out to be binary :

       00000000000000000010000000101111

    Now, I also assume that VCC would represent 1, and GND would be a 0, so how does this create the same value.  It looks like the new code would produce binary :

       00110000000010110110100000110110

    Or, if I got the VCC and GND wrong

       11001111111101001001011111001001

    Neither of which match 202F hexadecimal.  So what gives, I always want to learn SOMETHING from the daily WTF, so clue me in!

  • (cs) in reply to makomk

    I think quality should be measured by whether any competent programmers who inherit your code can actually read, comprehend, and fix or modify it in a reasonable amount of time. Paychecks would be retroactive.

    I'm sick of arriving at a job and told to fix the code, and it turns out it's written by an Obfuscated C winner with an obvious disdain for any form of comments or self documentation.

  • (cs) in reply to How many hardware engineers does it take to write a...

    I always want to learn SOMETHING from the daily WTF

    This is where I become nervous.

  • Anita Tinkle (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:

    When would you measure?  If a bug is not found until six months later, what happens?


    That's really only something you can assess at once-a-year intervals.  I wouldn't rank defects as severe if it took 6 months for them to bubble up to the surface.  Usually the really crufty ones in actively-used systems are found not far after deployment.

    Peer code reviews and having your boss browsing your code and asking questions is another way to encourage more quality.  Developers that are proud of their work will work harder at "cleaning" and unit testing when they see it has tangibles attached to them (a mixutre of positive rewards and negatives... like peer shame [dude your code sucks]).

    Project managers are evaluated on metrics as well and their success rate is important to them.  PMs with high # wins tout their accomplishments in their resumes like a hit-parade.  This is a good thing.   I've seen PMs jump ship on projects manned by nincompoops because they wanted to avoid their success ratio from being tarnished.  If you're the project sponsor, that should raise some serious red flags when PMs are giving up on you and looking for greener pastures.

    The only group that seems invulnerable to scruitiny are system architects.  Much like corporate Sophocles, there is no easy way to tie back their "work product" or rate their job performance.  They're paid to give out advice (in the form of design work and research) and to enforce standards.   Like KLOC, you really can't say an architect is a good one or not such by looking at how many reams of photocopy paper they suck up printing ERD and UML docs, Gb of websites browsed, etc..
  • Anita Tinkle (unregistered) in reply to makomk
    makomk:
    loneprogrammer:
    This story almost makes me wish that code quality was measured in terms of how few lines are used to accomplish the given task.

    As long as the code is still readable, of course.

    Using things like, oh I don't know... SUBROUTINES...  really helps cut down on the number of lines of code used.

    Someone should write a program - let's call it LOC++ for now - that automatically expands subroutines at every possible oppertunity to increase the LOC count in their code. (Possibly not applicable here, though; I don't know very much about this area...)



    What would be even better would be something that unrolls all your loops, "re-interlaces" function calls back into the source, introduces unnecessary constants, REPLACES some constants with stupid arithmetic equivalents (like calc-ing PI) etc... when you check your source code into source control, but then coverts it back to REAL code when you check it back out and compile it.    Then you can set a PHB-filter that keeps it unrolled when your boss looks at it.

  • (cs) in reply to stonguse
    stonguse:

    <o:p></o:p>Why change the code just because the manager will *presumably* be upset because there aren’t a lot of lines? To me, that is a bigger WTF than the manager who uses LOC as a metric. Maybe he should sit down with the manager and talk about some other metrics that could be used. If the manager is still a knuckle head, then start shopping for a new job.<o:p></o:p>

    <o:p> </o:p>



    What color is the sky where you are?  Oh, I see it now.  It's over the gumdrop falls and through the peppermint forest, where managers listen to their employees and hardware programming jobs grow on trees.  You're right.  What was this Adam guy thinking?
  • (cs) in reply to LaurieF
    LaurieF:
    Gene Wirchenko:
    I took a couple of courses in COBOL as part of my diploma program.  I remember one assignment where the shortest turned in was 350-400 lines.  Mine was around 2000.  Mine was documented in the code rather thoroughly, and I do use blank lines as part of my coding standard.  My code had approximately 200 blank lines, and each one had a reason.  I got the top marks by far in those classes, and my instructor (who had heavy industry experience) once handed an assignment back with a compliment on the professionality of my code (which counted far more to me than the grade).

    Hear, hear. I'm a great believer in the aesthetics of computer programming. Simply stated, if it looks good, it probably is good. My reasoning is that if someone takes the time to do all the indentations in a consistent manner (whatever style, it doesn't matter), if there's plenty (but not too much) of white space, and if it subscribes to "make it as simple as possible, but no simpler", the quality is probably high.

    I am fanatical about my coding standards.  I do not always make the quality bar, but I try.  I do not always manage it.  The in-house client billing system that I wrote/maintain has had to have a number of kludges to extend it.  I have taken to documenting this.  Some parts of the system have gone years without changes though.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to makomk
    makomk:
    Someone should write a program - let's call it LOC++ for now - that automatically expands subroutines at every possible oppertunity to increase the LOC count in their code. (Possibly not applicable here, though; I don't know very much about this area...)


    You are thinking somewhat small.  Use larger increments.  Someone should write LOC+=n.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    I took a couple of courses in COBOL as part of my diploma program.  I remember one assignment where the shortest turned in was 350-400 lines.  Mine was around 2000.  Mine was documented in the code rather thoroughly, and I do use blank lines as part of my coding standard.  My code had approximately 200 blank lines, and each one had a reason.  I got the top marks by far in those classes, and my instructor (who had heavy industry experience) once handed an assignment back with a compliment on the professionality of my code (which counted far more to me than the grade).


    Oh my goodness Gene! Did the instructor give you a cookie as well??

    sincerely,
    Richard Nixon
  • (cs) in reply to Joseph K.
    Joseph K.:
    I think quality should be measured by whether any competent programmers who inherit your code can actually read, comprehend, and fix or modify it in a reasonable amount of time. Paychecks would be retroactive.

    I'm sick of arriving at a job and told to fix the code, and it turns out it's written by an Obfuscated C winner with an obvious disdain for any form of comments or self documentation.



    Unfortunate side effect: Write perfect code, and you might never get paid.

    I know about the garbage code.  I sometimes wish the original coder were around so I could say (when applicable), "It is easier to throw out this code and rewrite than it is to figure out what your code is doing and [extend it|correct the bugs].  Now, get out of my office!"

    Sincerely,

    Gene Wirchenko

  • Logic dictates (unregistered) in reply to nobody
    nobody:
    Anonymous:
    Can someone explain how this change worked.

    I assume the : 
      32'h0000202F;
    is to allocate 32 bits, set to the value 202F in hexadecimal.  This works out to be binary :

       00000000000000000010000000101111

    Now, I also assume that VCC would represent 1, and GND would be a 0, so how does this create the same value.  It looks like the new code would produce binary :

       00110000000010110110100000110110

    Or, if I got the VCC and GND wrong

       11001111111101001001011111001001

    Neither of which match 202F hexadecimal.  So what gives, I always want to learn SOMETHING from the daily WTF, so clue me in!



    > I always want to learn SOMETHING from the daily WTF

    This is where I become nervous.



    And yet you haven't answered the question, so perhaps you too could learn something from this website.

    Now you have stated that the fact that someone could learn something from this site makes you nervous.  If you cannot answer the question, this would imply that you could learn something from this site, and therefore we can conclude that you make yourself nervous.

    So here is your chance, answer the question, or admit that YOU MAKE YOURSELF NERVOUS, because there is something you can learn from this site.

  • John Hensley (unregistered) in reply to Sean
    Sean:
    stonguse:
    <o:p></o:p>Why change the code just because the manager will *presumably* be upset because there aren’t a lot of lines? To me, that is a bigger WTF than the manager who uses LOC as a metric. Maybe he should sit down with the manager and talk about some other metrics that could be used. If the manager is still a knuckle head, then start shopping for a new job.<o:p></o:p>

    What color is the sky where you are?  Oh, I see it now.  It's over the gumdrop falls and through the peppermint forest, where managers listen to their employees and hardware programming jobs grow on trees.

    Exactly. It's called the Bay Area.
  • Puzzled cowherd (unregistered) in reply to How many hardware engineers does it take to write a...

    I presume this is part of the code origins obfuscation. We shouldn't be able to go and find the original source, so the values are changed. ;)

  • Puzzled cowherd (unregistered) in reply to How many hardware engineers does it take to write a...
    Anonymous:
    Can someone explain how this change worked.

    I assume the : 
      32'h0000202F;
    is to allocate 32 bits, set to the value 202F in hexadecimal.  This works out to be binary :

       00000000000000000010000000101111

    Now, I also assume that VCC would represent 1, and GND would be a 0, so how does this create the same value.  It looks like the new code would produce binary :

       00110000000010110110100000110110

    Or, if I got the VCC and GND wrong

       11001111111101001001011111001001

    Neither of which match 202F hexadecimal.  So what gives, I always want to learn SOMETHING from the daily WTF, so clue me in!

    Of course the previous message should have this quote inside...

  • Puzzled cowherd (unregistered) in reply to Puzzled cowherd

    Whatever...

  • (cs) in reply to Anita Tinkle
    Anonymous:
    Gene Wirchenko:

    When would you measure?  If a bug is not found until six months later, what happens?


    That's really only something you can assess at once-a-year intervals.  I wouldn't rank defects as severe if it took 6 months for them to bubble up to the surface.  Usually the really crufty ones in actively-used systems are found not far after deployment.

    Peer code reviews and having your boss browsing your code and asking questions is another way to encourage more quality.  Developers that are proud of their work will work harder at "cleaning" and unit testing when they see it has tangibles attached to them (a mixutre of positive rewards and negatives... like peer shame [dude your code sucks]).

    Project managers are evaluated on metrics as well and their success rate is important to them.  PMs with high # wins tout their accomplishments in their resumes like a hit-parade.  This is a good thing.   I've seen PMs jump ship on projects manned by nincompoops because they wanted to avoid their success ratio from being tarnished.  If you're the project sponsor, that should raise some serious red flags when PMs are giving up on you and looking for greener pastures.

    The only group that seems invulnerable to scruitiny are system architects.  Much like corporate Sophocles, there is no easy way to tie back their "work product" or rate their job performance.  They're paid to give out advice (in the form of design work and research) and to enforce standards.   Like KLOC, you really can't say an architect is a good one or not such by looking at how many reams of photocopy paper they suck up printing ERD and UML docs, Gb of websites browsed, etc..
    When a project involves millions of lines of code, and managers are working on projects to which they didn't contribute code (and may even be in a different language than the last time they wrote code), guess what happens:  they turn to SWAG ("sweet wild-a.. guess") estimates and KLOEC ("estimated") to set the project schedule.  (And then punish the poor folks who learn that the project is more complex than their managers first imagined.)

    This is real life, not a fantasy camp.

    And if a bug takes out the phone system for half of North America, it's a pretty severe bug, regardless of how long it took to discover.  Just ask the good folks at DSC.  Perversely, many of the most severe bugs exist in pretty decent code, and often in pretty decent architectures.
  • mestar (unregistered) in reply to martinl

    M flip flop sh  32 ff1 out, din, te, ti, out, cap, tck

    Hey Dol! merry dol! ring a dong dillo!

    Ring a dong! hop along! fal lal the willow!

    Tom bom, jolly Tom, Tom Bombadillo!

     

     

     

     

  • Anita Tinkle (unregistered) in reply to Coughptcha
    Coughptcha:


    This is real life, not a fantasy camp.

    And if a bug takes out the phone system for half of North America, it's a pretty severe bug, regardless of how long it took to discover.


    These kinds of software bugs that may go undetected for a long-length of time and then creep up to bite you (in this case, cause the death of some people).

    I wouldn't necessarily fault the software developer in cases such as this, because those kinds of circumstances may warrant a larger investigation.  Defect tracking and merit rewards are meant to thwart the everyday software fallacy.  Metrics won't detect and deter management FU** ups.

    But as far as today's WTF goes, if the device this embedded code runs on happened to be controlling an X-ray machine... I would be scared to stand in front of it to get my picture taken.

    This is also why I would change hospitals if I ever had a heart-bleep machine attached to me that ran any form of Microsoft Windows.
  • Tony Morris (unregistered) in reply to John Hensley
    Anonymous:
    Oh god it burns...

    Somebody needs to stamp this manager "return to IBM." And the lead programmer too, since he was willing to do the manager's dirty work.



    I resigned from IBM 4 weeks ago for the exact reason that I assume you are eluding to.
    Minimising retardedness (for some definition of) in my work was the primary objective and I believe I have succeeded well beyond my initial expectations.
  • (cs) in reply to Anita Tinkle

    Anonymous:
    Coughptcha:


    This is real life, not a fantasy camp.

    And if a bug takes out the phone system for half of North America, it's a pretty severe bug, regardless of how long it took to discover.


    These kinds of software bugs that may go undetected for a long-length of time and then creep up to bite you (in this case, cause the death of some people).

    I wouldn't necessarily fault the software developer in cases such as this, because those kinds of circumstances may warrant a larger investigation.  Defect tracking and merit rewards are meant to thwart the everyday software fallacy.  Metrics won't detect and deter management FU** ups.

    But as far as today's WTF goes, if the device this embedded code runs on happened to be controlling an X-ray machine... I would be scared to stand in front of it to get my picture taken.

    This is also why I would change hospitals if I ever had a heart-bleep machine attached to me that ran any form of Microsoft Windows.

    <FONT face=Georgia>Just imagine the possibilities. It gives the "Fatal Error" Windows messages a whole new meaning... [:|]</FONT>

  • Anonymous PIC (unregistered) in reply to BiggBru

    Fourtunatly the FDA does know something about the need for fault tolerance.  Heart pumps have a controller (such as a PIC) dedicated to critical functions only.  The FDA has to approve the code before production.

  • (cs) in reply to Joseph K.

    I'm sick of arriving at a job and told to fix the code, and it turns out it's written by an Obfuscated C winner with an obvious disdain for any form of comments or self documentation.

    Oh, are you actually talking about my new job???

  • (cs) in reply to Anonymous PIC
    Anonymous:
    Fourtunatly the FDA does know something about the need for fault tolerance.  Heart pumps have a controller (such as a PIC) dedicated to critical functions only.  The FDA has to approve the code before production.


    We all know they never screw it up
  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
      I took a couple of courses in COBOL as part of my diploma program. 



    I wrote COBOL for a living for over 2 years.

    I also wrote s/360 BAL.  I prepunched my cards for the comment field and every steenking one had something in those cols unless I needed the deep breath that blanks afforded.  The running commentary was in 41-70 I think, cuz 40 and 71 were '*' and 72 was a continuation indicator if I remember correctly). 

    I still have a box of those suckers somewhere.
  • (cs)

    Just to show why VHDL is a better choice for LOC here is a rought translation of the good version, without much exageration.

    Now why someone would apply a lousy metric of software developement to hardware developement :-(.

    I hope the forum doesn't mangle this too much...


    library ieee;
    use ieee.std_logic_1164.all;

    entity idreg is
        port (
            sout    : out std_logic;
            sel     : in  std_logic;
            capture : in  std_logic;
            sen     : in  std_logic;
            ti      : in  std_logic;
            tck     : in  std_logic;
            logic_0 : in  std_logic;
            logic_1 : in  std_logic
            );
    end entity idreg;

    architecture archidreg of idreg is
        signal din : std_logic_vector(31 downto 0);
        signal cap : std_logic;
        signal te  : std_logic;
        signal out : std_logic_vector(31 downto 0);
    begin
        din <= x"0000202F";
        cap <= sel and capture;
        te  <= sel and sen;
        sout <= out(0);

        Mflipflop_sh_32:ff1 
            port map (
                Q => out, 
                D => din,
                Something => te,
                SomethingElse => ti & out(31 downto 1),
                MoreStuff => not cap,
                CLK => tck
            );

    end archidreg;

  • Anonymaly (unregistered) in reply to Anita Tinkle

    Anita Tinkle:

    This is also why I would change hospitals if I ever had a heart-bleep machine attached to me that ran any form of Microsoft Windows.

    You don't have any faith in Dr. Kevorkian, do you?  [:D]

    BTW, I spent a lot of time frequenting the hospital over a period of a year recently.  Their radiation machines were definitely not running windows.  However, there were still machines there (most of them used for analyzing scans and the like, so somewhat more innocuous) that were running Windows 95.

    Kind of like the monitors in the airport terminals down here running Windows --they are very useful for displaying arrival and departure information while they haven't blue-screened, but I would wonder if the OS was actually employed (at least a much more stable version) in any automation used for traffic control.

  • Anonymaly (unregistered) in reply to Tony Morris

    Tony Morris:
    Anonymous:
    Oh god it burns...

    Somebody needs to stamp this manager "return to IBM." And the lead programmer too, since he was willing to do the manager's dirty work.



    I resigned from IBM 4 weeks ago for the exact reason that I assume you are eluding to.
    Minimising retardedness (for some definition of) in my work was the primary objective and I believe I have succeeded well beyond my initial expectations.

    Please don't think I'm placing you into this generalization, but I'm seeing a very disturbing pattern.  For my entire professional career, I've worked at only two small companies over the past eleven years and have seen many developers (who became managers) and managers come and go. [^o)]<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    What really amazed me is that quite a few people had the acumen to pass the interview, but for some reason or another, they managed to "take a proverbial dump" on the company before parting ways.  Now, what makes this interesting is that a good number of these people came from some very highly recognized organizations in the technology sector.  Companies that most undergraduates clamor to on career day and have neophytes at the company wondering why in the heck they would want to leave a company that would leave a "scratch-n-sniff" gold star on their resume. [:|]<o:p></o:p>

    Well, I got to see why firsthand.  Some of them were probably the result of first-round layoffs, dismissed with the excuse of budget cuts, stock valuation, etc., when in fact, they were disguising the truth.  Some of these folks had no other skill (which I admire worked very well for them) than to be "everyone's" friend and either: a) manage to pawn all their work off onto someone else; b) feign enough incompetence to be given any work of significant challenge; or c) (in the case of management) spent more time having meetings and making processes so inefficient that more people were required to perform a task that may require nothing more than cutting and pasting data into an Excel spreadsheet. [:@]<o:p></o:p>

    I managed to find people who spent more time working at ways to not do work; these people were skilled in the art of negotiations; holding meetings to discuss who was responsible for what work, trying to determine the actual workflow, then holding a meeting to clarify what was supposed to be done.  Developers were called into these meetings like pawns, to support or debunk claims made by either side determining the workflow to prove or disprove that the "fully functional widget" could actually be done in three days, when the project manager had been mulling over the concept specification for almost three months and the contract deadline loomed only two weeks away.  At the same time, I saw one development lead creating a new system that became a Rube Goldberg machine, ensuring that any developer which knew at least one crucial piece of it was not only guaranteed a secure job, but could also extort a company for more money at its weakest moment by threatening to leave. [:@]<o:p></o:p>

    I'm worried that a lot of these people who infiltrated the smaller, pristine companies are starting to pass along bad habits they've learned from these companies (perhaps not recognizing they are doing this) while touting their past credentials as authoritative support for their decisions in what they do; be it good or bad. [:'(]<o:p></o:p>

    Nowadays I'm keeping a wary eye out for those folks coming from some of the 'big' companies.  I realize that some folk like to leave them for valid reasons (i.e. really need a new challenge or opportunity to advance, were the 'new guy' who got the layoff notice the week after they started, or just like to be 'seen'), but for some of the folk I've had the opportunity to meet, they don't seem like they were considered the cream of the crop; and these are folks who had been at the likes of these companies for at least a couple of years. [^o)]<o:p></o:p>

    Please, I beg you; don't bring any bad juju to whatever company you decide to work for now. [:)]

  • (cs) in reply to Anonymaly
    Anonymous:

    Tony Morris:
    Anonymous:
    Oh god it burns...

    Somebody needs to stamp this manager "return to IBM." And the lead programmer too, since he was willing to do the manager's dirty work.



    I resigned from IBM 4 weeks ago for the exact reason that I assume you are eluding to.
    Minimising retardedness (for some definition of) in my work was the primary objective and I believe I have succeeded well beyond my initial expectations.

    Please don't think I'm placing you into this generalization, but I'm seeing a very disturbing pattern.  For my entire professional career, I've worked at only two small companies over the past eleven years and have seen many developers (who became managers) and managers come and go. [^o)]<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    What really amazed me is that quite a few people had the acumen to pass the interview, but for some reason or another, they managed to "take a proverbial dump" on the company before parting ways.  Now, what makes this interesting is that a good number of these people came from some very highly recognized organizations in the technology sector.  Companies that most undergraduates clamor to on career day and have neophytes at the company wondering why in the heck they would want to leave a company that would leave a "scratch-n-sniff" gold star on their resume. [:|]<o:p></o:p>

    Well, I got to see why firsthand.  Some of them were probably the result of first-round layoffs, dismissed with the excuse of budget cuts, stock valuation, etc., when in fact, they were disguising the truth.  Some of these folks had no other skill (which I admire worked very well for them) than to be "everyone's" friend and either: a) manage to pawn all their work off onto someone else; b) feign enough incompetence to be given any work of significant challenge; or c) (in the case of management) spent more time having meetings and making processes so inefficient that more people were required to perform a task that may require nothing more than cutting and pasting data into an Excel spreadsheet. [:@]<o:p></o:p>

    I managed to find people who spent more time working at ways to not do work; these people were skilled in the art of negotiations; holding meetings to discuss who was responsible for what work, trying to determine the actual workflow, then holding a meeting to clarify what was supposed to be done.  Developers were called into these meetings like pawns, to support or debunk claims made by either side determining the workflow to prove or disprove that the "fully functional widget" could actually be done in three days, when the project manager had been mulling over the concept specification for almost three months and the contract deadline loomed only two weeks away.  At the same time, I saw one development lead creating a new system that became a Rube Goldberg machine, ensuring that any developer which knew at least one crucial piece of it was not only guaranteed a secure job, but could also extort a company for more money at its weakest moment by threatening to leave. [:@]<o:p></o:p>

    I'm worried that a lot of these people who infiltrated the smaller, pristine companies are starting to pass along bad habits they've learned from these companies (perhaps not recognizing they are doing this) while touting their past credentials as authoritative support for their decisions in what they do; be it good or bad. [:'(]<o:p></o:p>

    Nowadays I'm keeping a wary eye out for those folks coming from some of the 'big' companies.  I realize that some folk like to leave them for valid reasons (i.e. really need a new challenge or opportunity to advance, were the 'new guy' who got the layoff notice the week after they started, or just like to be 'seen'), but for some of the folk I've had the opportunity to meet, they don't seem like they were considered the cream of the crop; and these are folks who had been at the likes of these companies for at least a couple of years. [^o)]<o:p></o:p>

    Please, I beg you; don't bring any bad juju to whatever company you decide to work for now. [:)]

    <FONT face=Georgia>And the Oscar for the most creative use of emoticons goes to...</FONT>

  • Anonymaly (unregistered) in reply to BiggBru
    BiggBru:

    <FONT face=Georgia>And the Oscar for the most creative use of emoticons goes to...</FONT>

    They love me...  They really really love me! [:'(][:'(][:'(]

    I added those after the fact for fun; my elementary school guidance counselor told me I would never amount to anything, so I decided to surmount instead. [:D]

  • Equistatic (unregistered) in reply to Sean
    Sean:
    stonguse:

    <o:p></o:p>Why change the code just because the manager will *presumably* be upset because there aren’t a lot of lines? To me, that is a bigger WTF than the manager who uses LOC as a metric. Maybe he should sit down with the manager and talk about some other metrics that could be used. If the manager is still a knuckle head, then start shopping for a new job.<o:p></o:p>

    <o:p> </o:p>



    What color is the sky where you are?  Oh, I see it now.  It's over the gumdrop falls and through the peppermint forest, where managers listen to their employees and hardware programming jobs grow on trees.  You're right.  What was this Adam guy thinking?


    If I logically explained to my manager that version A and version B were equivalent except for the fact that version A was infinitely more maintainable and could be written faster and he still insisted on using version B because it had more LOC, I would have a chat with his boss and give him the same demo. If he agreed with the manager I would think to myself  "do I really want to artifically inflate the LOC on every project I work on?" After that I would shop them out.

    I work as a developer and I have never had any problems with a manager not listening to me. I am sorry for you if you haven't experienced the same treatment.


  • Anonymaly (unregistered) in reply to Equistatic
    Equistatic:
    Sean:
    stonguse:

    <?xml:namespace prefix = o /><o:p></o:p>Why change the code just because the manager will *presumably* be upset because there aren’t a lot of lines? To me, that is a bigger WTF than the manager who uses LOC as a metric. Maybe he should sit down with the manager and talk about some other metrics that could be used. If the manager is still a knuckle head, then start shopping for a new job.



    What color is the sky where you are?  Oh, I see it now.  It's over the gumdrop falls and through the peppermint forest, where managers listen to their employees and hardware programming jobs grow on trees.  You're right.  What was this Adam guy thinking?


    If I logically explained to my manager that version A and version B were equivalent except for the fact that version A was infinitely more maintainable and could be written faster and he still insisted on using version B because it had more LOC, I would have a chat with his boss and give him the same demo. If he agreed with the manager I would think to myself  "do I really want to artifically inflate the LOC on every project I work on?" After that I would shop them out.

    I work as a developer and I have never had any problems with a manager not listening to me. I am sorry for you if you haven't experienced the same treatment.

    Equistatic, what you're not considering is that some of these folks don't feel 'right' about consulting their boss' bosses.  Perhaps it was a bad vibe sent through channels that you shouldn't "go over anyone's head".  There was probably some reason for it, but there may also be a backlash occuring because of it.

  • (cs) in reply to Equistatic
    Anonymous:


    If I logically explained to my manager that version A and version B were equivalent except for the fact that version A was infinitely more maintainable and could be written faster and he still insisted on using version B because it had more LOC, I would have a chat with his boss and give him the same demo. If he agreed with the manager I would think to myself  "do I really want to artifically inflate the LOC on every project I work on?" After that I would shop them out.

    I work as a developer and I have never had any problems with a manager not listening to me. I am sorry for you if you haven't experienced the same treatment.



    I don't think the manager knows that the LOC is artificially inflated. It's just that he is measuring the performance of his people in LOC, so they have a good incentive to deliver high LOC numbers. Of course they are expected to do it by doing much work (solving many tasks). Doing it like that is close to sabotage. If I was their boss, I would consider firing the whole team, including the manager.

Leave a comment on “Measured By The Line”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article