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.
They just don't apply to this art/science. Would Michelangelo's boss have put him to task for square inches/day or pounds of statue/week output?
Dude, buy a copy of DeMarco/Lister's "Peopleware", original edition is circa 1985. Your "revelation" is old news and you offer no substantive recommendations for actually helping management measure or actuate programmer productivity. The Peopleware book is factful and entertaining and reaches no better conclusion than you have. After 17 years, don't you think your postulations should improve on previous work. Have you done any research on prior publications?
They should evaluate programmers by the length of thier beards. =)
I SURVIVED THE GREAT SLASHDOT BLACKOUT OF 2002!
In a commercial setting, the awnser is obvious: how much money the software makes is how to measure the programmer's acheivment.
In a different setting, it's not as clear......
It's obviously not about the number of lines of code. It's about the number of lines of code you can generate. With a simple while loop or for loop, you can generate infinite numbers of lines of code. Then, it becomes more about how fast you can generate the lines of code. Plus, you want to set a slight variation so that your employer doesn't notice, and thus you can get paid the most. Cause that's what coding really is about, isn't it?
As far as "what makes a programmer productive", I know what makes a programmer unproductive... reading Slashdot all day. Back to work, all of you!
I don't care if it's 90,000 hectares. That lake was not my doing.
And less like a math exam.
Instead of getting graded on how much you write, you get graded on quality. Is it clear, concise and to the point. Does it explain the points in your introduction?
Over course this is an oversimplification, but it does take into account if quality over quantity.
Phew, what a long winded way to say: KLOC in any form is a useless metric.
I was rather hoping for positive suggestions regarding better alternative, and especially some shiny references to back them up for when I take them to my boss.
The best metric I've found is simply "Time until feature complete". Just that. Elapsed time between a feature being requested and it going live in the field with no bug reports coming back. Anything else is largely bunk. Trouble with that is that it's very hard for twitchy bosses to deal with the interim stages. "Time to code complete" is easier for them to monitor and deal with, but as anyone who has actually supported a product will know, that's only the beginning of a piece of software's life. Push the time to code complete back by a week, and you can save yourself month of grief later. ;-)
If you were blocking sigs, you wouldn't have to read this.
This article was rather superficial and should have covered one point instead of several, giving the article a bit more depth. I got the feeling like it was written off the cuff this morning.
(How do I know Danny does more work just because he does the same amount of work in less code. Its like the author follows some reverse logical mistake that he is harping about.)
A very interesting book on this subject is "The Psychology of Computer Programming" by Weinberg. It will get you thinking! I think the "Mythical Man Month" also discusses related topics.
Thanks
I work as a professional software developer and I can say that reusing our existing code to extend features, etc has helped us reach deadlines. Why reinvent the wheel?
However, there is a breed of programmer that was not mentioned in the above article, I like to coin them the "Cut and Paste Coders." This breed of programmer likes to scour the net for code, and use them without giving credit to the program the code was lifted from. While immoral, could this be considered productive?
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...
Perhaps a more useful metrics are how many use cases a programmer has satisfied, or how many bugs were fixed. In other words, measure a programmer's productivity based on success in making customers/clients/users happy.
Best,
-jimbo
XML Tools for Mac OS X
I come up with some good ideas while drifting in and out of sleep. Sometimes all it takes is a nap, fortunately I work at home and the bed is only a short walk away from the office. I also found that it helps to keep a small dictating recorder on the bedstand, that way you can record your thoughts in case you've forgotten them by morning.
I think the only other items I would add to this are pursuit of programmer metrics include
It's hard to measure that, because the superficial situations are identical: programmers enthusiastically extending some well designed code on one hand, and a set of programmers grumbling about fixing things in a poorly written chunk of code.
"Provided by the management for your protection."
While I can appreciate the difficulty in measuring productivity and lines of code, the solution for productivity seems to be something along the lines of this:
Productivity = (# of Programs written)/ (# of lines of code * hours worked)
This formula, using a standardized program would show that the most useful programmer is someone who spends one hour on freshmeat to download the program that does exactly what you need. Despite writing ZERO code, this programmer is much more useful than anyone who writes code for even an hour because you won't have to maintain it!
Standard measures use outputs/inputs. Always have, always will (think of cars per hour for Ford - outputs/inputs).
Regards.
-Mark
One of the things that makes good programmer full stop is not worrying about trying to measure the imeasurable.
Cheers,
Ian
You won't have the same ruler for everyone, but at least you are counting work done rather than effort put forth. I don't care if someone writes 10k lines of code vs. someone writing 800 lines - if both pieces of code meet the requirements for the system, and are maintainable. I'd probably prefer the 800 lines of code anyways, since that would usually be _more_ maintainable.
It compared the lines of code and number of bugs to the salaries. Of course it said it was cheaper to hire a super programmer. But, it found that the only difference between the average programmer and the incompetent programmer was the number of bugs generated, not the lines of code.
People need to be reminded of the high cost of debugging. It takes a long time to track down a bug.
Fight Spammers!
; )
"If being a geek means being passionate about something, then I pity those who aren't geeks." - Pike65
Your manager doesn't care how many lines of code you do or don't write. He doesn't care what those lines do, or how they work. That's because the client or customer doesn't care about those things. All they do care about is features: Did you add what we needed to add today? Did you finish ahead of schedule or behind it? Will we deliver on time or a week later?
Optimize on your own time. All the non-developers care about is what gets into the final product, and if you meet the list of desired features, then you're productive. End of story.
Spot the bug in this thought, then:
"Danny's code probably will be easier to extend and modify, and likely will have a longer lifespan, because of its compactness."
This is potentially utter rot. If you make something "compact" then you're quite likely *using* the language to insert every idiom you can think of. That makes code *unreadable*, not productive at all.
(Yes, I've been known to argue in favour of using prgramming languages' idioms before now, and more to the point I expect folks who dare to look at my code output to be able to read it, or else have the decency not to criticise it) but there are limits.
The alternative is that he's implemented a sufficiently different top-level algorithm - and at that point you're not comparing like with like so you can't say one person is any more productive than another.
However, you could introduce "amount of desired algorithm implemented per day" into the formula for productivity calculation.
~Tim
--
Rushing on down to the circle of the turn
I forgot about Peopleware. Its a great book. The more I think about it the more useless this article was.
In the end I've found that project managers couldn't give a rats arse how many lines of code or how the hell you manage to do the work, as long as its in on time and hasn't caused any undue payments e.g. overtime etc.
For all they care, you could have had a pit of slaves being tortured for a week, but the code is in and working.
Mind you, if you bother to even try and explain how you did it or what the problem is, pm's usually start getting a very glazed over look in their eyes...
I work on contracts for commercial software and it is amazing how much code people can write and not comment it. I had to change the functionality of some program once and it took me 5 days to write 3 lines of source. Why? Because I had to wade through code with variable names like "int32 data[7];". As a bonus there were hardcoded numbers to the variable. I had to do hex dumps at one point to see where the data was being used and how.
As I shouldn't even have to say... commmenting your code improves productivity A LOT. Some people say you shouldn't comment code in a commercial product because then you can easily be replaced. My response to that is, why don't you do good work then you won't have to worry about being fired?
If I had an employee who's not commenting his code, that means the next coder that tries to change something is going to spend a bunch of completely unproductive days just trying to figure out what's going on. I think I'd fire the employee because of his incompetence and the amount of time/money he going to make me waste.
Outdoor digital photography, mostly in New Engl
Mechanical measurements do not really provide much value, just as trying to have everyone document all of their procedures ala ISO 9001 does not make good engineers replacable.
>> I then propose a new definition that captures
>> what programming is really about.
Apparently, though, the author had no intention of capturing what the *original definition* (i.e. lines-of-code) was about, which was providing a way of *quantifying* productivity so it can actually be compared, aggregated, and used for real management purposes. Note that Timothy also summarized the article by calling it "a new way of evaluating the worth of programmer time". But the word "evaluate" implies assigning a *value* to that time. Without any way of quantifying that value, there's no evaluation going on anyway.
This is a completely content-free article. For Pete's sake.
I talked to my boss one day about how the engineers where I work are measured. Basically, it's along the lines of 'does the work get done?'. The project is defined with milestones set over a period of time, and if a deadline is missed the milestones are moved around a bit.
We have engineers that may spend a day or two writing out a document to assist their coding the next day. That isn't considered a ding in their productivity. If anything, providing an insight into their code before they write it (psuedocode, not commenting) has been very helpful, particularly when the other engineers need to code parts that talk to each other.
I honestly have no idea how this would scale to a >50 employee company. If it's really that important to make sure you're squeezing every ounce of productivity from your employee, I'd be concerned about where exactly that company is heading. Seems like investing more time into pre-planning would be more fruitful than lighting a fire under an employee to attain 'measurable goals'.
In some ways, I'm glad I didn't choose programming. It's quite frustrating to predict when you'll have code you've never written before.
"Derp de derp."
That's all I have to say about that...
www.jmagar.com
-
Don't get me wrong, commenting your code is a must.
However, I would rather have a programmer who writes easily understood code but doesn't document it well than one who writes well documented but overly complex code.
I've worked on large projects where there was nearly a 1:1 ratio of comments to code, but the comment didn't help you see the big picture because the parts of the application were too far abstracted from reality. And the code was written in strange ways that made it hard for other people to understand.
In summary, the code can and show be written so that most of it documents itself. If the application is well designed and the code is written well, the need for a lot of in-code commenting goes way down. This is assuming we're not talking about assembler, which in my opinion should have a nearly 1:1 ratio of code/comments.
Now, if I can just get my boss to endorse this programming style...
A good quantitative measure of a swe's productivity is DLOC. Deliverable demonstrates after all peer reviews, code reviews, test etc.. what survived, thus good or useful code.
True, 2000 LOC / day is a worthless stat.
if you say a SWE averaged 2000 DLOC / day, you better be treating that gal/guy right.
This article seems to raise more questions than it attempts to answer... This is not surprising because the "programmer productivity" has been the subject of many debates.
The proposed definition ("Ability to solve customer problems quickly") seems to ignore several of the good points mentioned earlier. For example, one can be able to solve a customer's problem quickly with an ugly hack. Some undocumented spaghetti code full of black magic may be able to solve one problem quickly, but it would be impossible for anyone to maintain this code later. Or to re-use it for solving someone else's problem.
So who is more productive? The one who solved the problem quickly with an ugly hack or the one who solved the same problem by writing clean, documented and re-usable code?
So it is a pity that what appears to be the conclusion of this article has thrown away the notion of clean and well-documented code mentioned earlier. Maybe a better (but more complex) definition would be: "Ability to solve customer problems quickly and to solve future, similar, problems in a quicker way". The drawback of this definition is that it cannot be measured on the current project, but only when the next one appears.
-Raphaël
Just read "Techniques of Program Structure and Design"
They stab it with their steely knives,
But they just can't kill the beast.
I want to add another angle... I managed validation. I viewed our job as reducing 1-800 support calls to zero. In the end, support costs need to be rolled into productivity numbers for develpers also. A couple of support calls from a single user can easily make the gross margin for the sale to that user negative. (And for you "free beer" programmers -- same thing applies, wouldn't you rather write code than spend time supporting users?)
And a closing note: A wise manager once said: "Obviously you want smart, productive people on your project. Note that dumb, unproductive people are relatively harmless, because they are not productive enough to cause much damage. What you need to watch out for are dumb, productive people."
Betty Beentheredonethat.
Shes the guy that wrote the code that Ingrid knew about and modified to a new task.
So we have evidence that Betty writes documented, modifiable and extendable code that others can pick up and improve upon. She even appears to have created documentation that allowed Ingrid to know enough about the whole system to be able to identify the relevent program in the first place.
I've always operated like Ingrid Insightful - I just can't convince managers to agree with me. If I could I'd make mid-day trips down to the Art Institute, or just go for a stroll while thinking about anything but the problem (strangely, the answers always come to me as soon as I get my mind far enough away from the problem that I can see the big picture clearly ... or maybe it's not so strange).
Unfortunatly, I'm doing consulting work and there's something about the client prefering to pay for time on site. Suggestions for beating these concepts into management?
Even that may not gauge productivity well. Engineering a good solution takes time. On a software project that is unique you can't fast track your way to a finished product. While on some things I will sit down and start writting code; I realize that larger projects need to be designed first. Or at least need some up-front thought. Thats it folks: design and thought can give a good solution.
"Drug related crime" is a misnomer, "prohibition related crime" is the more accurate and correct phrase.
Having any defined metric is (IMHO) a Bad Thing in the long run, for the simple reason that people will sooner or later start gaming the metric. If you reward lines of code you get lots of lines of code. If you reward feature points you get lots of features. For a while I tried more abstract things like "user satisfaction," but that started drifting into the "The Customer Is Always Right" syndrom, with all the feature creep and bloat that goes with it. Using "my satisfaction as your manager" is even worse; brown-nosers are a danger to anyone undertaking a team effort with any element of risk.
So I started wondering: do I realy need to measure productivity at all? Why do I care? The bottom line was, I don't care. I'm not interested in "producivity" any more than I am in "attendence." At this point, I tell people if you want to know what your score is, play a game, open an on line stock market account, or post messages on a web page that keeps track of karma. In this team, the focus is on getting the job done, not on keeping score.
-- MarkusQ
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
I have always viewed good design and high maintainability as good programming. But I can see other standards applying as well depending of the type of application being written.
A metric that takes real productivity into account for new projects (the Ingrid example above wasn't a great one since she was maintaining code, not creating it) would be one that measures requirements met versus time. It would of course be up to the manager to say whether the time taken was too long, about right, or less than expected.
A developer that consistently meets requirements with working code, in a timely manner, is a good developer.
Clearly the key to success with this metric is managing your manager's expectations. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Agreed. I think it was Dijkstra who argued that if Lines Of Code are counted, then the number should be viewed as a liability rather than an asset. That is, LOC are not something we produce, but something we spend.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
It never was. Or maybe it was, back then.
Old-school lines of code were assembly instructions, or COBOL statements (which map fairly easily to assembler anyway).
But all this has changed, a lot.
Software these days is about components, about reuse, about APIs. Reinventing printf gets you more lines of code, but is useless and stupid (in most cases).
Object orientation throws productivity into a whole new ball game. You should get productivity points for reusing code, not for rewriting. So it's never, hasn't been for some time, about lines of code.
Even function points are better.
But anyway, is productivity such an issue for programmers?
Productivity is a business concern, and makes sense in a business environment. And businesses don't (shouldn't) build software by throwing programmers at it.
Businesses build software through a process that involves requirements, analysis, then design, test suites, and then coding and testing and documenting.
What part of all this does programming involve? 15%?
Forget lines of code. Forget kindergarden productivity measures, forget subjective analysis into what is "good code" and "documented code". You document BEFORE you code. And it is "good code" if it implements what is documented.
Anything else is just fooling around.
free the mallocs!
I work for IBM as a software engineer and one time in a meeting a mid-level manager actually uttered the phrase:
"Its been shown that code reviews increase quality by 94%".
I knew then that these people don't have a clue what programmers do. They want to quantify something that is qualitative. You just can't fight someone who lives in a contradiction.
Apoptosis
from programers napping under a tree and sipping a decaf mochaccino. Be careful, the parks are going to be full....
I'm not a programmer, but if I was caught "thinking" about a problem like that, I wouldn't last very long. At least in my line of work, engineering, you can't just think of an elegant solution, you have to tackle the problem and make results.
The example scenario could have just as easily been Ingrid remains under the tree thinking, and Fred and Danny finish the job for the customer to start on another project.
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
Richard von Weizs
It is really all about time and money. Both have already been posted seperately but these 2 measurements are the clincher.
Sometimes really good code is just not worth it.
Sometimes code is not worth it period. (There are better ways to solve the problem than a custom process)
If you don't make enough money to pay for the time- you won't be in business long. (At least as long as your software engineers are willing to live off their own credit cards and pick up company expenses.)
.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
While I admire the author's brave attempt to establish a new model, I must conclude that he has failed: Applying a quantitative measurement to a qualitative phenomenon is absurd. Do we judge a painter by the number of brushstrokes and conclude that Rothko is lazy and Van Gogh is a diligent worker?
There are many qualitative components by which a programmer can potentially be judged: sheer output, ability to debug others' code, ability to have code debugged by others, ability to create understandable extra-code documentation, affinity for the lifestyle of the person doing the judging (i.e., likes to go out for a beer after work, roots for the same professional sports team, etc...), concentration skills, hygeine, and so on. Attaching metrics to this is nothing short of masturbating one's ego. There is a wonderful allegory to this in Robert Anton Wilson's Schrödinger's Cat trilogy, in which a self-important researcher attempts to rate a woman's orgasm using measurements on scales developed by the doctor himself.
"What is the sound of one belly slapping?"
The point of developing a metric is to condense information in an easily digestible manner. Ideally, the metric should be easy to measure and not subject to manipulation. Although I admire your definition of productivity, it is essentially useless since it is based on qualitative instead of quantative data.
Productivity is a manufacturing concept that is inherently difficult to apply to the software creation process. At its base, it is usually defined as outputs produced/inputs required. This works very well for a manufacturing plant making gizmo X but does not work well for writing software.
The truth is that the only way to tell who is a good programmer versus a bad programmer is to have the years of experience in the industry to tell the difference.
Amen, brother. I was the poor bastard who was the "next programmer". Fixing "Fred's" poorly written and worse documented code did do wonders for my skills, however.
Best Slashdot Co
isn't who was more productive, Fred or Danny, in the situation above, but who was more productive if Fred wrote his 5000 lines in 5 days and got it done, and Danny wrote his 2500 lines, took him 10 days to get it done.
That's the dilemma facing project managers-- is it better to "get it working now" or "ease extensibility/maintenance later." There is no hard and fast solution. It's different for every project, and often misjudged, in part because you can't see into the future to determine its lifespan. Of course everyone wants two Dannys who get done in 5 days, but that's not the real world scenario.
Measuing the productivity of a software "designer/engineer/coder" or whatever you want to call them, is a very difficult thing to do. On our current project we are using a third party tool that is riddled with bugs, unfortuantly due to management desicions we are unable to ditch the product and search for a different tool. However, my team has remained highly productive during this past month while working with the vendor to solve the issues.
Have we produced many lines of code? Not really, probably around 9000 lines between the 6 of us over the past month, that is about 1500 lines per programmer... in over a month. According to any logic using "lines per day" or anything along those lines, we are in horrible shape. However, we have been solving many of the issues with the vendor, scouring over lines of code to ensure that the tools are working correctly, changing and tweaking our testing classes (Java) to ensure that everything is truly working the way that it is supposed to be.
Now, with about a month of time wasted according to typical programmer productivity analysis, we have a decent library of functionality built up (or easily migrated into a library), we are very familiar with the product that we are using and the APIs, and will probably come in on, or before schedule.
Was that time wasted? Were we unproductive? I would say no to both of those questions. Yes working with a vendor with broken software was frusterating and time consuming, however we now have an intamite knowledge of a third-party "black box" and we have, in the process of working with them, built up a suite of test cases that will help us immensily in the near-term future.
But, we only turned out 1500 lines per programmer in a month you say. However do to all of the debugging work, and API "scouring" we have done, we will probably be able to turn out closer to 500-1500 lines of good well documented and working code every day or so.
Well my point is simply this: Lines of code per day is simply not a good analysis. The best way to determin productivity is on a per project basis. How is the project coming? Are the objectives being met, are you solving the problems that are coming up in a timely fasion? There is no final answer, it must be evaluated per-project, per-team, per-company.
-ryanI worked with a programmer for years who used to complain that his program had grown so large it wouldn't fit into his editor anymore. What he was really doing was bragging about the lines of code he had written.
Then one year I had to look at his code to convert it from COBOL to SQLWindows. O my God! Whenever he could have easily written 6 lines to process an array, he had cut and paste the first line the number of iterations that he wanted and then changed the index number.
The funny thing was that in our shop nobody cared how many lines of code were written as long as it worked. He was an old COBOL programmer that had come from work places where they actually counted the lines.
I don't agree with that. It often is "better" (to use this expression) to not use regular expressions for example but a self-written routine that does the same task. The code might not be that small but it might be much faster. I (and the system running the software) would prefer this over the simplicity.
This story reminds me of a book we read in a university philosophy class entitled "The End of Work". It was about how despite the fact that the industrial revolution (and later the information revolution) was supposed to largely eliminate human labor, most people still find they spend most of their time working. The book suggested that a reduced work week would lead to greater productivity much the same way Ingrid was more productive. The main question posed in the book was this: if we are supposed to be benefiting from all these labor saving technologies, we aren't we working less? It also touched on related topics such as unemployment and wealth disparity. The problem with Ingrid in the above example is that she is the most likely candidate to get fired. Like it states above, there is no good direct way to measure productivity. That reality directly conflicts with a company's need to measure productivity. It sounds like Connell endorses the same idea proposed in "The End of Work". Unfortunately there is no quick, conrete solution to the problem. The answer sought in "The End of Work" is through legislation and tax incentives. The last criterion set forth by Connell is too abstract to use on any short term basis. It's simply just a messy and very abstract problem.
Be careful when you have to fire someone. I guess you will have to give a reason, and if you touch the subject of "You lack XYZ", your current employees when talking with the former will know your reasons.
Buy a Nintendo DS Lite
Charles Connell is playing the part of Danny Designer, writing an article which restates ideas that have been stated before. You, on the other hand, are playing the part of Ingrid, finding the old information and simply re-using it. I'm sure this is what Chris was hoping you would do, in a nifty reality-hack kinda way...
Um, yeah.
Almost every page when reading Presman's Software Engineering book, I felt disgusted and a "that's too fucking absurd, why can't anyone see it". The only things which actually made sense were Fred Brooks' quotes.
You can't measure stuff like that. How do you measure love, for example? My neighbour loves his wife 1.39, whereas I only 1.2. In fact, we had an argument last night. Oh come on.
Writing software becomes rigid and well-defined only after there is 100x the budgetted expenditure available, and 1000x the time needed to spend in the project. If you don't have those, then you better let robots write your well-defined software for you.
Doh!
Give the programmer a job to do.
Does he do it fast? does the stuff work well?
hes productive.
Wow, it's so wonderful to see such incisive an understanding of programmer productivity. Who knew that lines of code is a bad measurement of productivity? This changes everything!
Oh...wait a minute...this would be old news if it were posted on slashdot circa 1975, it's positively fossilized now. Sheesh.
Argh! Caught in the act! Guess I'd better get back to writing errors in code! ;-)
A feeling of having made the same mistake before: Deja Foobar
...this article, life (for me) would be a better thing. Thanks for noticing that the best way to solve a problem is not always to sit down and start coding until you have coded a solution.
I have seen a lot of good programmers code for hours, but I have also seen truly gifted programmers walk around and "process in the background", then go back and present a solution just as valid but with much less "machine time".
Sir_Haxalot
stuff |
However, this article is a troll. It's soooo hardocre, even the Gap Troll envious.
What stuns me is that there is evidently a plan in some municipalities want to tax software development efforts as if it were a manufacturing business.
For me software is a consultative and artistic endeavor.
I don't know how "science" ever made it into the moniker -- when they tax architects perhaps it would be categorically fair.
Old age and treachery almost always overcome youth and skill.
This is yet another case of trying to quantify something that is qualitiative. It's is pointless to try to measure somebody's quality as a programmer (or as anything else for that matter) by using some numerical assessment. The examples above demonstrate that clearly, but here's a couple more examples:
Which is more valuable, a programmer who churns out 1000 lines of code/day but very reclusive or the one that does 500 but is also good at communicating project directions with others?
Which is more valuable, an inexperienced programmer who learns quickly or an experienced programmer who doesn't?
if you want to know how good a programmer is to ask them the right questions. I'm not sure exactly what those questions are, it depends on what you want out of them. But I've been on many interviews and it's amazed me the vast differences in interview quality. People who are trying to measure the quality of a programmer by "lines of code" are setting themselves for lots of problems.
I think I was asked once to estimate lines of code I've written and I had NO idea. Frankly if somebody did know the answer to that question I'd be concerned. It sounds like somebody who's too busy keep track of the metrics that imply their skill rather than actually doing good work. These are likely the same people who are staring at the clock for the last 15 minutes of the day, constantly estimating the minimum amount they need to do to get by.
This sig has been temporarily disconnected or is no longer in service
If someone demanded more lines of code from me I'd write a perl script which would take all my loops and unroll them, then the function calls inline.
Never again would they want more lines of code.
Rod Taylor
Sometimes I feel most productive after I have deleted thousands of lines of code. Code that has been replaced by better code. A good day is when CVSweb reports +500 lines -3000 lines.
The ratio of code to comment is not important. It's not quantity, it's quality. The comment needs to say anything that is not obvious from the code that needs to be said for the reader, who knows nothing about the code, to understand what is going on.
Another important feature of comments is a changelog-ish sort of function whereby each software change is documented within the code. Where I work, all of us in Sustaining Engineering write in a bug number with each change that we make so we can go back and find why that change was made later on when we look at the code and wonder why the heck we did that.
These are a few good rules of thumb in my experience at least..
Ben
Having a quick and easy equation isn't inherently bad, until it gets into the hands of a lazy manager. I would argue good managers don't need or use stupid equations to figure which member of his team is productive or not. Bad managers on the otherhand don't care enough to really understand the project, the engineers or the problem to set realistic expectations. Having an equation gives the bad manager a false sense of control and often results in the wrong person getting credit. I don't have any solutions. Ultimately, I don't think there is one solution or even a best solution. Software development is an organic process, so the more specific an equation is, the more likely it won't work in practice. If all programmers were equally trained, there wouldn't be a need for productivity metrics.
Unfortunately that doesn't exist. Having programmers of varying experience and skill is part of the challenge and makes programming more challenging. Sometimes generalizing API is necessary to make it easier for other programmers. Sometimes generalizing is over engineering. No one can predict the future, therefore the concept of productivity is temporary and arbitrary.
Placing value on n lines of code is always a sketchy excercise. At best, it's harmless.
*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
"I have made this letter longer than usual, because I lack the time to make it short."
-- Blaise Pascal
If anyone deserved to have a programming language named after him, it was the originator of this quote. I just wish it had been a more concise and expressive language.
If five hours worth of study leads to five minutes worth of coding that solves the problem, it is a productive use of my time.
However, if five minutes of research leads to five hours of coding, no matter whether it solves the problem, it's a poor use of my time.
You're trying to define quality - quality of code. Just be certain you don't go insane trying.
One thing to keep in mind when rating programer productivity is Ease of Use & Understanding. :) )
If i can write a function in 100 lines and make it self explanitory, it would be worth the time to do so, so that a year from now a programmer can come in and modify it to relfect the changes in the corporate software.
This is a much better approach then trying to write the same function in 20 lines of code, but making it so cryptic it takes a trip to langley to decode. (and dont mention anything about "job security", because in a year you wont understand it either....
Another method of good coding is reusability.
if i can reuse some code, then by all means do so. otherwise make methods you write reusable so that others can improve their productivity.
This
If one as a developer cannot show progress in a matter that can be understood by manager types, then it seems to me that managers often then lean heavily on trivial numbers, such as lines of code or made up completion dates, just so they can put it all into a report. So I think how a developer communicates to the outside world (if they are in that position) makes a huge difference on how their achievement is rated.
if you measure the quality of a slashdot post by the number of lines of text/post then this article was pretty good!
Really though, this is a great example of another problem with many folks in the software industry: gripes/solutions
This reply inclusive.
This guy clearly hasn't read The Mythical Man-Month. He should.
I'm starting to work with EJB's, and I'm finding that a lot of the "code" has been put into xml files. So do I count the stuff in the xml files a code. Some of these files can get enormous and I think are often more difficult to get right than the actual code.
Also he left out another important resource that I use. I'll go out on the internet and books and download sample code that mostly does what I want. And just modify it. What level does that get me to?
My Weblog
having no metrics is a BAD Thing in the long run.
Why?
You need metrics to prove to clients that you can perform based upon YOUR schedule estimates, not thiers. (and we all know their estimates are "we want it done yesterday!")
Example:
You have a client who likes your work, but is interested in cutting down costs as much as possible. You say "I think it'll take 19 months to get this done". They say, "well, we were hoping for 12. Change your estimate."
How can you quantify your company's performance? How can you prove to the client that it will really take 19 months and that reducing it to 12 will do nothing but ensure that the project misses the schedule? By having metrics to back up your performance.
Using metrics to judge your employees is wrong, shameful, reserves you a special spot in hell, and will get you shot in my neighborhood. However, not being able to show the customer your track record in terms of performance is as good as giving the contract to your competitors.
In the future, I would want to not be isolated from my friends in the Space Station.
Fred now writes comments and he completes his program by writing 1000 lines of well-documented, correct code per day for five days. Danny also completes his assignment in five days, but he writes only 500 lines of code per day
) [20]&48){D=89;_=unqb24,qT,@
b=map{ord qB8,unqb8,qT,_^$a[--D]}@INC;s/...$/1$&/;Q=unqV,qb2 5,_;H=73;O=$b[4]>8^(P=(E=255)&(Q>>12^Q> ;>4^Q/8^Q))>8^(E&(F=(S=O>>14&7^O)
^S*8^S>=8
)+=P+(~F&E))for@a[128..$#a]}print+qT,@a}';s/[D-HO- U_]/\$$&/g;s/q/pack+/g;eval
Unfortunately, Danny's code was written in perl and looked like this:
s''$/=\2048;while(){G=29;R=142;if((@a=unqT="C*",_
I am one of those programmers-wannabes who got the chance in the it-heydays. I was surprised to see the difference between the good and the bad. In my experience a veteran can easily be fifty times as productive as a wannabe (read me...).
Ok, so I was a bad programmer. Today I am project leader, where I do better.
The writer is truly missing the point regarding the purpose of measuring performance regarding lines of code.
Source Lines of Code (LOC or SLOC) are used, by management, to get an understanding of the overall productivity of software engineers in general. It is not an end-all,be-all rule regarding software engineering.
If you take a sampling of 100 good programmers, given clear requirements, and measure their performance, you will be able to determine the overall productivity for a single engineer on a per day/week/month/year basis. This allows managers to make some determinations regarding project planning, enhancements, changes, and yes, to some degree, the performance of engineers.
For example, if I know that my engineering group of X people are capable of contributing 1000 LOC per person per month (per man-month) to a project, then I can better estimate the cost and schedule of a new project. The project's scope is determined by detailing the customer's desires, and developing a break-down of capability. (Things such as R&D, training, and new technologies are identified and have an appropriate risk factor associated with then).
A LOC estimate is associated with each capability, which consequently will produce a timeline and cost.
What the author should have really reflected upon was not how to refine the software productivity metric, but rather how to refine the application of that metric.
I never thought that productivity was measured in lines of code. To me, it's progress against a schedule.
and you're talking about code size. hmm.. glass house.
How we know is more important than what we know.
About 2 years ago, I was working on my first major project and the project manager called me one day out of nowhere to ask where my progress was (normally we covered this in a weekly meeting). I started giving him percentage estimates based on feature completeness, structure completeness, etc.
So then he asks "how many lines of code do you have?" I tell him that I don't use that as a gauge, I use what I just told him for my progress. Also told him that I don't count lines. He persisted, so I came up with a rough count. He says "so if you say you're at 60%, and have X lines of code written, then you'll have Y lines when you're done, right?"
I had to reiterate (for the third time in that phone call) that LOC means nothing - it may very well be that I only had 100 lines left to put together, but it would tie up the remaining functionality needed (by gluing all my pieces together).
But he just kept coming back and harping on that LOC number, no matter how I tried to persuade him that it was meaningless. He was convinced that this was how he would know how much work went into the project. I guess the 3 weeks of writing very little code and charting out the logic of the app didn't mean much to him. He was taken aback when I told him "I don't just start writing code on day 1, I plan things out"
It turned out to be the smart move, because within a 3 years I had to recode it for another system, then another several years later.
A feeling of having made the same mistake before: Deja Foobar
It didn't sell anything and therefore the programmers were not productive? I don't think so.
Hate to admit it, but the actually productivity of the entire company is a critical element in the success of the programmer. A programmer who's personality disorders (a good description of me) causes his products to be rejected one after the other is not productive.
A coder might write extremely fast, clean efficient code, but if the code is not used for what ever political, personality or other problems that blocked the code then, in this sense, the programmer was not "productive."
On the other hand, it is extremely productive for society to have a number of these risk taking initiatives in the works. The common figure that 90% of software projects fail is sad but not a total loss because the few successful products that evolve out of the fray generally make up for the loss.
Here is a good question. If a KDE programmer ads a super cool feature to the product "yafflte" (yet another failed free linux text editor) and Microsoft reverse engineers the feature and includes it in Winword, who was the productive one?
I feel like some intrinsic part of programmer productivity has been overlooked here. A lot of development is done in teams, working with groups of people. Sometimes a person can be of immense support to a team by providing insight, direction, explaining an existing system, etc... without writing a single line of code. I've known some programmers who never wanted to be bothered and others who became so swamped with people asking them questions that they sometimes had trouble getting their own work done. If Bill asks Rick a question, and Bill's answer takes an hour to explain, but saves Rick a day in wasted implementation, how does that affect the perceived productivity of Bill and Rick? Furthermore, how does this make you look at the productivity of someone who never wants to be bothered or someone who rarely asks questions even when they should?
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.
There is 3 types of code:
Bad code - which doesn't work.
Good code - which gets the job done.
Elegant code - which can grow as the needs change.
It is very very hard to write elegant code, and does require quite a bit of forthought, insight, luck and insanity to get it right.
III.IIVIVIXIIVIVIIIVVIIIIXVIIIXIIIIIIIIVIIIIVVIII
The Agony and the Exstacy.
BlackGriffen
Managers pull the same thing with percentages in hardware too though they deal with design coverage percentages. They LOVE to reduce everything down to a nice shiny little number which they can use to massage the actions of their underlings. Really, after a while it can get annoying where you think, "What Axis of Evil spawned them?"
Interestingly, I've never ever heard any logic designer I've ever worked with utter a comment like, "I can write 5000 lines of VHDL/Verilog a day" because it's far more difficult to write RTL rather than something in an imperative/transaction based language. In addition, there are things like timing fixes which don't exist in software land: "Whoops, Billy Bob screwed me by loading down this net so now I have to do something else."
Fortunately, hardware designers have a bunch of neat tools like model checkers and slop like that to make their life easier. Plus verification is critical for hardware..it's been estimated that 70% of the design effort is consumed by verification alone!
And people wonder why I became an EE even though I really like programming too...I suppose it's because methodology is more prevalent in hardware design and that is one of the key things which helps one get a lot of work done quickly, fairly accurately, and consistently across a whole project.
My personal favorite productivity measture: lines of code I've DELETED!
Yeah, I know this isn't any new revalation either, but I'm a believer in Refactoring[?]: improving code without adding functionality. Refactoring improved efficientcy, understandability, and removed coded duplication.
Read Martin Folwer's awsome book, and/or practice Extreme Programming[?], it'll change the way you program.
----------
I can't spell. What else is new?
If Slashdot is where the spelling-challenged go when they die, I'm in heaven.
It's not the size of your code, it's how you use it that counts.
___
It's the end of my comment as I know it and I feel fine.
The article originally appeared here last week. Sheesh. Don't pretend it's an original Slashdot article if it's not.
I think the sign of a good piece of code is that it accomplishes it's goal with a minimum of code. I think a good way to measure this would be to track the rate at which a programmer increases the features to code ratio. Whoever does this faster is the better programmer.
Still another problem is the short term variations in this ratio. All propgrammers bark up the wrong tree from time to time. Therefore, it only seems reasonable to check the programmer's productivity on a weekly basis, if not less even often.
Anyway, at my company, we get along fine without ever reviewing the programmers. We are all just expected to produce good code in a timely manner. We don't set rigid deadlines, and we get bonuses for all of the projects we complete, with more money for bigger projects. Programmer productivity seems to be a fairly useless metric.
Yes, I'm still a junky. Are you still a bitch?
What kind of engineer would get a DECAF mochaccino?? No wonder she fell asleep right afterwards...
Greg
To a shark, you are just another food choice...
For instance, the assumption that lines of code = complexity is false. Ultimately, these are what matters in programming:
How fast is the compiled program
How big is the compiled program
How easy is the source code to read
How stable is the compiled code
How secure is the program
How complete is the feature set
These are all about software quality, not quantity, though. Once you've measured qaulity, the only measure I can see for quantity is, "Did ya get the job done?" The key to measuring a programmers productivity, I think, is to have the programmer keep a log of what he's doing. With that log, the company can insist on improvement, a maintained level, give bonuses for productivity, etc. The only issue I could see with such a log idea is that the higher ups will become so obsessed with the log, and what the programmer is allowed to claim as a job done in the log, that the programmers won't be able to do their job. Oh, well, it was just an idea.
BlackGriffen
One problem with this is that it requires an estimate of program size up front. This usually involves a rapid design phase to produce a set of classes, who's size is estimated, which, in turn, translates to lines of code per class. Unfortunately, this changes the goal of the design phase from a sound, robust design, to "hurry up and finish so we know how bit it is".
Furthermore, while designs shouldn't churn too much, proper designs allow some latitude for change up front. This approach precludes that because it changes the project size estimates.
You could've hired me.
You: "Well, sir, I feel I've been very productive today."
---------
Slashdot me. I dare you.
- adam
I have had highly productive days where i wrote maybe 10 lines of code.
Hoorah.
dominionrd.blogspot.com - Restaurants on
Another attempt by someone to redefine how to overwork teenagers into coding your software? What is the point of this article? It so basic and obvious and seems only to say; "Write good code, write code fast, repeat". WTF!>?!!>?!
Sophistic logic loops are bugs, not a basis for a business model or an essay. Let your programmers... program. Crazy as it sounds...
Good code is just that... stupid. Defining proper "procedures" assumes writing code has anything to do with management wogs like you. I know the guy who wrote this is supposed to be the sheit here... but he reads like management.
These are my comments on the issue, obviously, I find the essay above to be wrong in it's very existence. After all, these issues are old, as someone has wisely pointed out earlier. Not to mention the jingoistic silliness of implying that good coding is your duty as an American. Then you must please management with good coding, fast coding, and documentation. Then, Ingrid will Q&A and suck your joystick if you were a good little programmer.
Man, sounds like Berlin 1939.
I give this essay a BONG!
Your Servant, B. Baggins
I don't think anyone has ever claimed lines of code per day is a useful or meaningful measure, except of course for pointy haired bosses.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
First off, metrics don't "prove" anything. But in any case, this generally doesn't come up because I don't discuss schedules with clients. I've found it is counter productive.
The closest I'm willing to come is something like:
If you think about it, the only reason I wouldn't be willing to work like this is if I expected to fail. Which I don't.-- MarkusQ
is how hot is Ingrid? She can streamline code and she goes to the health club - I think I'm in love!
It's called Perl.
Or `Obfuscated C'
Hell, some even call it APL or Unlambda
0xC3
Some of the better pieces on program/project metrics include extensive case studies on multiple representative cases. The other ones usually aren't worth reading.
Yours doesn't include any evidence whatsoever, just fictional examples that merely highlight how little you know about the subject. There's a lot of myths and misconceptions and myths about good programming practices and lots of people that spread them.
Your estimate of productivity of 1 programmer per day ("5000 lines of code") is way off. Multiple, very good case studies have shown this to be between 1 - 10 LOC/day on large projects including all development phases. Unlike junior programmers, experienced software engineers typically agree with this number (I've heard several claim it was actually closer to 1 LOC than 10 LOC in their organization).
I agree with you that LOC is not an ideal productivity measurement given the difference in programming language, programming style, program quality etc. There are many alternatives (e.g. function point analysis). However, LOC is simply the easiest to measure.
In some of the more advanced software developing organizations I've visited (i.e. CMM level 2 and upwards) metrics (of all sorts) are used to steer the process. Consequently, the programmers in those organizations have nine to five jobs because management is able to acurately estimate the workload for a project. Also these companies have coding standards and review processes to enforce those. In addition, they measure defects/kloc so they know how good their code is.
Good programmers get noticed in such environments because of their low defect rates, good quality code and good productivity.
Jilles
...lots of comments can vastly improve your daily lines-of-code count:-)
Everyone would agree that the real 'metric' is a combination of factors that, in total, attempts to measure "how much of the spec was implemented how fast". This doesn't necessarily measure quality, which is a whole other topic.
The idea of the Function Point methodology (been around for years) is to assign a metric based on total inputs, outputs, length, etc. etc. for an application. The number, on its own, is meaningless. Rather, it's a relative metric that over time will make sense within an organization. It allows you assign hindsight to foresight - i..e "That last project arrived under budget and under time and it's Function Point profile looked like this".
It's not perfect, but it's not bad. It was given birth way back in the heyday of mainframe Cobol development, but has tried to morph into a scheme usable in other worlds (like OO development). And, there are still legions of believers who flock to User conferences, so FP must be doing something right.
CrazyLegs
"Pork!!" said the Fish, and we all laughed.
If you need comments in order for your code to make sense, you need to rewrite your code.
My personal measure of coder productivity is as follows:
1. Take all the produced code.
2. Remove all the comments.
3. Present each function to a third party who is unfamiliar with the code, and ask them to explain how it works. If they can't, delete the function.
4. If you have anything left, remove all formatting except linebreaks, and count the *distinct* lines of code. (Bad coders tends to cut+paste, which would lead to overcounting.)
Tarsnap: Online backups for the truly paranoid
Notably the RAII pattern, which these clowns appear to be totally unaware of.
Is it lines of code per day? Lines of good code?
One answer. Quality Not Quantity(tm)
At the very least this means lines of good code, but in actual practice don't we want efficiency? That is, with each block of code shouldn't we want to do as much as we can while still maintaining readability and stability? I think that people are getting confused about the appropriateness of the word 'productivity' in this discussion, since in essence as long as you are simply counting lines the word you are instead looking for is 'prolificity'.
Ah, yes. Such as this "compact" solution to the n-queens contest: int v,i,j,k,l,s,a[99];main(){for(scanf("%d",&s);*a-s;v =a[j*=v]-a[i],k=i=s*k&&
++a[--i]);printf("\n\n");} Very easy to extend and modify, no?
Charles Connell is president of CHC-3 Consulting, teaches software engineering to corporate and university audiences, and writes frequently on computer topics.
Uh, remind me never to take any of your classes.
Have fun: Join D.N.A. (National Dyslexics Association)
Nah, writing V1 in TECO is what did it.
I could go the easy route and check every array index in the first array against every array index in all the other arrays. For all I know this is the most efficient way to do this.
But, instead I'm going to research some algorithm books and see if I can't find a more efficient way to retrieve the common elements.
I may very well end up with something that takes a lot longer to code and has less lines of code than the brute-force compare-every-element-against-every-other-element method. But if the payoff is faster, tighter code, then my research and extra coding time will have paid off. However, to the untrained eye, it may look like I'm spending more time to produce less code.
If you are a manager reading this, remeber, the best solution may take longer and contain less code than a suboptimal solution! You have to think hard if you are going to try to quantify this - because nobody knows off the top of his/her head what the best algorithm for everything is. If you have a programmer who regularly researches the efficiency of the algorithms they use you will probably end up with a lot happier customers than if you just have people who bang out code without thinking hard about what they are doing. Unfortunately, doing things the right way makes the programmers job harder to quantify.
No, Thursday's out. How about never - is never good for you?
Define a standard task of medium complexity; ask all your slav^h^h^h^h programmers to solve it and obtain the per task LOC for each programmer, PTLOC(ProgrammerX). Then normalized-LOC, NLOC(ProgrammerX) =def LOC(ProgrammerX)/PTLOC(ProgrammerX).
Now you have a relative productivity measure of all your programmers.
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
with the water playing on the back of my neck... no time passes... and viola! A solution!
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?
It's bad form to use an analogy that refutes your argument, but it shows guts!
I always thought that the only really good thing about measuring LOCs was that the number was easy to gather. Yes, the meaning is limitted. Yes, the number of lines you produce changes dramatically regarding where you are in the lifecycle of a project. Yes, the numbers are next to meaningly when comparing different languages or different developers. But you can calculate it easily. Pretty hard to measure the quality of the approach.
So the metric has value when used with care and caution.
If you are in a junit environment, doesn't measuring test cases passed really give you the best idea of progress?
However, I still lots of people's effor being measured by HIO (Hours in Office).
...richie - It is a good day to code.
If you want to work differently from everyone else, you'd better EXCEED what others are doing, not just make sure "the features I was working on was completed on time".
In 5 years I've deleted more lines of other people's code than I've written myself, but most of the stuff I do is redistributing someone's functional implementations.
The result?
1. Less bugs due to less lines of code. Bugs are easier to spot.
2. More code reuse.
3. More readable.
4. smaller binary size.
5. Faster (mainly 'cos you can see what it's actually doing)
The ultimate irony is the point that the code runs faster. Normally people have written 'optimisations' which are unreadable and don't quite work as expected, so they compensate elsewhere...
Evgeryone seems to have missed the BEST measure of productivity:
How many Other Programmers are lined up trying to steal the Credit for the good programmer's work.
I like commentParserDatabaseCursor. I also like i, j, p, and retval. The length of an identifier should be roughly proportional to the log of the size of its scope. A file scope "i" is an abomination. A loop scope "commentParserDatabaseCursor" is an idiocy.
As a general rule, clean and short code is easier to read than clean and long code. For example, which of the following is easier to read (assuming you know C)? This?
Or this?
There's not much arguing that using the ?: operator is idiomatic in C or C++; many procedural and OO languages have no direct equivalent. And yet, when used correctly (!), it can tidy up half a page of code into a line or two. It's also more semantically meaningful; the above code is assigning a value to skyColour depending on some condition, and IMHO it's clearer to attach the condition to the expression being assigned than the whole statement.
There are much more powerful versions of this idea (see "pattern matching" in ML, or "regular expression processing" in Perl), where using an idiomatic feature of the language in an appropriate context makes for code that is shorter, easier to read and more meaningful than a more naive "longhand" equivalent. Sometimes it requires a basic familiarity with the language -- the syntax of the constructions mentioned here isn't obvious to those who don't know -- but to any reasonably experienced programmer, short and clear is likely to be better than long and tedious.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.)
Boss: How many lines of code did you do today?
Coder: 1
Boss: [next day], how many lines did you do today?
Coder: 1
Boss: [day 3] how many lines did you do today?
Coder: 1
Boss: how come you only do one line per day
Coder: Actually I'm working on the same line.
Boss: How many lines is the damn program?!?
Coder: 1
Boss: You're programming in Perl again arent you...
who could do a 90% solution to a problem in days that would have taken any one else weeks. There were two problems with him: he knew he was that good and it took the rest of us weeks to finish his code.
Just another post below my threshold.
Actually you could have mgmt that doesn't even know enough to debate whether or not they should have productivity metrics.
Of course, they stay off your butt b/c they are clueless.
-hc- I always get the shakes before a drop...
Getting away from a problem sometimes is a good way to solve it.
Works for debugging, anyway.
Once upon a time we were stuck for ages with a horrible bug, and were making no progress. I went home for a bath (don't remember at this distance why I thought that was necessary), and in the bath worked out what must be going wrong.
On returning to the office I got some coffee and wandered over to my desk, ignoring the group of people still huddled round the minicomputer. After a few minutes I looked up and said "You have fixed, it haven't you?". "No", they said.
So I told them which module to look in, and then which line of code was wrong, without the listing in front of me, and for no apparent reason they got quite cross when they discovered I was right.
... that Java is better than Perl. It takes so many more lines of code to do the same simple thing. 'splains everything.
Miko O'Sullivan
if (daytime) skyColour = blue; else skyColour = black;
if (daytime) skyColour = blue;
else skyColour = black;
skyColour = daytime ? blue : black;
//SkyColour = look out the damn window and know for yourself!
I hate to complain, but now slashdot is becoming more like most other annoying web sites cluttered with distracting advertising. Is there software that can block these annoying "pop in" type ads?
Thank you for your insight! I'm going to hold onto this one just incase I have to show a prospective boss in the future :)
--g33k
wasn't the latest incarnation of the linux VM written "fred fastfinger" style...?
also, there is a giant grey square in the middle of this thread. wtf??
That man tried to kill mah Daddy
Example Fredy FastFingers produces 5,000 lines of perfect optimized code a day, but if he only makes $30,000.00 a year then he is an idiot and who cares!
A boss of mine once said: "No one likes counting KLOC, but everyone does it". Have you ever worked in a big company that didn't count lines of code? I haven't.
;)
But, as a programmer, there are two things I really like doing with existing code: adding consts and removing duplicates
Completely off-topic, but I'm amazed Mozilla displays that correctly. Source should have been
goto considered harmful.
write ONE really good line of code per day.
I work for the Navy, and I'm not sure if this is just a Navy, DoD, or industry standard -- but we predict 1 man-hour per line of code. Of course when I first heard that I thought about how slow that was, but it makes more sense now (e.g. lifetime of the code, maintenance, training, reading, etc.). Does anyone else work for a place that puts a price or predicts time per line of code? If so, I'd like to see how it compares to the Navy.
where:
Tim ODonnell (trying to be the most
To sum it up - efficient code is not 5 lines instead of 20. It is 500 lines of good design instead of 1000 of uncommented hack.
<^>_<(ô ô)>_<^>
lines_of_code_added + 2 * lines_of_code_deleted + 0.9 * lines_of_code_changed -10 * needless_changes_or_additions+number_of_minutes_ex plaining_difficult_stuff_to_coworkers_needing_help + some_constant * amount_of_great_ideas_improving_the_design_of_the_ product + some_really_high_number * solving_some_really_tough_problems + some_reasonably_large_number * solving_some_moderately_hard_problems + some_pretty_low_number * solving_relatively_trivial_problems + some_large_constant * obscure_knowledge_of_esoteric_topics_helping_impro ve_the_design_of_domain_specific_code + some_other_large_constant * ability_to_write_clean_and_efficient_code_for_both _trivial_and_complex_programming_tasks + some_moderately_large_constant * not_having_a_gigantic_ego_and_be_willing_to_accept _other_peoples_solutions_when_they_are_better + another_large_constant * ability_to_understand_business_objectives_and_espe cially_the_needs_of_clients_and_apply_that_to_the_ task_at_hand + lots_of_other_factors_i_probably_have_forgotten
* an office with a door
* the best tools
* minimal interruptions
* minimal meetings
* reasonable schedules
Fuggit about measuring anything, you'll only
get what you measure.
Really, the most successful software projects are going to be ones where:
- The development is iterative, the only solid dates -- at least early -- are the ones for the next couple of iterations (or management and users understand that if the end date is solid the feature set can't be), and users and management have enough daily, non-disruptive involvement in the project to understand "the code count went down, and had a definite positive impact on the project."; Or
- The date shipped is the only thing that matters and the organization is willing to burn through people and sacrifice efficiency down the road
Note that from a software engineering perspective, the latter approach seems invalid, but from a business standpoint it's possible that it's correct given certain market conditions (though personally I doubt it's valid even from a business standpoint if the software in question has long-term importance for the company).If one absolutely needs a concrete measure of progress, it should be growth in the feature/bug count ratio.
You want to measure documentation separately, because it obviously isn't used in the same way as code.
For the code, the metric you'd actually like is something like number of useful, novel expressions.
Copying a section of code doesn't add anything, because the lines aren't novel. Any changes you make to the lines do count, though. Making an existing block of code into a separate procedure adds a novel expression, and the expression is useful if you call it from multiple places (i.e., if the procedure is a useful abstraction). Calling a procedure with a new set of arguments is novel and generally useful.
Basically, you want to know how long the day's work had to be, given the pre-existing code, if it was done optimally.
If you add a penalty for making the code needlessly long, then a day spent reworking bad code to be shorter by combining common expressions, removing extraneous computation, etc, will also be considered productive.
For the documentation, it is easier to consider but harder to quantify. You are now measuring the number of correct and useful pieces of information that a person would get out of reading the commented code. The information may, of course, be obvious from the control structure, implied by the variable names, or actually in comments; since comments add to the length of the code without adding any functionality, using coding idioms that the reader will know (because they're part of the company's style guide or common throughout the code) and informative names is better than putting in comments, unless it is impossible (which is frequently the case).
Of course, it's hard to quantify "pieces of information" and hard to judge objectively what can be gotten out of a block of code, which is one reason this isn't something you can set up cvs to do each day or something.
This means that the ideal block of code, which should be counted as the most possible for a given problem, has these properties: it (or an equivalent block) has to be there in order for the project to do what it's supposed to do; it is not replicated, in whole or in part, anywhere else in the project (if it did, it would do better to call the other part); its behavior is clear from the names of the procedures, variables, and types; any common algorithms are implemented in the standard ways; and unusual algorithms are commented explicitly.
I think this metric would measure productivity effectively. Of course, it doesn't help productivity to actually try to measure it.
Anyhow, he could type 70+ word per minute. The next fastest were two people who maxed out at 50 +/- wpm. One of these people got an 'A' and the other got a 'B-'. The difference? The 'A' student made very few mistakes. The 'B-' student spelled like most Slashdotters.
My pal who could do 70 wpm? He made about one error per page. He was a machine! :)
Me? It took me 3 days to type this. :P
One of the guidelines I have to find code to refactor : look for comments. Comments should be in the checkin log of the file, in the changelog of the project , in the header files and in the naming of variables and functions. And in the diff between revisions.
,and you get a very recognisable frustration. Only, the solution for it is not 'better comments'. It's better code
If they are in the code you have a good chance to point out weaknesses in the code. Occasionally these are weaknesses that are very hard to avoid. Often not.
Which leads to guideline two: always try to upgrade the clarity of the code when you do a small mod(usually a fix) . Small mods tend to degrade the code quality, the maintainability, even though the code works better than before.
Comments in the code also quickly become irrelevant, and even misleading, if they aren't already bad from the start. So take a weak fix and append a confusing comment
Obviously there is some value to the metric, however programming skill is not a function of one variable :)
I wonder how many bad pieces Michelangelo did before he did a good one? Did he copy other people and then modify his style as he progressed? Did he just do one piece or was he prolific?
If I can upgrade Linux to FreeBSD and get all
the benefits of Linux 3.x w/o writing a single
line of code, because it's already in FreeBSD,
then I can save the computer world a lot of
reinventing the OS.
The company I work for doesn't base my work 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 document laying out what objects I'm going to change(btw the application I work on is done in Powerbuilder) size of labels/colors/datawindow.... 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(not like I enjoy writting documentation.) 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.
about possible future problems. There are an infinite number of them. Unless you have an infinite amount of time before the project is due, focus on sound architecture, taking care of the "obvious future problems" if any, and let refactoring fix those "possible" problems if and when they ever arise.
Number of lines of code written, highest score wins. In short, why write in 100 lines what you can write in 1,000?
Number of lines of code written, lowest score wins. You end up with your own obfuscated coding contest. You might also find people rewriting other people's work, redesigning APIs and other infrastructure components, for no reason other than to lower their own score. This can lead to total chaos, fights in the parking lot, etc.
Number of good lines of code written a month. What's the definition of "good," and how subjective is it? If it includes comments, then how is the usefulness of a comment determined? I've seen developers write more comments than code, and in the end the comments said nothing useful that would've helped a new developer maintain the code.
Number of bugs fixed in a month. The programmer who spent a month researching the sev 2 bug that was affecting system availability or data integrity for the last three months isn't recognized for his/her achievements, while the intern who fixed 100 bugs pertaining to typos on the website and in the documentation is rewarded.
Number of bugs created in a month, lowest score wins. Nice idea, punishing people for creating bugs, but people might get so paranoid about causing bugs that the turnaround time for code is obscenely high.
Code complexity metric, lowest score wins: All this proves is that the programmer's capable of writing non-complex code but says nothing about the documentation for the code, the overall design of the component or subsystem the programmer was working on, etc.
Number of tasks completed in a month. This screws the guy who's got a hefty task that cannot be divided any further or the programmer waiting on the sysadmin to install the necessary development tools so that he/she can actually get started.
Customer satisfaction. The customers are pissed because the website is unstable, but the rest of the back office system is running perfectly fine. In the end, everyone -- the back-office developers, the database guys -- is punished when only the website people should've been put on call center duty for a week.
Number of customer issues resolved. There's a great incentive here to solve issues with kludgy hacks which, in six months to a year, might leave the company with a very flaky, unmaintainable system.
360-degree input, or "Mutually Assurred Destruction". This was a system IBM used -- still uses? -- where your peers, some picked by you, some by your manager, would fill out a survey and offer opinions about you. The manager would then piece it all together and come up with a result. Like Dilbert called it, it's "mutually-assurred destruction," although I saw it work the exact opposite way many times.
There's so much more that goes into developing and delivering software than just writing lines of code. And the number of lines of code written isn't all that significant if the design sucks, if the documentation is unusable by the people who need it, if the call center people supporting the thing aren't trained properly, or if the systems supporting the website or the database are unstable. How do you put a score next to a name when many of the things contributing to that score are subjective or out of the control of the person being scored? We're not building CD players here!
This guy is "president of CHC-3 Consulting, teaches software engineering to corporate and university audiences, and writes frequently on computer topics". Still he failed to mention function points (an old measure of product size) or use cases (a more modern measure of product size).
He also fails to recognize that programming is a group activity, where one person can be seemingly unproductive, but in reality being vital for the productivity of the group. Typical such persons are mentors, which spends some of their time helping others. Mentors may not produce a single line of code, but still be the most valuable person in the group.
Alistair Cockburn does in his modern classic "Agile Software Development" state that software development is a "Cooperative Game of Invention and Communication". Therefore the productivity is best measured at the team level, since they are, in the end, cooperating.
Also, I think it is quite clear that use cases, or user stories, or whatever you wish to call them, are the best way to describe the wishes of the customer. Fulfilling these wishes are ultimately the only thing that matters.
So, I would say that the number of finished use cases per unit of time, for the whole team, is by far the most meaningful measure of productivity.
Mats
being able to answer the question
"what are you doing to solve the problem?"
If you know, big picture, what your plan is, but you've spent 2 days figuring it out, that's probably better than just jumping in and writing a bunch of crap just for the sake of writing it. You're less likely to have to re-write that way.
In this case, you're probably going to write less code overall, but that's cool. This is a combo of Danny & Ingrid.
The problem is, you can't keep too many Ingrids around, because what if the required feature isn't already available? Then you have a staff of people who just laze around hoping an easier solution will manifest itself. It's all about balance.
Knowing how to proceed in solving the problem is a useful metric in an unfinished software product.
The process of software development is still a creative task, requiring the exercise of human imagination and judgement.
Few can properly measure the output of a programmer except in Yhellowstones (brown fluid in --> yellow fluid out) since this will remain a judgement call until this becomes a determinant rather than an emergent process.
A poet is still working even when gazing out the window.
Finally, usually communications/research time cuts down on code generation- and that's the real question. How can we have metrics unless there's a second opinion over whether code needs to be created?
-soup (GNUrd, Speaker to Machines) "Laugh at yourself- Why should everyone else have all the fun?" -Romanchek's 6th Ru
You should strive to make your design docs just good enough for the people who'll be reading them -- the maintenance programmers, who will also have the code. In other words, the design docs are the cliffnotes to the code. The code is always the authoritative design documentation.
BTW, I STRONGLY recommend reading Agile Software Development for anyone who's seriously interested in these issues.
Why would someone want to know "How many lines of code per day do you write?", or "How many good lines of code do you write?". The problem here isn't in the programmer being unable to be clocked, but not hiring proper management. If I am programming something, I don't want to report to someone who doesn't know what I'm doing, I want to be able to explain to him reasons for things, and him be able to understand it.
The issue arrises when an individual has to report to someone who just wants a number, and doesn't trust an individual. If upper management were to hire a manager that has proven performance, he should be trusted to say that "Coding is going along well, we have completed [fill_in_blank], and are well on our way to [fill_in_blank].".
Programmers can then show what they have done, and prove why it was done the way it was, and the closest management can understand. That management should also be educated or trained in communication between code, and his management (aka, his job).
We shouldn't have to say how many "pixels we painted", or "lines of code", or "notes played today".
In summary, the code can and show be written so that most of it documents itself.
Please excuse me for taking that line out of context. But it is important.
Regardless of the clarity of the code or lack therof, you need the comments - or another expression of the code's intent - to verify that it is doing what was intended.
"Self-documenting code" cannot be tested. This is because testing cannot determine if a program works, only that what it does matches what another document says it should do. The best automobile engine control program won't balance your checkbook, and vice-versa.
Once the comments (or other documents) are written, readable code is better than unreadable code. But if the only description of what the code should do is the code itself, the only thing you can test is the compiler.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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?
Using peer reviews and feedback, therefore, allows a manager to qualify a particular developer's "productivity" by asking the only metric worth anything - the opinion of other knowledgeable developers. Trying to equate any of this to any metric so far uncovered is truly pointless.
Not that there may not be a real metric (or, more likely, a complex set of metrics) out there that someone will discover to adequately measure this stuff; in the meantime, though, I'll continue to let the team examine, develop, grow, and rate itself. In the end, I know I'll have a strong group of developers who respect each other, work well together, can understand each other's code and approach, and who are...productive.
For that matter, the use of an obscure idiom can be readable if you take care to document properly.
At any rate, once you are in a situation where you want to measure amount of code, USE NUMBER OF TOKENS, not number of lines. (The number of words returned by a dumb word counter tool like the unix "wc" command is probably a good enough approximation to number of syntactical tokens.) Counting lines is useless in any of the modern languages where all whitespace is treated the same way regardless of whether it's space, tab, or end-of-line. Consider the degenerate cases:
//lots of lines
,
;
// versus just one line:
printf
(
"the number is %d\n"
foo
)
printf( "the number is %d\n", foo );
If you are trying to reduce complexity, reducing lines of code might not really be doing that - it might just be writing the same amount of code with more obfuscation, giving the opposite of the intended simplifying effect. Counting the number of tokens, or words, would be MUCH better.
Counting lines of code is a leftover from the days when languages were "dumber" and did things like require exact columns in the source code, and not let you throw in whitespace where you like.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
1. Have strict coding/testing standards.
2. Have a smart developer assign roughly equivalent (in terms of difficulty) use cases to the other developers.
3. Productivity is measured by number of cases completed through system with zero defects adjusted by their difficulty coefficient.
You can't let the folks whose productivity is being analysed control the analysis metric. You need to have work assigned by a knowledgable person. Pointy haired bosses need to be insulated from the actual code writers by at least one level of technical task leads.
When I worked doing barrels of C++ a day we had a program model tat we actually drew (one we came up with ourselves) We kept track of how complete each part of the program was by filling up that part's symbol with pen. the Managers liked that.
Though a bit off topic, here's a very good explanation behind this code:
s Gi ft/
http://research.microsoft.com/~tball/papers/Xma
Ugh.
Niklaus Wirth invented a language esteemed by acedemic professors, but not terribly useful in actual practice. I find it quite appropriate that he named it after the man who came up with Pascal's Wager - an argument for beliving in god that was hailed by the people who already believe in god, but utterly useless in practical application to its intended audience, those who don't.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
The firm I'm working for hired a contractor to write the system software for their scientific instrument.
... other conditional code // to exit
...
They later hired me.
It is now my job to maintain, expand and rewrite his original code as the device gets further from the prototyping stage.
Here's some metrics for you:
4000 lines of C code
Avg. Variable name length: 3 to 4 characters
Avg. Function Name Length: 3 to 4 characters
Total number of functions (not including state-machine functions): 9
Amount of documentation: nearly 0. Comments are laughable.
Total number of functions, including state-machine functions labelled from stsws0 through stsws30 - 40.
Total number of constant values used without #defines or assigned names: Too many to count.
Amount of documentation of constant values that aren't obviously for buffer/scratch space, but actually do something important: Zero.
Amount of dead code: Current investigation indicates somewhere between 30% and 60%.
Amount of dead code interspered with live code, so it's really difficult to work out what's a dead function, and what's live: All of it.
Level of interweaving of dead code and live code: pretty damn high.
Use of pound-defines for code switching and giving alternate code paths: Zero.
Use of pound-defines to switch blocks on and off that really you want to keep on ALL THE TIME (particularly as the app crashes if you turn them off): 10
Interesting idioms:
-- Use of pound-if(0) and pound-endif to bracket (useless) comment sections, eg:
pound-if(0)
This is a comment.
pound-endif
-- Use of a while loop to do error handling. Eg;
while (TRUE) {
if (condition) { error = 5; break; }
break;
}
if (error)
Number of pound-includes that are actually totally unneeded:
5.
Number of Windows 3.1 programming idioms used: 2 found so far. In a piece of code that *requires* NT4 and as such is Win32 only.
Other interesting idioms: Massively nested if's EVERYWHERE. Very little modularisation. Grabbing an HDC at that start of the app and not letting it go until shutdown, without specifying a Class DC.
The guy REWROTE FROM SCRATCH button controls and edit controls, using WM_MOUSExxx message and WM_CHAR handling, as part of the main frame window. Each edit/button has a separate cut/paste if statement block to handle it. There are about 80 controls on the main screen. This code is cut and pasted for each single control.
And for the final piéce de resistance;
Total number of local variables used: ZERO. 0. Nada. Zilch. EVERYTHING IS A GLOBAL VARIABLE.
Coming soon - pyrogyra
"Time Solution used without modification" / "Time to deliver solution" is the ultimate productivity measurement.
I've had about 2 good programemrs tell me the "avg" programmer writes about 10 lines per day, the rest of the figuring out algorithms are looking up APIs...is this true? Or should a "good" programmer just know how to write all these functions?
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
Radix(??) sort the first array into a hash table, then go through the second array and look up the hash of each element to see what elements of the first array it might match.
O(n) if your hash table is big enough that you won't get any double ups (assuming array values are unique), but still very fast if a table that big isn't possible.
While I have to grant that the guy made his point nicely, I must complain bitterly that he's seeded my brain with this question - now I want to know what the fastest algorithm would be, and I don't even have an application for it.
This is just as much nonsense about art as lines per day is a ridiculous metric for code. The issue isn't how much, it's how much that's GOOD.... Why is it that all forms of endeavor that don't involve writing code get no respect on /. ?
For that matter, your insights about management aren't much better--consider that managers might want progress reports to reduce the risk of the project failing, not to reduce the risk of getting fired WHEN the project fails.... Not every manager is pointy-headed, and not every code-jockey is a genius.......
"If a programmer can be highly productive by writing a negative amount of code, how do we measure productivity for software engineers? There is no easy answer to this question..."
The above is the article in a nutshell. Nothing to see here. Go back to work where the true measure of productivity is your paycheck. If money is an unfulfilling measure of your true worth then go out and buy yourself a cool new toy. It works for me.
heuristic algorithm seeks stochastic relationship
I work in an eBusiness sweatshop with entirely too much focus on VB COM. For fun a couple of months ago (when .Net hype hit), I re-wrote some of my code in Python, and then again in C#...
9 23 9&mode=thread -- the more powerful the language, the less time should be spent writing it.
For 200 lines of VB6, I used
- 120 lines of C# (mostly legible) or
- 80 lines of Python (which was 100% legible)
http://slashdot.org/article.pl?sid=01/05/01/153
— Antoine de Saint-Exupéry
Ceterum censeo subscriptionem esse delendam.
Anything, exept for "Hello, world" falls into the grey area of "kinda works, but we are not sure if that's what you need" or "works on my machine.." It would have been easier to have it "Good/Bad"...
<^>_<(ô ô)>_<^>
Before asking how to measure programmer productivity, or anybody's productivity for that matter, one must ask who wants to measure it.
Programmers who are concerned about their own productivity usually take what measures they can to increase it. Managers, however, have their own political agendas that rarely have anything to do with a programmer's idea of productivity.
Whatever standard of productivity a company adopts, it will be changed when business conditions or company politics change. For instance, even in a well run department a new manager will come in with a mandate to cut costs and boost productivity. Or, a bad manager will cover for his demoralized staff to protect his own turf. Or he'll fire a few programmers to please his superiors.
I was recently standing in line at the food court and heard a woman behind me say to her friend: "They just hired 11 new programmers to replace the 5 good ones they laid off last year."
Once I've typed ISDN_Terminals_Per_Trunk once, I can probably just type ISD M-/ and be done with it. Are typical software development tools so unforgivably lame that they lack something like emacs's dabbrev-expand?
Maybe my standards are misguided, but I've always considered this a basic function of a decent editor.
How true could be to say that we (programmers) write deterministic code through a non-deterministic process (in some degree...)?
How true would be to say that programmers write deterministic process through a non-deterministic process (to some degree... )??? ~~!@#(*$(???
Definition:Productivity, '2 a : the act or process of producing b : the creation of utility; especially : the making of goods available for use.' from Mariam Webster
Premise: Productivity cannot be measured except by creation of utility. Utility can be defined as a marginal increment of value. Value can be defined as a unit of production. Productivity then is a measure of increased value. Definitions of value have been attempted from Aristotle onward with varying degrees of acceptance. For business purposes value is found in the bottom line and is predicated upon Generally Accepted Accounting Practices.
If we put aside the idea of a programmer being made to be 'highly' productive as a pipe dream then increments of utility can be put forth as the only available measure of productivity. For example I find I'm more likely to be 'highly' productive the more people like me, do what I want them to do and give me what I want.
If we accept increased utility as a definition of productivity then the final product as it is defined becomes the final abitrator of value. This implies a Goal oriented approach to value based upon measurable increments to utility. This suggests any one programmer is capable of productivity only in so far as s/he is capable of adding to utility.
If this simple definition of productivity is looked at from the view point of Open Source an interesting phenomenon arises in terms of the artistry of programmers. The Renaissance and post Renaissance periods produced leaps in Science and the Arts something akin to what we're presently experience. It's been suggested the creation of perspective drawings birthed the industrial revolution by providing schematics that made possible the production of the machinery of industrialization. A critical aspect of the Renaissance and the eras that followed upon it allowed for the free borrowings from the works of others. Those given to 'copyrighting' their material had little recourse, famed lutanists would hide behind curtains so no one could steal their chops. Bach, Shakespeare and others freely borrowed lines and more from their contemporaries and those who came before them. Bringing this rant to a close it remains to postulate whether the Open Source movement, in multipart harmony, provides a more efficient model for productivity? Well doh!
heuristic algorithm seeks stochastic relationship
The first thing that immediately springs to mind is -- Exactly how many hours did Ingrid bill the day she was so supposedly "productive"?
And the other thing that springs to mind is that her supposed "productivity" was clearly a factor of long experience with the system, and the wit to recognize the similarity of function that led her to the solution.
In the Real World of plug 'n play coders, where no system is worked with for more than a year, system documentation is an obsolete notion (nobody is willing to pay to maintain it), and the concept of spending time to understand the system from the "Big Picture" down to the details is a fantasy, these things just never happen.
"Productivity", indeed!
Why is it that in all these examples, the woman is the one who has the right ideas?
Very similar to commercials were the woman always knows better, has the better deodorant, better car, better detergent, etc.
Blah!
Sometimes I wonder if we have forgotten the true value of "simple is beautiful".
Why make the art of programming such a complex issue?
My personal style of programming is that I break the program down into really small, and really simple parts.
If people think that my approach leads to bloatware, think again.
If you break down your code into small and simple parts, MANY OF THOSE PARTS CAN BE RE-USE !
That is, you don't need to re-invent the wheel.
A no-brainer example:
Let's say, in one part of your program you need to add two numbers. In another part you need to add up three numbers.
You can create two different functions -
one to add two numbers,
and the other one to add three.
Or you can create one function that adds up two numbers,
and then REUSE that function to add up the additional number.
I know the above example is a no-brainer. But by applying the same principle, and RE-USE the code, you may find that your program becomes MORE efficient.
On another note, can anyone recommend any good book on writing beautiful codes? How about those "tricks and tips" books? Care to share the ones which deserve your recommendation?
Muchas Gracias, Señor Edward Snowden !
Stop using line feeds.
Came back to find out the PHB and counterpart had worked out a MSProject timeline and assorted smile-stones. Crossed off everything but "test data due" and "final conversion." Then set about doing it. Called and met with the end customer (how dare I ask the client what they want!) Got yelled at and yelled back. Spent 3 weeks populating a database (MS Access if you need to know) with all the details, reports to customer, exceptions and questions. Many conference calls with the the client.
Not 1 line of code is written after 3 weeks. PHB knows I'll produce but counterpart is beginning to wig.
Came in Friday, wrote VB against the spec database and generated 18,000 lines of code. Wrote 6 subroutines that code-gen routines needed. Wrote MAIN to call things and setup for I/O. Went to lunch and for a nice walk. Came back, submitted test data 2 days early.
No feedback on test data, end client was happy. Tweaked for speed and ran conversion. No fixups.
Progress reporting consisted of adding 5% (20 days) each day.
It's called D
It reads: /* Why did I do this?*/
Which did make it easy to find the bug I was hunting...
Best Slashdot Co
Programs are made up of function points. Programmer productivity should be measured by FPs too. Some are a trivial "if", others are thousands of lines. The end user cares about function points. When I worked at NASA 12 years ago writing space shuttle software, we knew that FPs were it even though our contract required SLOCs.
I will give you a good advice: DO NOT, and I repeat DO NOT use loop statements. They are very bad. Instead use simple and tried copy and paste, paste, paste, paste, paste, paste, paste, paste. You will observe instant productivity boost. You will gain applause of your management, and maybe some day you will became one of them.
Have a happy LOC programming.
I recently downloaded an Open Source program, which I won't name, to evaluate. One of the authors (or maybe just a "promoter") had counted the lines of code, which came out to 96,000. The author then indicated how many developer years were required to write that many lines of code, using common estimating techniques. He was obviously quite proud of the fact that they had accomplished so much. As I noticed that the project had still not reached version 1.0, I just considered this to be an indication of how much time was required before they reached version 1.0, assuming that the code still contained very many bugs, and assuming that they weren't planning to add any additional lines of code.
There's a whole literature on managing software projects. Look up terms like "Software Engineering" and "Software Management". For tracking progress, the usual approach is to divide the project into a series of steps, where each step can be unambiguously determined to be true or not (no "90% done" steps). Estimate the time that's required for each step and use a scheduling program to determine how long it will take; you'll also need separate management reserve time for the inevitable problems (but keep this separate from the steps, so that you'll know when you're using it up). Some people define dollar values for each step, resulting in earned value approaches.
By the way, I've used SLOC to estimate the effort needed to develop one of the GNU/Linux distributions (Red Hat); you can see the results in More than a Gigabuck: Estimating GNU/Linux's Size .
- David A. Wheeler (see my Secure Programming HOWTO)
Lines of code are not a worthless metric, as is sometimes concluded from arguments such as those in the article. I do agree that LOC is questionable as a productivity metric. However, if LOC is considered a cost rather than an asset, then it is a much more useful metric.
For instance, if two people solve the same problem, all else being equal, the one with fewer LOC is likely to be the one that was easier to write and to understand. Barring deliberate obfuscation, higher LOC correlates with complexity and complication. Fewer lines to write, read, and understand make a system more maintainable.
It follows, of course, that LOC should not be a measure of productivity. That would be like judging a contractor based on how many dollars he spends per day.
Of course, code terseness can be taken to extremes, but I think there's an 80-20 rule involved: you can trim the code by 80%, with proportional benefits in conciseness and simplicity, with only 20% of the drawbacks due to terseness and obfuscation. Code could (and should) be much smaller than it is today with no loss of clarity; on the contrary, the clarity would be improved by careful editing and refactoring.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Much of writing software is like writing a user interface for programmers (other programmers or our future self). It can be a good interface or a poor interface. A good "programmer interface" will allow easy reading and changing without unforseen side-effects.
Thus, judging software by lines-of-code is a lot like judging a user interface (non-programmer) by the number of screens and buttons. One should strive to be lean, mean, and clean.
Table-ized A.I.
No, wait... didn't a famous mathematician hang out under an apple tree? Some guy named Newton. Invented a whole new branch of mathematics all by his lonesome called differential calculus.
:)
So, I guess you were wrong. I guess that's the way the apple falls.
"yes, that's right boss. It's a new style called Inline Programming...apparently it's really hot in Europe at the moment..."
I'm managing a software company and we have always been working the "Ingrid way", perhaps it is just a insight from the author to pick a swedish name as we actually do work in sweden!
That more relaxed style is more common here, but no as common I would like it to be.
But as long I will be in charge I will never forget my coding roots, I think I know how to create great code. You really have to create and environment where it is completely ok to hit the soffa and sleep for an hour if that seems like and good idea. One cannot force people to be smart and invent clever stuff...
If a programmer goes to hell, that is probably the kind of code he will be forced to maintain for all eternity.
"First lesson," Jon said. "Stick them with the pointy end."
This is why commercial software is *NEVER* completed. Are there any commercial devlopers out there whose XP manager said, "Sure, refactor the code, take as long as you want"?
Code refactoring (aka UnCut&UnPaste) is an often-skipped yet important development stage. Lines of code should go up during development, and then halted and refactored eliminating duplicate code *reducing* the number of lines of code, then at the end do a super refactor.
My last project was feature complete at 1000 lines, after refactoring it became 400 lines, causing the code to become simple enough to spot a way to improve the algorithm from O(n) to O(nlog(n)), although we charge extra monnnai for the nlog(n) system. Luxuries like adding GUI and usability enhancements become much simpler after a big refactor. Without one you always get software bloat
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?