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.'"
Seeing as how TFA mainly rants about XML (and only passingly mentions past "silver bullets" of the past), he should be complaining about the silver bullet.
I prefer my analogies in car or tube form, thank you very much.
Sorry, I LIVE in a pretty small town in Transylvania (used to live in a slightly larger one), and software developers around here are all BUT immune to (the lure of such) silver bullets... ever heard of Cluj-Napoca or Baia Mare (or any of the software microbehemoths that start springing to life there) ?
By reading this signature you agree to not disagree with the post you just read.
I will admit that people like to find silver bullets. BUT, and this is where I get annoyed. It is not just management that preaches silver bullets! How about those that preach Open Source will solve all problems? Or how about Ruby? What about Perl, Java, Linux? And we get annoyed when people don't listen to our "silver bullets."
The problem here is that everybody has their own silver bullets, and if you don't happen agree then you think the other person is a bone head.
So let's stop the blame game shall we.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
An interesting article but one should be wary of dismissing a silver bullet on the basis of poor application.
My own experience of some of these bullets (UML, agile methods, etc.) within an organisation is that they get a small enthusiastic following who push it so far, implement maybe 20% of the technique then lose interest or regress under deadline pressure. They don't follow the bullet far enough to draw proper conclusions.
I'm cynical about most bullets, but some catch the imagination. I'd just like to see one of them, just once, properly implemented.
Incidentally, this isn't just an engineering article. Management suffers from the same tendency towards managerial silver bullets (and the same poor application). I guess many professions do.
Oh, so buzzwords can be used to disguise laziness and bad implementation? Where's the news? Even in his satire of XML (and don't you think I'm a big XML fan) he shows that he doesn't understand.
For one: 'utterance_in_a_state_of_speechlessness' should be 'utterance state="speechlessness"'
And further: Using sophisticated design techniques doesn't replace the work, but it can help a piece of software reach it's maximum potential. On the inside of every shop there is a silver bullet: It's called education. A model doesn't replace programming and somewhere beyond the ususal CRUD there's allways work to be done on procedural details - that's where part of the fun in sw developement is. Every developer worth his money knows this. If he where ranting at academics, I'd understand, but as far as I'm conserned he's preaching to the choir.
TFA is definitely not 'well-thought-out'. In fact it's a tad pointless.
We suffer more in our imagination than in reality. - Seneca
Web services are probably being overtouted as a silver bullet, but the fact is that they serve a very useful purpose. I maintain a legacy app which uses ad-hoc XML over HTTPS. Since I have no idea what the format of the request and response is, I must constantly refer to the code to figure it out. I must also invent my own error responses if the format is incorrect. Web services mean I could just define the interface in WSDL (using WTP in Eclipse for example) and more or less forget about it. I can even use Axis or .NET's wsdl.exe to auto generate the stubs that make the call and just concentrate on the business logic. Bad calls throw a soap fault which is turned into an exception or whatnot by the client lib that makes the call. It doesn't make all my problems disappear, but it does mean I can be looking at the functionality of the app rather than wasting time rolling my own XML format.
And even the ad-hoc XML over HTTPS is quite an improvement over what came before. Then you'd be talking about opening a port and defining the whole handshake and transfer of data using messages, complete with all the bugs and security issues that go with that. Standards are a great thing even if they initially seem confusing.
Certainly any standard is open to abuse. I expect that anyone who has to deal with Microsoft's new Office format over XML will be in a world of hurt. But you have Microsoft to blame for that, not the standard.
- faultless software policy
- 'no heroes' policy
I am still waiting to see occurance of the first one and chief boss brave enough to properly implement the second even though attempts are constantlly made to down size, off-shore or tell a cleaning lady to do my job while swiping the floors etc. When one thinks of it - it is really a pity that so much effort to produce so many shiny tools and technologies go wasted all the time. I guess somebody makes healthy profit on our stupidity and/or indiferrence because I cannot explain why new ones are coming without a pause.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.
XML works perfectly? Only for some strange definition of "perfectly" I think.
Yes sure, it works. It is an easy solution to various simple data-interchange-like problems.
However, it is also bulky, inefficient and overly complex. Bulky - needs no explanation. Inefficient - parsing it isn't that trivial, and also applying schemas is expensive and complicated. Multiple levels of namespaces, and so on can lead to complex heirarchical data structures that need a load of work to make sense of.
_
\\/ are accustomed' - First Lensman
Just because it's new and has a buzzword doesn't mean it's a flash in the pan.
Silver Bullet != !(Flash in the Pan).
It doesn't look like the essay defines "silver bullet" and I don't have the original in front of me, but a Silver Bullet is a single methodology or technology change that by itself always results in an order-of-magnitude improvement, thus seeming to "slay" previously immortal beasts of problems.
Fred Brooks never claimed there wouldn't be improvements, and there have been. But they always seem to start out looking like silver bullets, and end up being incremental improvements at best. Most things are actually steps backwards if applied to the wrong domain. (A Silver Bullet probably won't have a "wrong domain", although this point is debatable; certain it shouldn't have many.)
Being a "flash in the pan" is even worse than not being a silver bullet, in that it implies it never had any real value at all.
Also, while your web application specifically may have been an improvement, the idea that it's an improvement in general is debatable, let alone anything like a silver bullet. It improved your case simply by virtue of expanding your options, allowing you to adopt a model more suited to your domain, but there are cases where a web app would be a serious step backwards. I consider the attempt to build office suites for browsers a joke, for instance. Web apps are merely improvements in some ways at some times, not a silver bullet. (I realize you didn't directly make this claim, I'm just discussing it.)
If Vendors would stop preaching that they are the next 'silver-bullet' then perhaps this would stop.
Actually, it would only stop if potential customers would stop believing in silver-bullets. I work in the specialty chemical industry. You would not believe how many times I have been asked for a 'silver bullet', even when I explain that said bullet is impossible because it violates one or more laws of nature. Vendors offer them because customers want them, reality be damned.
-- Fugacity: Confusing chemists since 1908
Many resumes I read these days proudly trumpet UML and RUP as a key skill. Those resumes cause me to either pass altogether on that candidate or grill them harder on fundamental computer science during the interview. Many of these folks can't tell me when to use a hash table vs a linked list. So, some hiring managers have not drunk the UML coolaid.
While most corps screw up with UML, that's only 'cause they don't use it properly. It's not about the ``UML'', it's about the process---and knowing how to draw boxes has nothing to do with knowing and following the process.
I've been on many projects (and managed quite a few myself) that successfully used UML in requirements gathering (use cases---so business folks can sign off on them; leading to less problems later on), object modeling (database schema generation, php, c#, java, etc., code generation, ado code generation, etc., UI generation [similar to MS Access wizard forms]) and general documentation.
On projects where I used UML, it becomes the -source- of everything. If you need to add an attribute (or field in a form), you change the diagram, not the source code. You then have tools (in my case, almost always written in Perl) that generate the source code from the diagram. UML in essense becomes the single place for all non-logic related changes (sorta like a visual domain language).
Obviously there are still huge chunks of glue code that cannot be done in UML---but those can often be reused from project to project---so most DB/UI projects I do now basically involve creating a UML diagram, generating some code (with/without networking support, etc.) and playing with VisualStudio to tweak default generated forms to look nice. (and handling some exception cases that don't lend themselves to generation).
You'd be surprised, but 95% of all database apps are exactly the same. Why bother hand-coding all that over and over again?
Also, managing the HUGE number items (and changes) via UML is much easier than... well... with just about anything. Try managing 10 developers working on a single project without some coordination thingie like UML.
The problems that most corps have with UML revolve around using UML just for documentation (that's an overkill, and will get out of sync). Also, non-programmers (``System Architects''---the non-techy types; or managers) tend to think they can build stuff with UML, and almost always get things very wrong.
"If anything can go wrong, it will." - Murphy
I believe military history and military science have something to help us illuminate this issue.
I am a reader of military history, and I recall reading about the German 81mm mortar in WWII - about how the allies conducted studies into its design after the war, as they wanted to find out what the German "secret" for such an effective weapon system was . . . the secret was, there was nothing special about the 81mm mortar - its crews were simply well trained, highly motivated, and well led.
The Germans did more with less, beat materially superior opponents consistently, and maintained tactical superiority up until the last moments of the war - I believe there is something to be said for all this (moral/political/personal opinions aside) and one of their core philosophies was that it's not the weapons, it's the men.
Now, the historical points I have brought up are debatable, however, I am convinced that the fundamental idea stands:
It's the Men, not the Weapons.
MRH
SARAVA!