eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When management wants to measure something now or predict something yet to occur, a software developer will probably have to come up with the final form of the algorithm that yields the answer.
With last weeks announcement of consumers access (pay-per view or subscription) to their FICO credit-worthiness scores, we have a particular reason to think about the implications of letting software writers grind the lenses through which we see the world.
I heard a radio discussion of the FICO formula, and its counterintuitive consequences, on National Public Radios “All Things Considered” last Tuesday. If you try to tame your use of credit, said the radio programs visiting expert, you may actually reduce your FICO score: Closing several high-interest credit-card accounts, for example, to consolidate your balances into one new, lower-interest account will tilt your credit history toward short-term statistics. It will also result in a higher percentage of your available credit being used. Each of those, reasonably enough, is considered a bad thing, but the formula fails to respect the context that makes this an improved situation compared to what came before.
The firm that compiles the FICO, Fair, Isaac & Co. Inc., apparently plans to put a “FICO simulator” on its myFICO Web site so that people can see how their financial choices might affect their suitability to lenders. Well, thats better than making people guess. But what does it say about the merits of the metric, when common sense doesnt work in predicting what it will say?
Normally, I argue that its the job of the software writer to ensure that a specification is clear and unambiguous; that it can be implemented within the limits of available data and computational resources; that the performance of the resulting system will meet the actual needs of users. Ive been present, for example, in conversations with users who said—only because I asked them—”Oh, if that took more than five seconds, Id never bother to do it.” You can spare yourself a lot of work that way: The hairiest, most ugly pieces of a specification may dry up and blow away if worst-case acceptable performance is part of the description.
Unfortunately, some discussions of the problem of ambiguity are themselves poor examples of clear writing. Others are more direct and useful as statements of what we should try to do tomorrow.
What scares me most are the people who write the specification, after the fact, to describe what their code appears to do after making all the changes proposed in the beta stages: For example, in the testimony by Bill Gates that I quoted last week, another passage reads: “121. Microsoft would be prohibited from providing information and obtaining feedback via the Open Review Process… Section 4, read in conjunction with the definition of Timely Manner (Section 22.pp), appears to require that Microsoft disclose technical information to the industry generally (ISVs, IHVs, etc.) at the same time that information is disclosed to any third party. It is not practical to disclose information concerning a new technology to the industry at large before specifications for the new technology have even been prepared…” Umm, what is the information and code thats being sent out for comment before any specification exists to say what the thing is supposed to do?
Sometimes, coders wind up rewriting specifications, in the process of writing the best code that theyre able to produce that comes close to what the actual specification requires. Joseph Weizenbaum described several such episodes in his book, “Computer Power and Human Reason,” in a chapter entitled “Incomprehensible Programs.” That kind of invisible editing is not something that I ever want to see.
At some point, though, I wonder if the analytic ability of any competent programmer deserves to be given more scope: If its the unwritten job of the coder to give feedback to those who are paying for the work, asking, “Do you realize that these changes to the input will produce these changes to the output? Is that really what you want?”