Work: "The transfer of energy from one physical system to another, especially the transfer of energy to a body by the application of a force that moves the body in the direction of the force. It is calculated as the product of the force and the distance through which the body moves and is expressed in joules, ergs, and foot-pounds."

Working hard means applying excessive force to move an object over a certain distance. This object can be a software project that needs to be completed in a short timeframe.

Working smart means using RightTools to accomplish the goal.

----

As applied to software projects work is programmers*hours*lines_of_code . Correct me if I am wrong.

You are wrong. It's programmers*hours*lines_of_code_per_man_hour. :)

''I have been to places where it is simply programmers*hours.  Some managers there value programmers who worked-late-but-do-not-deliver more those who delivers-but-do-not-work-late.  Not surprisingly, projects managed by that manager is usually late.''

If you deliver-but-do-not-work-late you should help out the person on your team who worked-late-but-did-not-deliver. You would then both be people who delivered-and-worked-late. 

''That's pure management wishful thinking.  Firstly, programming is not like digging, most of the time you can't just "help out" other teammates whenever you want.  Secondly, do-not-work-late does not automatically mean you have extra energy left to help others.  Working overtime helping others will very probably make you tired enough to add lots of bugs to both programs, making both of you end up worked-late-but-do-not-deliver.  What's worse is some managers prefer the everyone worked-late-regardless-of-who-delivers ("Umm.. you failed, but you did your best!") instead of having some teamates deliver-but-do-not-work-late and some worked-late-but-do-not-deliver. ("Yes, you finished your task on time, but you should have helped joe to finish his task too, you slacker!").''

See PointyHairedBoss

----

''Hmm.  There's something wrong with the above equations.  Folks that don't reuse generate lots of lines of code.  We need another unit of measure.  How about a dollar's worth of contract labor!''

Process vs. Results.  Unfortunately, process seems to win in most shops.

''By definition, good process should yield good results.  I think evaluating results over the short vs. long term is the friction you're encountering.'' 

I would say that the problem is that good '''quality''' of process yields good '''quantity''' of results, but the PHBs only know how to measure quantity.