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.'"
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.
Ok, so the syntax was standardized.
XML says little of the semantics. This isn't evil in and of itself. The way it was marketed as a silver bullet, even though the semantic holes|canyons|abysses stretch wide, explains the backlash.
What's good about XML, and I used to go to some government working groups about it, is that by calling everything "human readable text", there was much participation from people who otherwise wouldn't budge.
The bad news, in the government case, is that homo bureaucratus realized that free transfer of information among agencies would mean a migration of the logic from people-ware to software. Realizing the ensuing threat to the rice bowls, the whole working group collapses in semantic wars. Shall we use attributes or nest entities? and so on.
Once again, technology fails to overcome behavioral problems.
What will succeed XML as a soteriological technology? Rails?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
- 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.
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.
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
Your "~~~" idea doesn't even come close to solving the problem. It still won't help with newlines in the data, if the parser parses line by line. It still doesn't solve the problem of weird characters in the key, either. To really solve this problem you need to escape the sequences with a special meaning (which would involve lots of extra complexity for both writing and reading), or encode it as length/data pairs, at which point it stops being usable for humans.
Now, in most projects, parsing configuration files isn't one of the primary objectives. If that's the case, why not just use an XML library, where all those issues have been dealt with already?
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.
Thank you ...
...
.....
...
...s action") during the transaction ...
...
coming from an other world, where 2400 baud modems were a luxory, I always get bothered while dealing with XML, and seeing that in most transactions, over 50% is the tags.
Then people deal with the magic SOAP transactions, where they send 90%+ tags, and 2-3 short strings as the actual data
On the other hand, implement a payment processing using
a. SOAP requests
b. some proprietary crap
than you will thank God for XML
I also have to mention that while XML seems like a bandwidth hog, there is little to complain about, when people are stuffig 1M+ size images on flash loaded sites, where they stream you mp3 by default on onLoad(), and force you to DL a new flash version for no reason whatsoever (flash 8 player is important for those menus, yeah)
I also agree, that framing data in xml is a waste many times, but that is also the problem of naming
In fact using tags like ThisIsTheFirstNameOfTheCustomeOfTheTransaction you can use "Name" or a1, then agree with the client later on )or before) what a1 is. Especially when that file has that 1000 times, that would save 2x100x bytesize("ThisIsTheFirstNameOfTheCustomeOfTheTran
but hey, who cares when the hosting company gives 1000gig UL xfer a month and a dual proc with 2gig ram for $99-120
I personally do, but most people don't
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!