Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As part of a review of all job descriptions, my company has decided to include the following as a key output:

website development completed on time, within specification and error free

Given that specifications regularly change, there is no formal change control process and environments are, shall we say, a little unpredictable, how realistic and reasonable is this KPI?

share|improve this question
15  
Completely unrealistic. That was probably written by someone who's worked with one too many bad developers. But it could also be the fault of bad management. Not enough information provided. –  Mark Canlas Apr 5 '11 at 20:55
10  
The developer who comes in with "writes error free code" on their resume will be ludicrous enough to match the position. –  P.Brian.Mackey Apr 5 '11 at 20:56
12  
The only code that can be proven to not have any bugs and achieve it's goal is an empty code base that claims to do nothing. –  unholysampler Apr 5 '11 at 21:25
8  
pfft... looks like a scapegoat clause to can people easily. "Sorry, you didn't live up to your employment agreement... we're going to fire you without notice or additional cause. Tootles." –  Steve Evers Apr 5 '11 at 21:44
3  
Of course it's error free. The compiler says: 0 errors, 0 warnings. That completely fulfills the job requirements :-) –  Ferruccio Apr 5 '11 at 23:14
show 7 more comments

15 Answers

up vote 19 down vote accepted

"Error Free" is far too subjective. One man's "Unfufilled feature request" is another man's "Error". Something like "Should substantially meet design specs" would be more appropriate. I've never actually seen what you describe in a job description. I've seen it for contract work, but not for employees.

share|improve this answer
7  
+1 - Love the "Unfulfilled feature request" comment. –  P.Brian.Mackey Apr 5 '11 at 21:12
add comment

I'll take an opposing position to most answers and say it's absolutely reasonable and realistic.

Will all development be completed on time? Of course it won't, not always.

Will all development be completed within specification? You'd like to hope so, but sometimes that will simply not be possible and you'll have to flag a deviation from an impossible or self-contradictory spec.

And will all development be error free? Never.

But that's what a KPI is for. It's something that can be measured and by which you can track performance and progress.

If specifications regularly change, there is no formal change control process and environments are unpredictable, then it will be a challenge to keep this figure close to "error free". But that challenge is your job, and it's a job which you will hopefully do quite well - and even better next year, as you get more practice at managing your company's own particular flavour of chaos.

Counter question: what KPIs would you propose for a programmer? It's a tough one. A lot of what we do is hard to measure.

share|improve this answer
4  
A code base of any significant size is practically impossible to guarantee as "error free", because there could be an error that you simply haven't found. Also, what's an error? A bug? How is this measured? –  philosodad Apr 5 '11 at 21:35
1  
@philosodad - that's kinda my point. It will not be error free. But if this year x errors are found in code you wrote, and next year x-4 are, you've improved on your KPI. As to what an error is, that's really a matter for your organization, and no doubt one that will cause some arguments re "error" vs. "undocumented requirement" vs. "changed requirement" vs. "difference of opinion". –  Carson63000 Apr 6 '11 at 0:47
3  
@Carson63000: but that's my point! A KPI that is guaranteed to cause several arguments, lead to inevitable disagreements among parties, and vaguely defines a key metric is, at the very least, problematic. To take your example, if an "error" is a subjective measure, it is predictable that managers will define errors down to make themselves look better, so everyone will have a reduced error rate for the exact same performance. But a new manager might define it up, and then down, to show how they "improved" the same exact output. –  philosodad Apr 6 '11 at 3:51
3  
It would be preferable to have a target of no critical errors (define critical). Or to have an improving error rate. And even better, this stuff should be targets for annual performance appraisal, not part of a job description. –  quickly_now Apr 6 '11 at 4:50
3  
KPI's involve a target that can not only be not quite met but can also be exceeded. You use it to measure whehter you are doing worse or better than the KPI target. I don't see how "error free" can be exceeded. Therefore, even if intended as a KPI it is flawed. A better KPI would be to measure the number of faults, test reports submitted against code you have written that resulted in actual code changes, etc. –  Marjan Venema Apr 6 '11 at 6:01
show 1 more comment

