Measuring software quality/programmer performance

[chronodekar]

In other words, as a programmer how is performance measured in your office? Are there employers out there who still demand 300 lines of code a day? (made up figure)


In my office, it varies from project to project, but generally, before we start, we have the client approve of a list of test cases and we code to confirm to that list. As the project goes, the list changes, depending on customer feedback etc. But, by the end of the project, a programmer is valued, depending on how his/her code met up to the test-case criteria. (And if the customer left feedback on how they liked the product)

Ideally, well-written code is something that should never be patched. (Feature additions are another matter) But how is code valued DURING the coding phase?

I thought it would be interesting to hear from all the professionals out here how they do it in their work-place. (For any programming students reading this, you could consider it as a glimpse into your future. he,he. )


This thread is what prompted me to make a new one on the matter.

 

[KB]

A programmer in my group is measured by how quickly and efficiently they complete their assigned task, usually a new feature or bug fix, not by line count. For example they may be given 2 days to complete a new form and function and they are measured to make sure it is not taking over the alloted time and to make sure there aren't a ton of bugs.
A good programmer can complete a task in as few lines of code as possible. If you make a line of code per hour requirement you may get a lot of comments and a lot of variable declarations, which is good, but you may also get inefficient algorithms, repeated code and some other bad things. Lines of code however are not directly proportional to quality of code.

 

[Markbnj]

How do you measure the "quality" of the engineers working on a new bridge? You can measure the easy stuff, like whether they know the basics of their craft, turn in their work on time, need a lot of correction and supervision, etc. Anyone who gets past the junior stage passes. When they satisfy all those criteria how do you measure how good the work actually is? For the most part you can only say for sure long after the project is complete.

 

[chronodekar]

Originally posted by: Markbnj
Anyone who gets past the junior stage passes. When they satisfy all those criteria how do you measure how good the work actually is? For the most part you can only say for sure long after the project is complete.

Well, that pretty much winds back to my point of starting this thread. I don't think it's possible to measure product quality until AFTER a project is completed.

BUT, in a corporate setting, for the sake of promotions, salary-hikes, ... etc, it's done anyway. So, I was wondering how different companies go about it?

 

[Drakkon]

My previous company we set the benchmark as how well they dealt with deadlines that they provided (will get this module/class/function done of this date - luckily we had that flexibility) and the quality of code (based on errors that came back) from pieces they built. So a person that told me a week, got it done early, and came back with a ton of errors would be treated equally as a person that had no errors but was a week late on delivery. If they constantly missed deadlines, or constantly had large amounts of errors it would be a problem. The better they got with proving me deadlines that they would meet and less errors would be due for bonuses. It seemed to work as time went on I would be able to time line out entire large scale projects with my team and give a real deadlines to my superiors that we could meet which was a big deal to them.

 

[Apathetic]

That's pretty much how we do things here. Once the design is agreed upon, I'll be asked how long will it take you to write Widget X? My boss will hold me to my estimate. If I continually meet the timeframe(s) and the code works well in production I'll get a good review. The biggiest sin would be to finish code early only to have it crash repeatedly in production.

Dave

Originally posted by: Drakkon
My previous company we set the benchmark as how well they dealt with deadlines that they provided (will get this module/class/function done of this date - luckily we had that flexibility) and the quality of code (based on errors that came back) from pieces they built. So a person that told me a week, got it done early, and came back with a ton of errors would be treated equally as a person that had no errors but was a week late on delivery. If they constantly missed deadlines, or constantly had large amounts of errors it would be a problem. The better they got with proving me deadlines that they would meet and less errors would be due for bonuses. It seemed to work as time went on I would be able to time line out entire large scale projects with my team and give a real deadlines to my superiors that we could meet which was a big deal to them.

 

[degibson]

Originally posted by: Apathetic
That's pretty much how we do things here. Once the design is agreed upon, I'll be asked how long will it take you to write Widget X? My boss will hold me to my estimate. If I continually meet the timeframe(s) and the code works well in production I'll get a good review. The biggiest sin would be to finish code early only to have it crash repeatedly in production.

Call me a Devil's Advocate, but isn't it best to claim everything will take 10x longer than it really will...? Or is your boss also sufficiently technically adept to know what is BS and what is reasonable?

 

[Aikouka]

Deadlines and in a sense, it also tests your ability to sense how long a task will take.

 

[zebano]

All code is peer-reviewed before being checked into source control. At the end of the year we all fill out self-assessments and write short assessments on 1-4 of our peers (as chosen by our manager).

 

[Apathetic]

He's very sharp and if your estimate if very different from his estimate he starts asking a LOT more questions. It also helps that he has a PhD (ABD) in Computer Science and *loves* to eat BSers for lunch.

I have to admit though that this way wouldn't work very well at all if we didn't have a technically comeptent boss.

Dave

Originally posted by: degibson

Originally posted by: Apathetic
That's pretty much how we do things here. Once the design is agreed upon, I'll be asked how long will it take you to write Widget X? My boss will hold me to my estimate. If I continually meet the timeframe(s) and the code works well in production I'll get a good review. The biggiest sin would be to finish code early only to have it crash repeatedly in production.

Call me a Devil's Advocate, but isn't it best to claim everything will take 10x longer than it really will...? Or is your boss also sufficiently technically adept to know what is BS and what is reasonable?

 

[chronodekar]

Originally posted by: Apathetic
I have to admit though that this way wouldn't work very well at all if we didn't have a technically comeptent boss.

Even if your boss was a total technical-inept person, it won't work. Perhaps once or twice. But if you start a pattern where it seems that you finish up your work waaay too early, well, I'd think anyone would start getting suspicious.

If it becomes a habit, you risk the situation where when-ever you give a deadline, your boss expects you to finish it in 1/4th the time, and when you miss that, things are going to get ugly.

Something similar was going on in the initial Star Trek series. You know, the ones with James T. Kirk ? I think the chief engineer (forgot the name) ALWAYS gave a 4 times estimate on timing, and whenever Kirk heard him, he would mentally divide by 4. (Please don't ask me to mention which episode, I don't remember it.)

 

[degibson]

Originally posted by: chronodekar

Originally posted by: Apathetic
I have to admit though that this way wouldn't work very well at all if we didn't have a technically comeptent boss.

Even if your boss was a total technical-inept person, it won't work. Perhaps once or twice. But if you start a pattern where it seems that you finish up your work waaay too early, well, I'd think anyone would start getting suspicious.

Naturally when you finish early you would have to then waste some time to cover your overestimate. It would be more of a safety measure than anything else.

Something similar was going on in the initial Star Trek series. You know, the ones with James T. Kirk ? I think the chief engineer (forgot the name) ALWAYS gave a 4 times estimate on timing, and whenever Kirk heard him, he would mentally divide by 4. (Please don't ask me to mention which episode, I don't remember it.)

Montgomery Scott. And I think it happened any time anything was broken, damaged, or needed modification. He also tried to teach the techniqe to TNG's Geordi LaForge in the episode "Relics".

 

[chronodekar]

Originally posted by: degibson
He also tried to teach the techniqe to TNG's Geordi LaForge in the episode "Relics".

Ah yes, that's the one. Thanks.