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 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 correctly paid much-needed attention to the objective of supporting configurable runtime behavior. As opposed to simply documenting how the design would accommodate this desired configurability, 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 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 implementable 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 service…” 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 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 detailed description of his alleged perpetrator to a police artist who appears to be diligently sketching a corresponding likeness on an unseen tablet of paper. After some time, the police artist believes that the likeness he has captured is sufficiently ready for the victim to assess its accuracy. Amidst a rising crescendo of expectation, the artist reveals his drawing to the victim. Shockingly, the drawing contains only a human stick figure that would be considered primitive by even kindergarten standards. All of the critical detail is missing from the sketch upon which to base future work, just like when CreateWorldPeace or IncreaseTheSpeedOfLight use cases are delivered to software engineering organizations for implementation. Abstraction has a whole new meaning amidst the whiz of silver bullets!
Silver bullets of the past and present share a number of common properties that will also likely apply to the bullets only now forming in the mental foundries of the fantasy minded. They defy the laws of physics, they are not bounded by cost, they are not constrained by time, and they seem to rob otherwise intelligent people of their common sense. Their usage is typically accompanied by postponing engineering efforts to a time later in the product life cycle, shirking responsibilities to other organizations, and blatant disregard for reality. And probably the most consistent property associated with silver bullets is that the people who promote or endorse them have generally never been software developers nor have they directly contributed to the delivery of a successful program. With Fred Brooks’ well-known admonitions aside, it is startling that the failure of past silver bullets is insufficient to make people very wary of them today.
Barring future events similar to the Hunt brothers’ failed attempt to corner the silver market in 1980, silver futures appear to be bullish. The supply of fine-grade silver required to manufacture the next generation of silver bullets is projected to meet future demand so the sound of their whiz will not subside anytime soon. As a result, software organizations must accept that silver bullets will be a part of their future and should prepare strategies to defend against them rather than to assume their demise. The only plausible defense strategy against silver bullets that I have been able to think of is to assemble an engineering staff that has a natural affinity for eluding these projectiles and one with an innate terror of them. Assembling such a staff, however, would involve an undertaking that is currently quite unpopular: outsourcing. As opposed to China or India, however, my outsourcing plan would focus on a small town in Romania. For it is only in Transylvania where one can assemble a team of those certain someones having an innate fear of silver bullets…werewolves.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment