Slashdot Mirror
The Whiz of Silver Bullets
ChelleChelle writes "In an entertaining yet well thought-out article, software architect Alex E. Bell of The Boeing Company lashes out at the so-called 'Silver Bullets' and those who rely on them to solve all their software development difficulties. From the article: 'the desperate, the pressured, and the ignorant are among those who continue to worship the silver-bullet gods and plead for continuance of silver-fueled delusions that are keeping many of their projects alive.'"
If Vendors would stop preaching that they are the next 'silver-bullet' then perhaps this would stop. It is not the techs who decides what comes in and what goes out. It is normally driven by cost. And when companies say they can do all of X,Y, and Z at a lower cost then any competitor, the IT department gets screwed, and management looks at them with wonder because they provided a 'silver-bullet' solution to them.
There are no loopholes. It's either legal or it's not.
... - As the saying goes.
The problem with Silver Bullets is not the bullet itself - but the idiot behind the trigger.
Most of these Silver Bullets are great ideas, but give them to some moron who half knows how they work (and yet claims to be an expert) and they do the exact opposite of what they were intended to do, and because some PHB reads about in the industry pages, they just keep hanging in there like a millstone around our respective necks.
For any technology you can see outstanding implementations. But for every one of those there are ten other complete disasters.
And as the other saying goes - if you don't know who the moron is.....
Genesis 1:32 And God typed
Fred Brooks original silver bullet paper
I've seen programming paradigms come and go (structured programming). I've seen management techniques come and ago (PERT charts). I've seen technologies that had gone come back again (virtual machines) and even some that have gone come back (centralized computing services). If punch cards come back, I'm retiring to my cave.
There is one thing that seems constant: The mix of successful, marginally successful, and just plain failed projects feels the same as ever, even though I'm positively sure that our knowledge of how to create software is much greater than it was.
The glass half full aspect of this of course is that the sytems we are developing are far more powerful and complex than what we worked on in the early 80s. Back then many projects were just collections of utility programs that were invoked from the OS command line and ran top to bottom. Structure those programs, and the problem of how to create software is solved, see??? That's why structured programming was the silver bullet of the 70s and early 80s.
Now, it's not uncommon for a "lowly" application programmer to have to deal with things like aynchronous processes, something that was the province of the lordly systems programmer back in the day. Ordinary applicaitons are as or more complex today than major systems were back then.
The other thing that is constant is that some people get it, some sort of get it, and some don't get it a all. But the common shibboleths of our profession are freely available to all, level of englightment not withstanding. The difference is the lower the level of enlightenment, the more those things take on the role of totems and fetishes.
I've been looking at jobs listings recently, and curiously they never seem to be looking for charactersistics that would demonstrate that somebody "gets it". I've seen things like "Must have three to five years of programming with Struts." Now I have nothing against Struts, but I can see nothing about Struts that would indicate you need three years of hard labor to be able to work productively with it. After all, the point of all these frameworks is to make things easier. I can see "must have thre years working with distributed transactional systems", or "must have three years of experience with security on web applications", or "must have three years of experience with designing user interfaces."
I'd rather call things like the XML or web services craze "technology fetishes" than "silver bullets". A fetish is "An object that is believed to have magical or spiritual powers, especially such an object associated with animistic or shamanistic religious practices." Religious or technological, fetishes are for some aids on a difficult but rewarding journey, for others they're the promise of relief from hard work, thinking and risk.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Some time ago when SOA where the very new buzword, I've had an interview where the manager of the team asked me why I didn't put XML in big bold character in my resume next to Java, C++, ...
..., just the plain XML) that allowed the world to see the light and embrace SOA/MDA design, the only god that can save our wicked developer soul. The whole interview was about my relationship with the XML and how its light shines upon me.
For him, XML was sort of a religion. The ultimate "technology" (we were not talking about all the technos that comes with XML like XSLT,
Talking about XML as a "tool" was a blasphemy. I "learned" that the savior XML:
- Saved us from the interoperability problem by allowing us to transfer data from and to any system
transparently. Sure, you only have to transform the output of one application into the input of the second system.
- Reduce coding problem ( using for example, the function "XML DoSomething(XML params)", so you can change the params without changing the interface and the doc (duh!) )
- Reduce database problem ( storing XML as blob in the DB - no need to call the DBA when you change the data format )
- Solve configuration problem ( now configuration file are in XML that means it is easy to understand )
Thanks XML.