Slashdot Mirror
It's Not About Lines of Code
Charles Connell writes: "What makes a programmer highly productive? Is it lines of code per
day? Lines of good code? In this article, I examine the concept of software
productivity. I look at some of the standard definitions for productivity
and show why they are wrong. I then propose a new definition that captures
what programming really is about." Read on for Connell's stab at a better way of evaluating the worth of programmer time.
CT Originally the contents of an article were here but there was
a communication problem resulting in us thinking we were given permission to
print the article here. Now that things have been cleared up, we've linked
the
original article which you can read instead.
Sorry about the inconvenience.
Fortunately, you can tell a programmer's personality type by the code they write - it is all explained in this paper by Kevin Marks & Maf Vosburgh
There are various types of programmers around. We've certainly worked with a wide selection. Over the years, we've come to realize that programmers can be divided into various "personality types". You don't stay the same personality-type your whole life though -- as you develop and learn, your approach to programming changes and that change is visible in your code. We're going to look at various functions and how programmers with different personalities would write them.
MacHack attendees have normally been around the block a few times. That means they have learnt various things, like when you're going around the block, it helps to watch where you're going, and be driving a tank. We know that a function has important responsibilities. It needs to check every error code, keep track of every byte it allocates, and that function needs to know how to cope with anything that happens, cleaning up perfectly after itself and returning an error code which explains what went wrong. But in order to write code like this you have to have made mistakes and learned from them. We know we have...
Ummm, this appears to be a regurgitation of a segment from Triumph of the Nerds . With the Microsoft guys saying that productivity should be based on getting a problem solved vs. the IBM guys saying that productivity should be based on LOC or KLOC (thousands of lines of code) or MLOC (millions) etc.
Being a "Data Miner" myself, I can certainly agree with the problem-solving-as-productivity approach, rather than the "how many inner joins can I throw at this to make it look like I am busy" approach.
Actually, the LOC as productivity is so foreign to MY thought process that I can not comprehend why anybody in management or in direct labor would bother to think about it.
Eve Fairbanks says I drive a hybrid!LOL
*sigh* Code quality is subjective. Perfect example:
:)
if( 1 == x )
Runs fine, looks butt ugly, but works. Is this of quality? As long as it works? As long as its easily readable?
What about a function that does:
int x ( int a, int b ) { return a/b; }
Runs fast. Can break.
Its all subjective baby. You can't measure it by speed of coding, by lines of code, number of functions, number of bugs..etc... Its a matter of the employeer of the programmer being happy with his output.
Next questin
-
ping -f 255.255.255.255 # if only
This guy clearly hasn't read The Mythical Man-Month. He should.
"It's hard to look at an unfinished piece of software and know how it's coming along"
That would depend on the development method and the actual product being developed. If you're developing APIs or libraries for other people to use, then you really can't "see" how far along it is, although you could count function or components complete. However, if you're developing something like a website or a client application, then you can see how far along things are though.
Of course I completely agree with measuring lines of code being boneheaded, unless of course the number of lines of code for the final product is known before it starts. Luckily I work with people that understand that numbers are irrelevant, and that the product won't be finished until long after it has been released to the public.
As far as an ideal solution, give the managers the convoluted formula of computing productivity that results in an answer that only slightly deviates from a standard amount. That way at least they'll stay out of your hair long enough to get some coding done.
What is needed are metrics for estimating how hard the problem is, not how hard someone worked to solve it. For estimating the cost of writing a program in the first place, there are various measurements of the problem complexity. One is function points. Google found about 10 pages of links. Here is a FAQ (not approved by the function point users group) that discusses the use of function points to measure productivity, among other things.
OH MY DEAR GOD!!! This man did not provide us with any revelations or entire new ways of doing things!!! ....LETS BURN HIM!!! BBUURRRNNN HIM!!!
you need to chill out... just because his idea was old doesnt mean you have to tear him a new ass hole...
The larger teams also have code reviews, so if a programmer's code leaves something to be desired, they can say so in those meetings and send him off to fix the problems they highlight. Said meetings understand that programmers of varying abilities work on the team, but they allow the team to address the most obvious shortcomings in someone's code.
A testing cycle is also required to insure that the programmer's not just saying he completed the requirement. Not much point in submitting code as complete if it doesn't operate as per the requirement's specification.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
However, I still lots of people's effor being measured by HIO (Hours in Office).
...richie - It is a good day to code.
He may have been a genius, but his bosses weren't.
And you wont get good code written from programmers who are underpaid, and pissed off either (but sex-starvation doesn't appear to do much harm to code productivity or quality.)
it look like Charles Connell submitted this story himself, so what's the problem?
The company doesn't base on the LOC of code.
This is how it works. But alittle background first. The company I work for creates billing/customer care software for cell phone comp's. The applications we have aren't out of the box. Each site is totally different.
Anyways. First the customer requests a change or new feature, a impact assessment(IA) is created with what's going to be changed and if any possible problems with current functionallity.
Once the Customer has reviewed the specs, they write off the IA and then it's my turn. I then review the IA, I then rewite a detail design doc laying out what objects I'm going to change(btw the application I work on is done in POwerbuilder) size of labels/colors/.... Once thats done, then I write out Unit test cases in TestDirector(http://www-svca.mercuryinteractive.c
AFTER thats all done, then I code. So 3 weeks that was given to me for this project, 50-60 is writing out documentation(no that I enjoy that crap.) then it's off coding, which has been done already while creating the Detail Design. Then it's off testing Unit and Application test cases.
97% of the time there are no bugs sent to the client and 99% what they asked for was added and working.
A quick trip to the IEEE's online store, and about $300 bucks will give you all the gory details you need to measure software quality ... provided you consider that software quality synonyous with programmer productivity.
... Hell, I'd piss on a spark plug if I thought it'd help.
For example. In grad school, we took the 1992, IEEE Standard for a Software Quality Metrics Methodology, along with GNU Flex, and wrote a program that would slice-n-dice C & C++ programs against a table of measureable metrics for code readability and reusability.
Of course, we had a blast testing it against winning entries from the 9th International Obfuscated C Code Contest. But we also noticed that there were just some things that it would never be able to test. For exmaple, while our little app spotted code that was uncommented, it could not tell us whether or not the comments were useful or relevant.
Point is, judging code and productivity is always (or at least until HR offices are equipped with Beowulf's) going to have a subjective element. Because lets' face it, when it comes down to it, many bosses really only care that the job gets done on-time and under-budget.
Or what's that great line from the movie "War Games"
healyourchurchwebsite.com - WWJB?
Though a bit off topic, here's a very good explanation behind this code:
s Gi ft/
http://research.microsoft.com/~tball/papers/Xma
Hooray for dabbrev-expand!!!
If there are any emacs users reading this who don't know what dabbrev-expand is, try it now. It works like magic!