If it is a job description, then I wouldn't worry too much about it since working towards error free code is part of a typical programmer's job (even if we can never achieve it).

However, as a KPI it is too far reaching, but don't blame the person who suggested it if they aren't programmers. Just explain that that statement sets a goal that might be undesirable for the organization. That is, "error free" is an extremely high standard for software that would cost a fortune to actually deliver. Explain that a well run software project requires decisions to be made about whether each defect is worth spending valuable developer time on.

Here's an example that makes the point nicely.
A programmer discovers that our software has a "year 3000" bug and will cease to function after Dec 31,2999. It will take 6-8 months to fix the problem. Based on the KPI is encouraged to take on this project despite having no real value to the company.

Okay, so that example is a little extreme, but in any software project there will be literally dozens of little defects discovered that similarly don't generate the ROI required to fix them. If the KPI was instead intended to imply that the programmer never introduce the defect in the first place, does it seem reasonable for ANY employee to be held to the standard of never making a mistake in the performance of their job?

share|improve this answer
    
It seems unlikely that you'd have a KPI which covered "fixing defects which have been deemed by management not to be a problem, and not to need fixing." –  Carson63000 Apr 6 '11 at 0:48
    
@Carson - not in some big companies I know of. Silly goals is part of their way of doing business. –  quickly_now Apr 6 '11 at 4:51
add comment

Sadly this just sounds like a way for them to "cover all the bases", and is clearly not recommended and is likely to just engender disillusionment in the developers.

However having said that, this really only matters once you see what they do with that text during the review period. So don't overreact too quickly - there might still be sanity at the end of the tunnel.

share|improve this answer
    
Given my current work environment, I'd be very suspicious of how they'd apply that wording. –  Phil.Wheeler Apr 5 '11 at 21:14
add comment

Am I being stupid, or does "error" not mean "fatal compiler message amounting to non-compilable code"?

By that definition, it's a very reasonable requirement...

share|improve this answer
1  
True. Having misaligned text on a page footer might be an error but it is certainly not in the same class of error as something that prevents a page to fail to load and spits runtime errors back to the user. –  FrustratedWithFormsDesigner Apr 5 '11 at 21:19
add comment

No

Not only is it not appropriate, it is ludicrous

Testing can only prove the existence of errors, not their absence, so every program written under this engagement would have to include a rigorous proof of correctness...and 100% test coverage

"Beware of bugs in the above code; I have only proved it correct, not tried it." -- D. Knuth
share|improve this answer
    
KPIs are a measurement of success and progress towards a goal. They're not a binary toggle "error-free code = success, one single error = failure, you're fired!" –  Carson63000 Apr 6 '11 at 0:50
    
@Carson: "error-free" is not a KPI, it's a fantasy. –  Steven A. Lowe Apr 6 '11 at 2:04
1  
Sounds to me like a stitch-up. Put in something silly in the JD then whenever an excuse is needed the person can be fired because they are not performing as the JD requires. –  quickly_now Apr 6 '11 at 4:53
add comment

Of course it is every programmer's job, and responsibility, to write code that is error free. That's a perfectly reasonable expectation. How can you be a professional programmer if you release code that doesn't work? How can you consider yourself to be a professional programmer if you release code that you don't know works?

If you hire a painter you expect him to do his job well. You expect the result of his work to be error free. If there are errors, you expect him to take responsibility for those errors and fix them free of charge. What's more, if the errors cost you money, you expect him to reimburse you. Why do you have these expectations? Because the painter is a professional.

Programmers love to blame everyone else for their errors. "My program has bugs because of the requirements, or because of the schedule, or because the Moon is in the 8th house" But there's really no one else to blame. If your program has errors, you put them there.

