Code-Rate-o-Matic and Orbital Laser Death Ray

I'm struggling a little bit with how to respond to your idea, Steve, but I do have a couple of raw reactions...

I'm not sure if we're talking about things "the customer" really wants, at least not specifically. Depending on who "the customer" is (an end user? a manager in charge of the end users? a stakeholder who could give a damn about the end users?), what he or she wants could be very different than what some other "customer" would want. To the extent that your question connects to the Apgar discussion, the way I think of it is that the customer wants "good quality." They don't want crap. Yes, the software needs to fulfill the specified requirements, but underneath that what the customer wants is not-crap. A person buying a chair wants a chair that is comfortable, but beyond that they are not thinking about "invisible" things like

When I think of the "score-able attributes" in an Apgar-like software scoring system, I'm thinking mostly of things that are "invisible" to non-technical stakeholders, but which can later come to bite everyone in the ass down the road, just like a chair that breaks after three months of sitting in it because the carpenter/factory/designer made crappy joints. To me the usefulness of the Apgar idea for software is for technical people to judge a piece of software and tell stakeholders whether what they have is a piece of crap or not. This puts the at odds with the obstetrics Apgar, which as others have pointed out, measures things that are obvious to everyone, and not just trained medical personnel.

In imagining a perfect, magical code analysis machine, I'm stuck feeling like science fiction novelist Philip K. Dick, who would only have been able to imagine how something seemingly perfect and magical could be misused and/or flawed, as depicted in the movie adaptations of his stories such as Minority Report, Blade Runner, and Total Recall. This makes it hard to get into the spirit of the exercise as you've suggested it. :-)

If I do try hard to imagine it, though, I don't think I would want to apply such a machine as you've described it to evaluate *people* and how much they contribute to the bottom line--but my reasons for that go back to the reasons why I have trouble imagining such a machine.

Dan

The whole idea cries out for Structuralist analysis.
In the grammar of ALL documents about the evaluation of programmers we find:

(1) The User is always spoken of in the singular

(2) The Programmers are always a collective and spoken of in the plural

THIS IS SIGNIFICANT.

In reality, as I have said again and again, the Users are plural and their needs conflict (furthermore their needs are alienated because they are agents of the firm).

In reality, solitary programmers often do a helluva job because they don't have to play footsie, grab ass, Trivial Pursuit, Staff Meeting, and Who's the Schmuck with "co-workers".

I suppose the extra-cost Laser Death Ray is attached to Steve's contraption in order to nail "nonproducing" programmers. But as I have said, a meaningful job is a human right, and, after a company has done due diligence in hiring a man, the company owes it to him and his family to rectify THEIR mistake if he can't code, by moving him to a slot in which he can produce.

[The "sexist" language is used advisedly: single mothers are smart cookies and can substitute the name of woman if they like, I just don't give a damn anymore. A "man" is someone on whom people depend considered most abstractly, and its high time to honor the poor slobs on who most people depend, slobs with dicks in most cases.]

Furthermore, if your team consists of nothing but Ace Venturas, it can still produce dreck, especially if the user is just kidding about the requirements, which he is in about 50% of all cases.

They aren't the only stakeholders. The EMPLOYEE (as Marx pointed out) gives something, his time, which he can never recoup, as compared to the capitalist who gives only his money, which he can regain by further profitable ventures, or by going to money-lenders with a typical capitalist's credit-worthiness.

Mixed economies that successfully combine socialism and markets in fact implicitly recognize the massive "opportunity costs" that employees AS EMPLOYEES pay, a cost that was in Marx's Capital transcendent-with-respect-to (different in kind and not just in quantity) the money that the capitalist pays.

Considered in the irritatingly teutonic and abstract way of Marx, the employee "as such" gives his life-time to the firm and is given, in a Judas bargain, money in exchange (usually peanuts, but at this level, that's by the way).

Marx refused to acknowledge the universal validity of the equation "time is money" which is a fundamental saw of "the real world".

Note that I cannot express this Great Refusal in the language of economics because Marx is meta-economic. In fact, you have to READ literature to understand it.

In de Maupassant, the young girl works herself to death for years to pay off a debt for a diamond that is not a diamond: even if he didn't realize it, de Maupassant was exposing the falsity of the idea that we get a fair deal when our life's time is equated with a minimum wage job, or 50K per year.

Literature exposes us to the fact that there is no surd way (as in the opposite of absurd) to "map" our life time onto a proper salary.

And literature helps us to understand that if we slave for peanuts, we're cheated, but if we're massively overpaid, there almost always is some piper (workaholism, isolation, stress, marital breakdown) who must be paid.

This is because time isn't money.

This means that the stockholders cannot "buy" the employees but must treat them as equal human beings with full rights to recognition and respect.

American culture is ridden, especially in the Sunbelt, with a nostalgia for slavery: a desire to buy a man's time and make him your slave, with "no rights that a white man need respect", in Chief Justice Roger Taney's words in Dred Scott.

Well, you can pay me anything you like...I am not your slave, and if after due diligence I think your system needs error checking, if only for my own sanity, I think this demand deserves equal recognition and respect.

An effective data system is the product of a conversation among equals: rough consensus and working code.

Those are some excellent points! There are quite a few crappy programmers who can't write a correct line of code to save their lives but they at least know what code needs to be written. Lots of good programmers, myself included, will freely go off into the bushes and solve the wrong problem.

Indeed this magic tool would be blind to detect people who exerted influence over the code but did not actually write it or check it in themselves.

So if you you did decide to install the orbital death ray option, you would throw some wheat out with the chaff. Further, there are plenty of great programmers who, through bad luck or bad politics, end up working on backwater projects.

While I've couched this argument as theoretical, it's by no means out of reach to construct a tool that would approximate how much value is delivered to the customer by each line of code. (All you have to do is get a count of each time a function is used, and by which user, then collate that with amount each user pays to use your system.)

But I can't help but observe that such a tool has not yet been written, even though the technology to do it has been there a while.

I personally conclude that it's because at some level, managers know they can't handle the truth...