- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
He'll be your manager soon...
Admin
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".
Admin
Crappy f**king forum software!!! What I meant to say was...
He'll be your boss soon...
Admin
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....
Admin
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.
Admin
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.
Admin
<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}
Admin
That must have been very few lines of code in order to fit "over a bottle of bourbon"!!
Admin
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 ;-)
Admin
My elementary school teachers all predicted I would become an Astronaut. They said all I did in school was "take up space"!
Admin
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.
Admin
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!
Admin
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.
Admin
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.
Admin
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...]
Admin
Is anyone really so dense as to think that lines-of-code produced is a metric worth collecting? Surely, this is a joke.
Admin
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
Admin
Sadly, it's far from a joke. Sadly.
Simon
Admin
No, no, for the sake of symmetry we must assume that they invented the "EarlGrey" language.
Admin
I
Admin
am
Admin
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
Admin
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.
Admin
cool
Admin
because
Admin
No, no, for the sake of symmetry we must assume that they invented the "EarlGrey" language.
(Second posting - now I know how to quote.. :-)
Admin
I
Admin
post
Admin
alot
Admin
.
Admin
It was standard practice for software management in the 1970s, mainly because IBM did it.
Admin
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.
Admin
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..
Admin
I think every code metric can be deceived somehow. LOC has its uses as long as people have no incentive to fake it.
Admin
Didn't really look that way, not to me anyway :)
Admin
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"!
Admin
Nope, quoting is not going to work for me, better revert to being a lurker again, Have a nice day.
Admin
Sounds like a nice scam...
(Y'know, I always wondered what exactly happened to the Japanese economy. I guess that explains a lot tbh.)
Admin
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.
Admin
No, "bubble" in that sense is quite a bit older. Try 1720 at least. Look up "South Sea bubble".
Sincerely,
Gene Wirchenko
Admin
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.
Admin
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.
Admin
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.
Admin
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/.
Admin
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.
Admin
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
Admin
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.