Vviewpoints
DOI: 10.1145/1378704.1378712
From the Front Lines
Software Development Amidst
the Whiz of Silver Bullets
Software development organizations must accept the inevitability of silver-bullet
solution proposals and devise strategies to defend against them.
THE SOFTWARE ENGINEERING
landscape remains pockmarked with individuals
who continue to disregard
Fred Brooks’ sage admonitionsa asserting that silver bullets
should not be relied upon to solve all
woes. The desperate, the pressured,
and the ignorant are among those
who defiantly worship the silver-bullet
gods, pleading for a continuum of the
silver-fueled delusions keeping many
of their projects alive. It is difficult to
be overly critical of those who have succumbed to silver bullets, however, because the software engineering space
is being strafed with them as never before. In fact, even the most savvy must
occasionally liken themselves to the infamous Neo in the film The Matrix and
gyrate wildly to avoid being stricken by
the many silver bullets whizzing by.
Veterans of the software industry
will attest to having seen a number of
silver bullets come and go during their
careers. The argentumb projectiles of
yesteryear, such as OO, high-level software languages, and integrated development environments, are now obvious to have been only low-grade alloys
compared to the fine silver being discharged today. Some of today’s silver
bullets have demonstrated an unparalleled ability to provide implicit value to
a Brooks, F.P., Jr. No silver bullet, essence and
accidents of software engineering. Computer
Magazine (Apr. 1987).
b The Latin word for silver and the basis of the
periodic symbol: Ag.
artifacts just because they were created
using a particular technology while
others have demonstrated the power
to shift the responsibilities associated
with long-established engineering disciplines to other organizations. Only
the passage of time will reveal the new
and amazing capabilities of future silver bullets that have yet to whiz by.
Getting back to today’s silver bullets, though, I was recently reviewing
a software design package that cor-
rectly paid much-needed attention to
the objective of supporting configurable runtime behavior. As opposed to
simply documenting how the design
would accommodate this desired con-figurability, however, the design description also included a compelling
assertion a number of times: “The
configuration data will be stored in
XML.” What on earth did this have to
do with anything? Should I have been
relieved that some form of irregular
ILLUS TRATION B Y JOHN HERSE Y
