Egyptian hieroglyph had not instead been chosen as the representation choice for this configuration data?

Still reeling from the potentially powerful implications of what I had read, I began to wonder if any textual content expressed in XML would somehow lead people to believe it to be of high pedigree, divine origin, and having some implicit warranty of accuracy or correctness. I decided to test this premise and composed an email message to my 12-year-old daughter hoping to sway her on an opinion she had been stubbornly adhering to in the past—see Figure 1. I was hopeful that if she were to read my message within the context of XML, our long-standing dispute would finally get some much-needed resolution. Unfortunately, things did not work out as I had hoped, and my ploy only served to further reinforce her unyielding position on my standing among other fathers.

XML is not the only silver bullet in the software engineering toolkit to which value seems to be implicit by mere usage. The fact that a diagram has been created using UML leads some to believe that the associated design is guaranteed to be implement-able and ready for development even if the laws of physics were ignored as constraints. Had my daughter not already convincingly dashed the notion of implicit technological sanctity, I certainly would be tempted to create a yoo-mel^c sequence diagram for my wife detailing the steps I plan to take someday to be more sensitive, a better listener, and less of a slob. If she were to see my plan captured in UML, perhaps she would be more inclined to believe the sincerity of my intentions?

No discourse on silver bulletry would be complete without giving due recognition to a current favorite: Web services. “That’s just a Web ser-vice…” is a phrase often spoken so convincingly that it is hard to believe that there are not Web services already available with which to accommodate all known functional needs. After all, there are already Web services available that provide the stock price for any ticker symbol or the ZIP code for any city, how difficult could it be to

create a new one that simply returns numbers that violate the Goldbach Conjecture?^d Considerations for strict temporal determinism, sporadic network availability, or the fact that a Web service’s signature does not support one’s workflow needs are unimportant amidst the whiz of silver bullets.

Although vulnerability to error and productivity impacts of working directly with XML inspired the innovation of technologies such as WSDL with which to improve the usability of Web services, some developers feel that their usage short-circuits the unparalleled maintainability and flexibility properties offered by method signatures as shown in Figure 2.

Why should anyone subject themselves to the brittleness of specialized methods when a single method can accommodate currently required behaviors and any that may only be known in the future? Additional benefits of offering methods with DoAnything() signatures include freeing designers from the burdens of time-consuming negotiation with prospective service users and not having to be bothered with recompilation issues that typically accompany usage of more strongly typed interfaces. It would serve as a great justice if the providers of methods such as DoAnything() also assumed their associated liabilities. The unfortunate reality, however, is that the method’s users typically have to

d A long-unsolved math problem asserting that all even positive integers >= 4 can be expressed as the sum of two primes.

endure the associated liabilities in the form of increased testing and integration costs as the result of misusage being virtually undetectable at compile time. In response to suggestions that a DoAnything() method should be redesigned to take advantage of strong typing, it is not uncommon to hear its designers assert something of the sort, “An XMLCommand is a strong type, let’s see you try to use an integer argument in its place!”.

The challenges of software development are difficult enough without also having to endure the ricochet of silver bullets strafing the organizations responsible for engineering the products that software development itself relies upon. For example, some systems engineers have discovered that usage of UML greatly simplifies efforts that their predecessors unnecessarily struggled with in pre-UML days. As opposed to having to devote significant efforts to the consideration of constraints such as network bandwidth, processor speeds, and the speed of light when developing system architectures, such annoyances are now overcome by creating stacks of UML diagrams that abstract these details away as uninteresting implementation issues. I wonder if there is any way for us software guys to further kick this problem down the road by convincing testers that their jobs would be much easier if they validated UML models instead of software?

One of my favorite television commercials of all time helps characterize the situation. While sitting in a police station, a crime victim is providing a

figure 1: sample message text expressed in XmL.

<message _ from _ Dad>

<addressee> Alanah </addressee>

<message> Hi Sweetie, I am not the weirdest Dad of all the kids in your whole school.

Love, Dad.

</message>

</message _ from _ Dad>

figure 2: sample method signature.

XMLResult DoAnything (XMLCommand Arguments)

{

......

c Spoken in a drawl, a euphemism for insane usage of the UML.

}