• Captain Toad (unregistered) in reply to uncool

    He'll be your manager soon...

  • (cs)

    I'm somehow reminded of a Jack T. Chick anti-evolution tract - "Isn't losing something the opposite of evolution?" Obviously, some people believe "progress" means "let's just add more stuff".

  • Captain Toad (unregistered) in reply to uncool
    Anonymous:

    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

    Crappy f**king forum software!!!  What I meant to say was...

    He'll be your boss soon...

  • M (unregistered)

    A previous manager of mine knew enough about C code to know that a rough and ready line count could be obtained by counting semi-colons. However, he was also clueless enough to use it to try and measure programmer productivity. The most productive programmers were the ones who changed the default function block header to no longer be surrounded by asterisks....

  • (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.


    I'd go so far as to say that the most productive thing one can do to existing code is to reduce the LOC while keeping functionality intact. Removing line breaks or comments doesn't count, obviously. Actually, removing comments sometimes helps too; there's way too much useless pro forma commenting being done.

    The biggest feeling of concrete achievement that I ever get in this job is at those times when I manage to cut a 300 line method down to 50 lines without losing any functionality.

    Had that last about a week ago: a method that dumps some objects to a formatted string used an incredibly convoluted, inefficient, verbose and inflexible way to ensure they'd be dumped in a particular order - which was A) unnecessary since the objects were guaranteed to arrive in that order and B) broken because it indirectly relied on them being in that order and would have produced incorrect results if they ever weren't. It would be truly worthy to be displayed here, but I would have to translate it to make sense, and it may just be too long.
  • (cs) in reply to Anita Tinkle
    Anonymous:

    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]).


    One of the most nervewracking experiences I've had in my professional career was when my boss sat in my cubicle at 10pm (after a 13-hour day) while I was trying to finish up and debug an important class. He was the self-proclaimed 3rd best (world-wide, even!!) assembly-language programmer, and this obviously made him an expert in everything else. The hard-hitting contributions to the project were "What does 'split' do? and What do those arrows mean?" (this is PERL, now).

    That was the night I got off the fence and actually decided to quit. Let's just say that I haven't regretted the decision.
  • (cs)

    <FONT size=4>Quantity</FONT> as a substitute for <FONT size=4>Quality</FONT> will bite you every time.

    {spoken from the voice of experience}

  • (cs) in reply to diaphanein

    Anonymous:
    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.

    That must have been very few lines of code in order to fit "over a bottle of bourbon"!!

  • (cs) in reply to brazzy
    brazzy:


    I'd go so far as to say that the most productive thing one can do to existing code is to reduce the LOC while keeping functionality intact. Removing line breaks or comments doesn't count, obviously. Actually, removing comments sometimes helps too; there's way too much useless pro forma commenting being done.


    This is so true. Except for those dirty tricks that lead to unreadable code. Today, while creating some unit tests, I discovered a method that was a) broken (didn't work as expected) b) always used in a redundant way (the way it was called from the rest of the program, it effectively did nothing at all).
    Removing such code is definitely more productive than writing it ;-)
  • (cs) in reply to Anonymaly
    Anonymous:
    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]

    My elementary school teachers all predicted I would become an Astronaut.  They said all I did in school was "take up space"!

  • . (unregistered)

    Everyone knows you should spend 3 days doing a full function point analysis.  That's the only way you can determine whether you are getting cheated  by those nafarious lazy programmers.




  • (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)]

    *snipped*<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    <o:p></o:p>

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

    I can say ditto to that.. One place I worked highered anyone who breathed air and say that "Yeah, I am a software developer". Only to show up the first day and not know how to turn on a computer and spent most of their time asking the person next to them as many questions as possible until the work was done. Then have the manager say "Yeah, so-so does excellent work!". Nice when this person had a masters degree in mechanical engineering! People wonder why I went for greener pastures. Word of advice, if you do work for the big-dogs out there ask as many questions as you possibly can about anything you will ever do for whatever project they place you on!

  • (cs) in reply to Anita Tinkle
    Anonymous:
    [(defectX & severityY, n...)/(#of features implemented + #tasks completed)] == Defect Level

    That is fine, so long as the features/tasks that two programmers complete are on equal level of difficulty. I've worked with some poor programmers, we (Me and the other good programmer) kept their code off this site by giving them easy sections, while we took the hard tasks. I'm sure that my scores would be an order of magnitude worse than the lesser programmers.

    Fortunately everyone knew I was a better programmer (including the less programmers). In their defense they were better than me at other tasks.

  • (cs) in reply to Anonymaly

    I think one of the worst consulting experiences I ever had was made even worse by the LOC thing. I went in, and there were no subroutines, there were no abstractions, there was no consistency. When I got done, the code ran faster, and was about 1/10th the size of the original code (mostly from removed redundant code), and HUGELY easier to maintain (which was the reason I'd been brought in, to make it easier to maintain). I thought I'd done a pretty good job.

    Imagine my surprise when the management types confronted me with the fact that not one single program had increased in size. What had I been doing for 6 months? Did I do any work at all? I'm pulling up these hideous chunks of code on the overhead, then comparing them to code I wrote that does the same thing in half the space, and is readable, and doesn't reinvent the wheel, and I can see in their faces that they think the ugly code, which is completely unreadable, must be better than the readable code, just because it looks scary.

    They had no grasp of OOP, so there were subroutines that I had reduced to simple function calls with friendly names like doObscureProcessToFindData(data); and they're asking me things like "Do you think it's just going to work because you named it 'thing that will work'?" and I'm responding with things like "Well it DOES, DOESN'T IT?!?!"

    After they paid me and I left, they went through and erased all traces of my existence in my comments, so two years later when I got hired by a guy in another part of the company to integrate some third party code into their code, I got to listen to a story from the new Lead Programmer of how he'd written almost all this code from scratch. He was fired for some code he HAD written a couple of weeks later, and I ended up getting his job because I worked so well with the code.

  • (cs) in reply to Anonymaly
    Anonymous:

    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.



    Anybody who ever worked for me knew, explicitly, that they were welcome to go around me to my boss if they felt the need.

    If anybody had ever felt the need, I would have interpreted it as a sign that I had a problem.  Probably (but not necessarily) with me.

    Open systems are not only for code...[lightbulb emoticon would go here if I could figure out, quickly, without risking losing all this typing, how to do it...]
  • AgileGuy (unregistered)

    Is anyone really so dense as to think that lines-of-code produced is a metric worth collecting? Surely, this is a joke.

  • (cs) in reply to Anonymaly
    Anonymous:
    Equistatic:
    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.


    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.


    If he is willing to quit over the nonsense, what backlash can there really be?  There are definitely things that I would not do

    I am glad I have a good boss.  I have had bad bosses.  There is a difference, one that permeates the job.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to AgileGuy
    Anonymous:
    Is anyone really so dense as to think that lines-of-code produced is a metric worth collecting? Surely, this is a joke.


    Sadly, it's far from a joke.  Sadly.

    Simon
  • shadowseeker (unregistered) in reply to Albatross

    No, no, for the sake of symmetry we must assume that they invented the "EarlGrey" language.

  • anon (unregistered) in reply to ammoQ

        I

  • anon (unregistered)

        am

  • (cs) in reply to Cooper
    Cooper:
    Anonymous:
    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.


    Anybody who ever worked for me knew, explicitly, that they were welcome to go around me to my boss if they felt the need.

    If anybody had ever felt the need, I would have interpreted it as a sign that I had a problem.  Probably (but not necessarily) with me.

    Open systems are not only for code...[lightbulb emoticon would go here if I could figure out, quickly, without risking losing all this typing, how to do it...]


    The university I attended had a policy for complaints.  If you had a problem with an instructor, the first step was to take it up with him.  If the results were not satisfactory, then you could go to the department chair, and so on.  Skipping steps was frowned upon.  This last bit makes rather a difference.

    Sincerely,

    Gene Wirchenko

  • Ross (unregistered)

    In the mid 90s I worked for the US R&D division of Juki corporation, in the surface mount technology (i.e. pick-and-place machines... the assembly line machines that populate all manner of control boards, motherboards, etc...)

    They started the software division because to some extent they knew they were getting bilked by the contracting company (Fujisoft ABC) that had been doing the bulk of the software developement for them to that point.

    It wasn't apparent just how much they had been bilked until I sat down to add some new functionality to the line monitoring software due to the capabilities of the new machines that Juki was about to release. I literally found chunks of 60-80 lines of code that did all kinds of algorythmic gymnastics to set the vales of 7 variables that were being passed to boolean function whose result was checked to indicate which of 2 seperate 200+ LOC blocks of code got executed.

    When I went down the path of investigating what the function did (obfuscated by nesting a few more calls to boolean functions each taking a succession of massaged parameters) the root call was one line: 'return true;'

    I approached my bosses with my analysis of the situation... roughly 800 lines of code that upon first perusal actually did something boiled down to either not being executed or were totally irrelvant. None of the itermediary variables were used anywhere else... literally 800 lines of code was just pure BS... it had no other effect than to eat memory and CPU cycles.

    I found out that what I had discovered was exactly the reason we were being given work to do in the first place because thre was some concern that FSI was overbilling for certain coding efforts.

    Turns out that the contrator situation at that time in Japan was such that it was pretty standard practice to bill per LOC.

    Since I had deleted roughly 800 lines of code (causing a measurable improvement in the applications performance) without in any way changing the functionality of the app, I have always wondered if I didn't owe money to the company at that point... after all, I had generated *negative* 800 LOC.

  • anon (unregistered) in reply to anon

        cool

  • anon (unregistered) in reply to anon

        because

  • shadowseeker (unregistered) in reply to Albatross
    Albatross:
    Anonymous:

    Is this where Java was born?

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

    No, no, for the sake of symmetry we must assume that they invented the "EarlGrey" language.

    (Second posting - now I know how to quote.. :-)

  • anon (unregistered) in reply to anon

     I

  • anon (unregistered) in reply to anon

    post

  • anon (unregistered) in reply to anon

        alot

  • anon (unregistered) in reply to anon

    .

  • John Hensley (unregistered) in reply to AgileGuy
    Anonymous:
    Is anyone really so dense as to think that lines-of-code produced is a metric worth collecting? Surely, this is a joke.

    It was standard practice for software management in the 1970s, mainly because IBM did it.

  • (cs)

    While LOC is obviously not a good metric for billing or measuring the ultimate productivity, it does have some uses. It's very easy to calculate (unlike FP) and this can be done for small pieces of software, even single functions. If one subsystem is 1000 lines and another is 30000 lines (in the same language), it does tell something of the size and effort to produce - although not the whole story. If one product has an error rate of 10 errors/KLOC and another in the same field has 1 error/KLOC, it also tells something. However, one must always be careful when interpreting LOC values.

    LOC counting should be done in a standard way to get comparable values. Are comments counted? Variable definitions? Imports? And so on. Whitespace is usually stripped.

  • (cs)

    I forget where it is I read it, but there was a dev house somewhere that would automatically count the number of statements in the C code base to measure productivity.

    Somebody realized it measured statements simply by counting semicolons.

    It started innocently enough--every while loop became a for loop, and then the extra "accidental" semicolons started appearing at the ends of lines.

    Ultimately, someone realized that the parser also didn't escape comments.  Then things got ugly.

    /* ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; /
    /
    ;; Function: foo(int n)                ;; /
    /
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; /
    /
    ;; Description: This function ...      ;; */

    You get the idea..

  • (cs) in reply to K.Ovaska

    I think every code metric can be deceived somehow. LOC has its uses as long as people have no incentive to fake it.

  • (cs) in reply to shadowseeker
    Anonymous:
    (Second posting - now I know how to quote.. :-)

    Didn't really look that way, not to me anyway :)
  • shadowseeker (unregistered) in reply to impslayer
    impslayer:
    Anonymous:
    (Second posting - now I know how to quote.. :-)

    Didn't really look that way, not to me anyway :)

    Bah, and I tought that I had this k00l punchline.

    Oh, an by the way, if Moon Microsystems invented a programming language it would be called "Ceylon", not "EarlGrey" not "Coffee" - "Ceylon"!

  • shadowseeker (unregistered) in reply to shadowseeker

    Nope, quoting is not going to work for me, better revert to being a lurker again, Have a nice day.

  • (cs) in reply to Ross
    Anonymous:

    In the mid 90s I worked for the US R&D division of Juki corporation, in the surface mount technology (i.e. pick-and-place machines... the assembly line machines that populate all manner of control boards, motherboards, etc...)

    They started the software division because to some extent they knew they were getting bilked by the contracting company (Fujisoft ABC) that had been doing the bulk of the software developement for them to that point.

    It wasn't apparent just how much they had been bilked until I sat down to add some new functionality to the line monitoring software due to the capabilities of the new machines that Juki was about to release. I literally found chunks of 60-80 lines of code that did all kinds of algorythmic gymnastics to set the vales of 7 variables that were being passed to boolean function whose result was checked to indicate which of 2 seperate 200+ LOC blocks of code got executed.

    When I went down the path of investigating what the function did (obfuscated by nesting a few more calls to boolean functions each taking a succession of massaged parameters) the root call was one line: 'return true;'

    I approached my bosses with my analysis of the situation... roughly 800 lines of code that upon first perusal actually did something boiled down to either not being executed or were totally irrelvant. None of the itermediary variables were used anywhere else... literally 800 lines of code was just pure BS... it had no other effect than to eat memory and CPU cycles.

    I found out that what I had discovered was exactly the reason we were being given work to do in the first place because thre was some concern that FSI was overbilling for certain coding efforts.

    Turns out that the contrator situation at that time in Japan was such that it was pretty standard practice to bill per LOC.

    Since I had deleted roughly 800 lines of code (causing a measurable improvement in the applications performance) without in any way changing the functionality of the app, I have always wondered if I didn't owe money to the company at that point... after all, I had generated *negative* 800 LOC.

    Sounds like a nice scam...

    (Y'know, I always wondered what exactly happened to the Japanese economy. I guess that explains a lot tbh.)

  • (cs) in reply to makomk
    makomk:
    (Y'know, I always wondered what exactly happened to the Japanese economy. I guess that explains a lot tbh.)


    Nah. What happened to the Japanese economy was that in the late 1980s, they developed a massive economic bubble based mainly on real estate and fuelled by overeager credit-giving by banks. In the early 1990s, that bubble (actually I think it was where the term "economic bubble" was coined) burst, but gradually rather than quickly, so the country still hasn't recovered completely (the problem of what to do with all the nonperforming loans wasn't really tackled until a few years ago). The 1990s are called the "lost decade" in Japan.
  • (cs) in reply to brazzy
    brazzy:
    In the early 1990s, that bubble (actually I think it was where the term "economic bubble" was coined) burst,


    No, "bubble" in that sense is quite a bit older.  Try 1720 at least.  Look up "South Sea bubble".

    Sincerely,

    Gene Wirchenko

  • Anonymous (unregistered) in reply to ShawnD

    I hope you aren't seriously busting on VHDL, because that's crazy.

    Just as LOC is not a reasonable metric for how productive a programmer is, LOC is not a reasonable metric for how good a language is.

    On the whole, VHDL is a much better language than Verilog. Strong typing, alone, makes it better than Verilog. I developed in VHDL for years, and loved the language.

    Who on earth implements a flip-flop as an entity in VHDL? That just doesn't make any sense. You just imply one in a process statement. Why are you still passing around logic_1 and logic_0? Even if you did really wanted to reduce LOC, you could put all the std_logic inputs on one line and all the std_logic outputs on another... it just isn't good style.

    I can only hope that this post was in jest.

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    brazzy:
    In the early 1990s, that bubble (actually I think it was where the term "economic bubble" was coined) burst,


    No, "bubble" in that sense is quite a bit older.  Try 1720 at least.  Look up "South Sea bubble".


    I rather doubt they actually called it that at the time.  The economic phenomenon is of course very old; an even earlier (and more bizarre) example is the "tulip mania" in the Netherlands in 1636-37. But I think I read somewhere that the expression "bubble" for it was first used to describe what happened in Japan in the late 1980s.
  • (cs)

    KLOC metrics sometimes pop up in other areas besides software. Compare pre-revolutionary and post-revolutionary works of the Bolshevik poet Vladimir Mayakovsky. For instance, take a look at the visual structure of  "Our March," published in 1917, and "Good!," published in 1927. What happened? After attaining power, the Bolsheviks decreed that all "workers" should be paid according to output produced. For poets, that meant they were paid by the line.

    I guess it's pretty clear how well all that Bolshevik stuff worked out in the end.

  • (cs) in reply to Dave Nicolette

    Sorry, had a problem inserting the link to the page with Mayakovsky's poems. The URL is http://www.marxists.org/subject/art/literature/mayakovsky/.

  • (cs) in reply to brazzy

    Brazzy: "I rather doubt they actually called it that at the time. The economic phenomenon is of course very old; an even earlier (and more bizarre) example is the "tulip mania" in the Netherlands in 1636-37. But I think I read somewhere that the expression "bubble" for it was first used to describe what happened in Japan in the late 1980s."

    The earliest book I can quickly find referring to the South Sea Bubble under that name is:

    MEMOIRS OF EXTRAORDINARY POPULAR DELUSIONS

    BY CHARLES MACKAY

    dated to 1841 at http://www.gutenberg.org/dirs/etext96/ppdel10.txt

    This somewhat predates the Japanese example. I would expect the term 'Bubble' to have been used in this sense since before the Bubble Act of 1720.

  • (cs) in reply to Bellinghman

    fun thing is that the stupidity of using LOCs as a productivity metric can be shown by 20 years old examples such as the writing of the Apple Lisa core softwares back in 1982

  • (cs) in reply to masklinn

    been there, done that.

    Once worked on a team that got punished by management for having a negative KLOC count on a performance release.
    We'd removed 25.000 lines of dead and poorly performant code and replaced them with 10.000 lines of optimised code.

    Taught us to not do that anymore and in the future always make sure our code was as verbose as we could make it.

Leave a comment on “Measured By The Line”

Log In or post as a guest

Replying to comment #:

« Return to Article