Apgar score: less than zero
(Editor's note: see this blog post for the beginning of the discussion of an Apgar score for software.)
"The division of the world into important and unimportant matters, which has always served to neutralize the key phenomena of social injustice as mere exceptions, should be followed up to the point where it is convicted of its own untruth. The division which makes everything objects must itself become an object of thought, instead of guiding it."
The doctor can start with observations of the patient that are more or less objective, although even in medical science, the observation of the patient factors out the patient's reaction.
The problem in MIS development is that the starting point is not objective, consisting instead of texts which are a mixture of honesty and obfuscation, and the interests of a subset of the real stakeholders.
For example, Apress author statements were a surprise simply because they provided enough information so that the author could spot a contradiction, and could "crossfoot" the amounts. This was a surprise because most statements, whether for author's royalties or utility bills, are not in this way self-checking, so that a billing error does not appear as a failure to crossfoot.
This occurs because in modern MIS shops, each line of code emitted by the programmers is reified and measured, and the ability to judge whether a feature is needed has been taken away. In some exceptionally tight ships it is a termination offense to write a single line of code or an Easter Egg that can't be "justified" by a business rule, whether or not the business rules (in turn cost-justified exclusively from the standpoint of profitability and, perhaps, following the letter of applicable law) serve all the stakeholders in the system.
Suppose a programmer, reading a "reinsurance" data base for doing accounting for insurance firms that insure other insurance companies against large claims and creating a distinct object for each distinct policy (which lists 1..n other policies it ensures) worries about direct or indirect "loops" in the policy network, such that policy A insures policy B down to policy D, which lists and insures...policy A.
This may occur in Hong Kong and other financial centers with intent to defraud, by arbitraging insurance policies with these loops as secret bombs, where the abitrageur gets paid for an uncollectable policy. In a fictional short story called HOUSE OF CARDS, Hong Kong writer Peter Gregoire in fact describes just such a scheme from the viewpoint, not of the programmer but of a scheming arbitrageur (in SWEAT AND THE CITY, Stories and Poems from the Hong Kong Workplace, Hong Kong Writer's Circle 2006).
The reinsurance programmer would probably be instructed to simply call the module for the start policy, and then enumerate through the first level of policies insured, recursively calling the starter module for each policy to price or otherwise process that starter policy.
However, his program will "loop" if a policy contains a direct or indirect reference to itself, since the data base NEED NOT BE INFINITE for an infinite loop to occur: this is because each policy appears to the module as an object reference in the heap, and there of course can exist multiple such references to one object.
I encountered this in building a software tool that analyzed module references by iterating through the tree structure of a build. My solution was to create a collection of found references as I processed the reference tree, obtaining quick rather than linearly slow access to the collection by replacing a linear search (which, in VB, used IS to detect object identity) by a keyed reference using object instance names which I sequenced and controlled from the constructor of the object itself.
The reinsurance programmer could probably use policy number to quickly check for a loop, whether direct or indirect.
But consider the situation of the programmer in a reinsurance company where the possibility of a cycle has not been considered.
We assume that people who work in such companies and wear sober suits would know about this problem and specify a check in the business rules, but in today's world, this assumption cannot be maintained!
Many people in business are simply unable to "think like a programmer" (eg., systematically in a way which is only human as in homo sapiens), and they cover up what should be a shameful fact by pretending to a passionate knowledge of life and people which they simply do not have over and above the shrewdness of the street, and office gossip. Typically, working on "the requirements" they will in fact probably miss this possibility since it demands a MATHEMATICAL insight into what constitutes a tree of references (which are all distinct nodes and therefore distinct, forming a proper tree) versus what is a graph with cycles, which from the viewpoint of the code is what you have as soon as a reference to the same object occurs in the tree.
And, Peter Gregoire's story raises the interesting point that in Hong Kong and other world financial centers, employees and managers of reinsurance firms are doing deals on the side which in fact, rely on the program seizing up when there is a loop.
Both sets of "users" can get a clever, and surplus-conscientious, programmer fired.
The business "vision thing" remains that the programmers will as automatons NOT "think for themselves" UNLESS they find some clever way of increasing profits.
Now, I do not know in the case of reinsurance whether regulatory boards require such a check, but Peter Gregoire's story seems to be a *roman a clef*, a writer with a day job writing about the finagling and shenanigans he knows.
I do know that when I worked on Cobol reinsurance, the original author used a fixed array in place of a stack for the processing, which limited the customer to only a few levels of reinsurance, and the array had to be continually rebounded. I do know that one of the programmers on this "software maintenance" project, one day, said "I got into computers to explore space and make the blind see: why am I working on this crap?"
There is in this data smog simply no verifiable, observable set of facts such as whether the poor little tyke is pink or blue.
Instead, the ultimate quality of a data system has to involve the legitimate needs of all of its users, not just its contribution to the "bottom line": in my reinsurance case study, the actual managers of the firm were arbitraging reinsurance on the side, and selling ever more complex policies to each other, and they didn't care about the bottom line; yet, they were self-appointed Users whose word, as far as Mere Programmers were concerned, was law.
Programmers want, desperately, to be considered as scientists serving some vision of the truth: are we not men? However, absent a guildlike organization of the profession, which is a non-starter in a world where the consumer rules, any social untruth, such as the failure to anticipate and prevent what would necessarily be an infinite loop in a reinsurance application, means that the programmer is instead using the network to defraud.
He can of course remove himself from liability, but he still has to live with himself.
For Adorno, in the quote from Minima Moralia with which I started this essay, the key was the division of the world into an agenda...of what is important "today" and what is unimportant and may be postponed, perhaps forever.
In cases where a manager doing arbitrage on the side didn't forbid the "feature", code to check for a loop would in most MIS shops fall into the famous categories of bells and of whistles, which is a convenient category for people who unlike real programmers get a headache when they think.
Adorno names the inferior, castaway term in "the division", social injustice. In fact, the media is a binary sorting tool "for winners only": losers, and geeks, need not apply for anything but a supporting role, and their concerns are always a detour and frolic.
Part of the "chaos" of the 1960s in France, and elsewhere, was the phenomenon of mere coders and cameramen and techs redescribing their daily work in political terms, and demanding, in Paris, some say in this direction. An early book on data processing I used to own describes a manager sitting down with everyone in the company to make sure his system would be accepted: such scenes are the exception and not the rule.
Anything is better than the sick powerlessness many nice, liberal, Kerry-voting, white wine swilling programmers must feel when they learn that Air America is going off the air because Microsoft has directed traffic managers not to place its ads with AA.
For while some programmers are fat thugs, most are NPR-listening and vaguely liberal, vaguely critical of what passes for political talk on hate radio. But a firewall exists between their political life and their all-consuming 16 hour day.
To connect "unrelated" issues is a disturbance because it raises the possibility that "George Bush" is no more the problem than "Richard Nixon" was in 1972. It was clear enough to me in 1972 that "Nixon" was part of the *zeitgeist*, not of course of the fashionable crowd, but of the men and women who made society go by getting up, like my Nixonian father, and going to work every day.
Likewise Bush perfectly expresses a more contemporary zenophobia...a generalized zenophobia that is terrified by slippage off topic, even a subroutine call from which our mental stack can guarantee return. An incuriosity correlated with hyperfocus on today's bullets, coupled with an acceptance, an almost infantile and regressive trust, that the PowerPoint has in actuality anything to do with reality "out there", the very notion of "out there" being in play at least until "human voices woke us, and we drowned" on September 11.
In GROUND ZERO, French theorist Paul Virilio questions the entire basis of many programmer's lives, which is based on assigning a hard cash value to "information", something which we can score as we do a baby's health.
But the baby is among other things a creature with rights and claims against all other creatures and things in the world, in a sense an "instance" of the class "human being" whose methods, in my OO terminology, exhibit a certain moral grammar.
For the physician, this pre-organizes the raw observables: trivially, the uterine cord is not included in the Apgar score.
Whereas any MIS system is in reality a relational set of human practices and procedures embedded in human relationships...such as misusing a field labeled "family member" to enter a business reference when the employee has no next of kin who is not a psycho abusive lunatic.
No clear boundary exists between the data system, the code, and everyday life. For example, Oracle can produce metrics that show that Oracle is better than SAP, but so can SAP produce its own metric. Oracle users in good faith laud its standard SQL and decry SAP as a sort of Kool-Ade in which SAP users have to be carefully trained in what is a far more complex, almost proprietary-complex, product. And guess what: if you talk to Steve Ballmer, SQL Server is better than either because its Total Cost of Ownership is low.
No conceivable "Apgar" score could ever resolve this three-way Budweiser challenge: this spaghetti western *paredon* between the Good, the Bad, and the Ugly (we cannot even decide into what slot SAP, Oracle and SQL Server belong in the spaghetti western).
This is because in a well run shop, the users are more productive in the system they know, and they've long ago been permitted to workaround its flaws. We talk of "the human interface" as if it may be separated, but absent this interface there is nothing at all, merely code running until the power runs out.
Shortly after Sep 11, "Microserfs" author Douglas Coupland wrote a fantasy about life after the death of human, animal, and plant life, a world in which software code randomly directed containerships and oil rigs in actions without meaning until the power gave out.
The thrilling conclusion is that a computerized society should in fact be run by people who know the difference between a tree and a graph, but who also know literature and law.
Tim Berners-Lee has been speculating about this too...but all too typical for you young whippersnappers, he wants "teams" of techs and scientists and philosophers to work together on the epistemology of the Internet.
The miserable record of "teams" unguided by a Chief Programmer, a J. Robert Oppenheimer should assure us that Berners-Lee's teams will accomplish nothing, since they will exhaust themselves in playing footsie and grabass.
But "in the matter of J. Robert Oppenheimer", the deliberate and malicious sacking of the inventor of the atom bomb for "being off topic" and suggesting political solutions in addition to scientific solutions, American society made it clear that it expected to be able to use high technology for its former ends of power and control by the wealthy. The result is George Bush, whose amorality, aliteracy, and incuriosity are music to our ears, because it whispers into the collective ear that it's same shit, different day, and we can just sit back, do our narrow jobs, and relax.
The problem: if the manager
The problem: if the manager wants the check on cycles, it's "good": if not, it's "bad".
This means that we can, by widening focus, subject the business rules to an Apgar score: requirements that call for the check have a higher score.
However, MIS managers reserve the right to ignore, or modify, the Apgar score by selecting a subset of requirements based on the expectation that a smaller, weaker set of rules can create a usable system faster.
The Apgar score is modified by a time factor, such that a full-featured system has a lower net score than a system with the "important" features that can be completed faster is "better".
OK, this seems fine, doesn't it.
The trouble is it is not fine.
The human infant's health is allowed to be unbounded whereas the health of the MIS system is always bounded by fear that a too-healthy system will take too long.
The length of time a system takes is not a property of the system.
Systems are thus "ripped untimely from their mother's womb", "deform'd, unfinished, scarce half made up" in a necessarily clumsy effort to increase the net Apgar score because a healthy system, that took "too long" as measured by the time value of money (rationally) and the fears of powerful stakeholders.
A human being is scoreable by nurses and by techs because we don't consider the costs in producing a human being, not because the human being has a high quantitative value but because the human being has an infinite (not Compareable) value.
I conclude that we cannot "score" a data system because it is irreducibly a network of human relations among its developers and its stakeholders.
Famously Frederick R Brooks said that assigning nine women to producing a baby doesn't reduce the time it takes, to produce a baby.
The very idea of parenting a child has in other words a syntax and is a relationship, all the way down, between human beings: the mother, the father, the child, and the delivery room team.
Delivering a data system is a relation also among people but in a free-market system some of those people have to subordinate their needs and insights to those of others. This usually "works", but the subordination always extracts a cost which the subaltern necessarily seeks to redress by the detour and frolic.
A toxic cynicism necessarily (not statistically) results.
Score usage
Again, I find it difficult to disagree with anything you said. So why do I continue the debate? Well, I guess it's because I think there are still points worth discussing.
While it's true that management can put whatever scoring system into place they want, that is only an extension of the simple fact that anybody can score anything however they choose. Quite frankly, management is free to score me however they want. If I don't like the scoring system and it's effects, then I'll move on. As my father continually reminded me, I was looking for a job when I found this one--and if there's one skill I claim mastery over, it's finding that next job.
I think that it's critical for the programming community to discuss the issues that you raise. But I think the programming community also needs a way to quickly and accurately assess the 'health' of code independently of those issues. If the application has been "ripped untimely from the mother's womb", the programmer's equivalent of Apgar, applied rigidly to the code, without modification or waffling, will reflect that.
More importantly, having an industry-recognized and -accepted scoring system of this nature gives the people who do care about their work something to keep on the table. Since nobody likes to do shoddy work, this will have the effect of discouraging programmers from hanging around the sweatshops. If the score is useful, it will correlate with the 'health' of the code and 'healthy' code is easier to care for than unhealthy code, which translates at least indirectly to a business expense. I can see how this scoring system might be the thin edge of a wedge used to raise the overall quality of programs (and this time I don't put "quality" in quotes and use the word "program" instead of "code", because I'm of the opinion that by any measure things will get better).
If the scoring system is something that only another programmer can apply, then it probably has little value. If, on the hand, anybody with minimal training can apply the score, then management can independently verify the results. Once we have things in that state, management's natural tendency to control us will cause them to reward or punish us based on the score. And that is exactly what we want to happen, because it means that they will be demanding that we do the job to the best of our ability instead of just spitting out another piece of junk.
Ron Echoes My Thoughts
Edward, thanks for your contribution to this discussion. In your response to Ron, especially, you hit on some key points, and I don't wish to gloss over the issues you point out. But like Ron, your concerns do not persuade me that this is a futile task. If I have it right, this appears to be the bottom line for you:
However, MIS managers reserve the right to ignore, or modify, the Apgar score by selecting a subset of requirements based on the expectation that a smaller, weaker set of rules can create a usable system faster. ... I conclude that we cannot "score" a data system because it is irreducibly a network of human relations among its developers and its stakeholders.
Your characterization of the opposing priorities of managers and programmers (expediency vs. "quality," respectively) is dead-on, but I agree with Ron's response:
I think that it's critical for the programming community to discuss the issues that you raise. But I think the programming community also needs a way to quickly and accurately assess the 'health' of code independently of those issues.
Ron, I do, however, depart from your thinking here:
If the scoring system is something that only another programmer can apply, then it probably has little value. If, on the hand, anybody with minimal training can apply the score, then management can independently verify the results.
Perhaps this points to a difference in our conceptions of what traits of the system are being scored. If the traits, as I have generally assumed, are primarily "internal" traits, then the score will be difficult for non-programmers to asses. For example, if a fat client GUI program had a score-able trait of "+1 point if the business and presentation logic are separated," then how would a non-programmer be able to judge?
But perhaps you were thinking that the score-able traits would primarily be "external?"
I'm with you on this:
Once we have things in that state, management's natural tendency to control us will cause them to reward or punish us based on the score. And that is exactly what we want to happen, because it means that they will be demanding that we do the job to the best of our ability instead of just spitting out another piece of junk.
I think a healthy shop would have a happy medium in which management encourages the team to achieve a good score and programmers want to do so regardless, and may even do so in spite of a lack of direction from management.
Getting back to Edward's point about the possibility for management abuse (if that's a fair characterization), I take a more optimistic view: that managers who are largely ignorant of "internal" technical matters of a program, who don't understand the intrinsic value of things like exception handling schemes and logging, will have a tool to enable communication with the technical team. The manager may not understand what goes into the score, but if there is a general impression that the score is something important, then he or she may be more likely to not only approve things like exception handling and logging, but may even ask for them. Even if the manager does not truly understand what he or she is asking for, he or she will know that it's a factor in the score so it must be important.
Maybe as a way to allow from some requirements-oriented subjectivity, there can be a minimum score + bonus points for program traits that are less essential.
Best,
Dan
Scorable by non-programmers
Daniel, you make an excellent point regarding what kinds of things make good scoring points relative to the skill required to perform the scoring.
This could be a reflection of my background (I'm basically a paid hobbyist with no formal training), but as soon as Apgar was suggested as a possible model, I envisioned a collection of attributes that a non-programmer could use to score code. If the training burden can be kept low while still maintaining an adequate correlation to 'good code', then we'd get better buy-in from our managers. Let's face it, most of them already don't understand what we do, so setting up a scoring system that they can't personally utilize will have no value to them, thus reducing the likelihood of acceptance.
If we end up with 5-10 simplistic yes/no attributes, each one of which is normally found only in conjunction with other more complex, yet desirable attributes, then a white-paper or a 1 day seminar might be enough to transform the industry.
Having said all that, I have to admit that I simply don't know how to even approach the problem. But I'd also like to stress that the Apgar Score is what was suggested as a model and I haven't seen anything to suggest that it requires several years of experience backed up by a university degree. Maybe our Apgar-equivalent must be more difficult to apply because of the difficult nature of the problem. But maybe not.
Internal vs External
I forgot to address the issue of internal (i.e. code) inspection versus external (i.e. program) inspection.
I see no way to avoid internal inspection and that is at odds with Apgar's external inspection. However, I think that there may be attributes of the code which are both transparently simple to inspect, even by non-programmers, and which correlate well with those aspcects of the software design and implementation that are just so much gobbledegook to a non-programmer.
The user's perspective is important
For example, I give Symantec "Internet protection" a low score because it starts up slowly, and if started up more than once, it hangs.
However, the user's perspective, unmodified by any deeper, professional perspective, will let, IMO, too many unethical and incompetent systems past the gate.
Why can't the two perspectives be combined? Data systems are not the human body. Perhaps what you want does not exist.
If the interests of programmers as programmers, and managers as managers, are in any way opposed, then they will not be able to agree on a scoring system.
Perhaps both the fabrication and evaluation of a data system are irreducibly a new form of "the humanities" in which no judgement can ever be final, and all judgements are texts...not numbers.
Maybe it can't be done
Maybe the two perspectives can be combined. Perhaps neither of us can ever be truly satisifed with what's possible. Discovering what can and cannot be achieved is part of why I bother to participate in the debate at all.
I know that I'm guilty of stretching the analogy with Apgar. And probably beyond the breaking point. Being aware of that is making me think more deeply about the issue and focussing more attention on the problem and less on the model.
If I recall correctly, you have made comparisons between the code and literature. As I consider the issues that you raise and cast about for other ways to judge what I produce, I wonder what we can learn from how writing--especially technical writing--is judged. There are measures of readability (length of words, sentences, and words; spelling and grammar; organisational structure, etc.) that are separate from issues relating to captivating text and technical merit.
Code is not technical writing--well, it some sense I guess it is--and data systems are not the human body. They need their own quality detection systems. They all have various quality measures, and what you choose to measure may depend on the circumstances.
I see that the problem is much harder that I first hoped, but then that seems to be pretty much a normal situation.
Code evaluation
I recommend that you think further about the fact that a software system, as a tree (a graph without cycles) or even a full graph, can never without loss of signal be "projected" on a one dimensional scale, the scale used to "score" a data system.
To write good code evaluation tools, we need good, public domain, object-oriented parsers that can be called by the actual tools, since "simpler" tools that apply regular expressions to code are so often fooled.
As to the literary evaluation of a software system. Note that a court decision is a species of literature. Good court decisions, such as Brown v the Board of Education, which in 1954 announced the impossibility of maintaining two systems in perfect synchronicity with a just apportionment in both (something that should appeal to a broad engineering mentality) lie well on the page.
Bad court decisions like Dred Scott have to announce as a moral rule by fiat that "a black man has no rights a white man need respect" and in fact are "creative" in the way conservative legal observers charge that liberal court decisions are overly "creative": Earl Warren derived the Brown reasoning from our common sense, that if you run two different education systems for whites and blacks, some party will get the short end of the stick (because you cannot synchronize the operations of the two without appointing a super authority over both, resulting paradoxically in ONE system)...and gee I wonder who will get the short end.
Segregation wanted the final apportionment between white and black school systems to occur "out there" in the woodshed with no government authority, and Warren reasoned that you don't ONLY violate the 14th amendment by actively discriminating but also by passively allowing people's racist feelings to control what's given to each of the systems.
Whereas in Dred Scott Justice Taney had to announce on behalf of white men whose rights they need respect, which brutally overrode the power of Northern, Abolitionist white men to choose their moral code, and 'suade others to it.
The syntax cannot be separated from the semantics, nor the semantics from the logic.
Likewise, I'm afraid that my call for a literary, written evaluation of a data system would necessarily be too "liberal" for many conservative MIS managers, for it would I'm afraid expand to include the experience of stakeholders other than owners...there being no reason, absent just assuming there is, to restrict my set of stakeholders to managers and shareholders.
Note in this connection that at SEI Information Technology in Chicago in 1979, I was directed upon being hired to write a detailed status report every week.
But as the company evolved and devolved under the pressures of recession and the oil crisis of the times, I found that increasingly, my status reports were being "reviewed" and "edited" to death.
The folks in the central office, having to please a Fearless Leader and owner who was basically a techie and contemptuous of most of his hires, claimed they were protecting me against his wrath, which, it appeared, was based on a regular expression processor in the Fearless Leader's head that would be activated, not by anything like a close read of the status report (he being one of those busy busy men whose time is so very very valuable), but by strings of nouns separated by ignored, wild card verbs and adjectives.
I was literally told that he might pick up one of my dangerously unedited status reports and stop reading after a couple of lines, picking up the phone to fire someone, maybe me or maybe my boss.
The game was Stalinist. A Russian friend tells me of his father's adventures as an engineer in Stalin's Russia, and his immediate supervisor found my friend's father a headache, not because he was a slacker or "wrecker" but because he would naively construct wordy texts on the job, thereby increasing the statistical probability of attracting the attention of the Cheka or KGB.
Interestingly, the game continues in circles not thought to be Stalinist. As Ari Fleischer said in 2003, "people need to watch what they say", and it appears to me that the same sort of editing of midlevel reports flowing upward occured in the runup to the Iraq War, significantly damaging the input given to Bush by his own design, since he didn't want to have to deal with contraindications to his grand plan.
I'm afraid, for example, that a literary assessment of the effort which apparently occured when First Chicago Bank was bought out by Bank One would have to mention that oh by the way ATM users could not withdraw 100.00 weeks after the changeover because the software "thought" 100.00 not divisible by 20.
The problem is that this, under "employment at will", would get the exhausted programmer, who miscoded the business rule because he was working 20 hours a day, canned. The wider issue is that from Chicago to Hong Kong, banks treat their little customers, the sort of people who made First Chicago and Hong Kong Shanghai Bank into powerhouses, like s*t, and the business rules are biased AGAINST the chump who can only withdraw 100.00 because his balance is 105.76.
We use scoring to protect ourselves in hopes that our lines of code or Apgar score will foreclose a closer audit.
Why is management free?
Since 1980, management has been free to do what it wants. We have learned to say in reply that in a free market we are free to move on.
In the Hobbesian sense (in which the distinction between normative/prescriptive and descriptive is ignored), management is free not only to do anything it wants inside the law, it is also free to do anything outside the law as long as it can "get away with it", as in the case where companies deliberately violate environmental laws, and then pay thousands of dollars in fines cheerfully because their cost accountants have shown them that the violation contributes millions of dollars to the bottom line.
Hobbes, in Leviathan, was thinking without assuming that moral strictures had been established as the goalposts and limits of corporate, state or individual conduct. His sense of "can" meant NEITHER "should" nor "could": it meant BOTH.
He *naturalized* morality for the very good reason that when we make choices, our decision procedures take into account, simultaneously, what we are physically able to do, how it is we will stay out of intimate or legal trouble, what we "should" do to avoid incurring G-d's anger, and finally what is right and what is wrong.
Kant, later on, restricted moral choice to the last procedure: Hobbes, by way of building his argument, did not.
And, Hobbes came to some thrilling, counterintuitive conclusions. The criminal in the dock condemned to hang has no further duty to the state and may make a run for it in Hobbes' naturalistic morality. But the State has the reciprocal right to not only nail him, but also to hang and flog other chaps pretty much at will. Hobbes' legal theory was strangely akin to traditional Chinese codes in which "respect for law" meant an absolute respect for the freedom of law to chop your head off.
But the Chinese thinkers did not balance this fearful respect with a corresponding of individual, or even wholesale, revolution, as did Hobbes. An implication of Hobbes is that a successful chieftain or warlord, say Fidel Castro in the mountains of Nuestra Madre, has precisely the same naturalized moral legitimacy as does the fellow in the presidential palace, and in Hobbes, the greater legitimacy is through a (hopefully rare) passage of arms, followed by totalitarian gun control under the new Mandate of Heaven: the new Leviathan, Milton's great sea-beast.
American management is essentially Hobbesian. It was delegated ownership rights, as John Kenneth Galbraith details, by capital because after WWI, too many Americans were questioning the nexus between ownership, and the sort of neofeudal rights that were being asserted by old fashioned bigod owners like John D. Rockefeller, who'd become ducal rulers in company towns by WWI.
Management became a shock absorber.
But it still acts under the rose in its own self-interest. Sure, the individual manager may also be a majority stockholder, but, many managers are not, and in the case of Enron, the managers were busy at the end of Enron in transforming themselves BACK from stock owners to pure or *reinen* managers...letting the ordinary saps, the little no-account programmers and network admins of Enron, to become part owners precisely at the point where THEY, and not Skilling, Lay, or the anonymous big investors, could take the punishment that capitalism administrates unto failures.
The theodicy asserts that because the capitalist, the owner in whole or in share, takes such a risk of being plunged into Queer street, he should receive a double gift for his success in avoiding Queer street: the simple relief of having escaped ruination, AND a chunk of change.
But in the case of Enron and many other companies, the system has moved far beyond the world which we learn about in English class when we are forced to read The Rise of Silas Whoever.
Risk, reward, and reward's inverse are arbitraged, and the most popular game in town is called Fall Guy, with his large stock of worthless Enron stock.
English classes teach us something we need to know: but no "class" teaches us something else, we need to know. The Rise of Silas Lapham and other novels of the 19th century taught us of our potential to be a sort of fully responsible, Promethean hero, who like the originary hero of the 19th century, Bonaparte, was fully ready to enjoy the rising sun of Austerlitz and to bear his imprisonment on St. Helena.
But we don't get to read The Fall of Homer Simpson, about a world in which (partly owing to data systems) individual identity and individual responsibility are by default factored.
We all know about it. We all know how it is that at our level, we eventually have to pay the piper. A student loan company found me on my own personal St. Helena, Lamma Island, and I was so impressed by their skill that I paid my loan off. This is what I do: I pay debts. Sooner or later.
So we ask who are those guys who don't?
It's not all about "personal responsibility" in a world where people can buy all the PR they want. It used to be about solidarity and not kicking a man when he was down.
Therefore, I would agree that only in the brutal Hobbesian sense is management "free". They are NOT free from my condign judgement of scoring systems which they announce with such fanfare and which are an invitation to people who would rather play competitive games, and make good people look incompetent, than do the work of the world.
My kids needed an Apgar score, because without observation, they would have DIED. I'm sorry, but I cannot so value the "needs" of the American corporation, a thing with entirely too many rights and a shady past.
Instead, it needs to be in a continual and ongoing conversation with its employees and its community about just how well it meets HUMAN needs, which are not NUMBERS but HUMAN stories and texts.
To be a conversation, this conversation needs to start with a fundamental acknowledgement of the dignity and importance of every human being in the conversation.
For example...
...I would refuse to use CVS to find the bum whose code is delta'd alot.
"No Bad Programmers".
There are no bad programmers in the sense that it is a major waste of time to Find the Bad Programmer.
It's a waste of time because the white collar employee will turn, in a game of Find the Schmuck, away from doing a good job and into the job of Not Looking Like a Schmuck.
There are no bad programmers. Or, if you like, I've written a lot of code. Blame me for all your problems.
But there is a bad society, one in which the electorate was systematically lied to for six years.
Don't get me started, in other words.
Different things need different scores
While I wholeheartedly agree with most of what you write with regard to matter of ethics and software, I think you might be off track here.
As I understand the Apgar Score, it is an assessment of physical health and is used only to decide whether to call in the experts and/or start immediate treatment or whether to simply turn the infant over to Mom. Everything else is secondary during the first minutes after birth.
The Apgar Score also strikes me as something that any fully functioning mind can become expert at with practically no medical training.
Just as Apgar seems to express no concern for the ultimate mental, emotional, ethical, and even physical health of the person through life, I think we can make effective use of a scoring system that ignores such things as re-insurance schemes. This is especially true if it turns out that the scoring system encourages and rewards a clarity of expression that makes it easier for people to spot the existence of a re-insurance scheme (or mistake, for that matter).
I doubt that being able to score code in this way will have any effect on the ethical behaviour of programmers or their bosses. But it's not intended to. We already have other ways to measure ethical behaviour, many of which have been encoded as laws. What we don't have is a way to reliably measure the 'quality' of the code independently of its actual purpose. Perhaps a comparison could be made to literature. There all manner of well-written books that have evil messages or purposes and there are all manner of wonderful messages that are expressed very badly.