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-melc
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.
}