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
References:
Archives