Our profession will never be a profession until programmers realize that the buck stops with them. That they are responsible for the quality of their programs.

Do you know why companies created Software QA departments? Because programmers weren't doing their jobs! Programmers were releasing so much crap that companies had to form whole new departments to check up on them.

How long is the bug list? It is professional to have thousands of bugs in the bug database? Quite clearly it's not. It's a reflection of bad behavior, poor discipline, and, frankly, dishonor.

We will never be a profession until we realize that is it our job to make sure that QA finds nothing.

share|improve this answer
    
+1, but I'd like to think of error free as a personal goal rather than reality. We should all go for it but unless given endless resources we won't get there, at least not given how we develop software now. –  Cwan Apr 6 '11 at 6:46
    
I could not agree more strongly with Uncle Bob's sentiments. It's very much a question of professionalism. –  Johnsyweb Apr 6 '11 at 9:37
1  
This position is complicated slightly by the fact that my management is absolutely clear that they would prefer me to give them buggy software now, rather than correct software later. I do not think i am alone in being in this situation. –  Tom Anderson Jun 9 '11 at 16:09
add comment

Hire me! My code will be error-free given an infinitely large time frame.

If the time frame is constrained, the code will have to contain errors. The less is the time between assigning a task and a deadline, the less "error-free" will my code be.

share|improve this answer
add comment

"Error-free" as in "perfect?" As in "written by God and the angels, not humans?" (we're speaking here of program-logic and maybe hardware-logic errors)

I can't say truthfully about even one single line of code that it is without error. That's because us humans, well, we can't prove no negative hypotheses!

The best I can say is that the probability of an error is a number between 0 and 1. I reach that number by way of well- or ill-defined and well- or ill-understood software development and testing principles; by a count of the source software lines in question; by an understanding of how well or poorly I candidate, poor mutt, applies those principles in producing those lines of code; and more.

And I can express that understanding only as a probability. So the term "logic-error-free" means close to nothing.

If I saw an ad for a software engineer who produced "error-free" code I'd either apply right away or I'd run right away: the company hasn't thought much about how it develops, tests, and delivers its software. So it'll be either a great opportunity or an endless nightmare.

Of any software, though, I can easily -- and must -- say I expect code that has no errors that fall outside that sucky, murky, logic-ey stuff: code that compiles and links without errors or warnings; that is "valid html" or "valid css"; JavaScript (say) that generates no unexplained error messages or browser faults. That part I can measure straightforwardly and mark in black and white on a graph.

That part's easy as pie. Anybody can do that.

Hey, good luck in your search :-)

share|improve this answer
add comment

It means the job description was written by someone in HR, not a programmer.

share|improve this answer
add comment

marketing people are fanastic, they clearly don't live in reality. Name an industry which claims they have 100% no-defect record. Programming isn't a science, its still an art. Its a means of expressing a solution to a given problem, to the understanding and knowledge of the programmer.

share|improve this answer
add comment

No one expects them to actually require 100% of what is listed on a job post, so they probably only mean 75% error free. Anyone remember the post that suggested this?

share|improve this answer
add comment

Sounds like a rule that was likely born when someone consistently delivered error-prone code - to the point where the managers involved felt compelled to express their frustration as a general rule that 'everyone must satisfy' rather than dealing with the employee directly.

Most procedures, rules or laws are created to solve specific problems with degenerate individual behaviors.

share|improve this answer
add comment

Only if you don't want to hire anyone smart enough to realize that this is an impossible requirement.

Not to mention, contractors who have been burned by a client before (which is almost all of them) are going to be extremely suspicious. I certainly would be.

share|improve this answer
add comment

My concern about having such a thing in a job description or KPI is that it is an impossible goal. Thus, it is something that can be easily used against you and it is much harder for you to use it to your benefit.

In other words, job descriptions and KPIs should be realistic, even if they are high goals ones must aspire to reach.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.