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.'"
Microsoft Vista! It's the silver bullet for everyone! Where do you want to go today? TM
I'll probably be modded down for this...
In this case, if you under 18 years of age, I recommend that you buy a box of silver bullets or just plain vanilla lead bullets. Put the bullets into your revolver. Hide the revolver in your jacket. Then, walk into your boss' office. Fire away. You will not be tried as an adult since you are not a legal adult. Better yet, after you reach the age of 18, your criminal record will be wiped clean.
If you are over 18 years of age, you need to weigh the situation carefully. If you kill your boss, then you will definitely be tried for 1st degree murder. You may be eligible to submit a plea of insanity. Most states allow such a plea. Check with your lawyer before you start shooting.
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.
Overheard while doing an internship at Logica CMG:
Manager: "This new project should be done with new project management methods, like UML"
Senior: "Uuh, you do know that UML is a notation for diagrams?"
Manager (irritated): "Yeah, of course I know that. You know what I mean!"
8 of 13 people found this answer helpful. Did you?
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"
... - 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
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.
XML works? Huh?
XML is a data representation. It works? How does it work? By representing data?
What else could work? S-Expressions? SGML? ASN.1? Flat text file?
The data representation isn't solving the problem.
XML, Extreme Programming, technique / technology of the week all are trying to do the same thing: help us manage complexity. Fred Brooks had a lot to say there. My favorite quote from the 'No Silver Bullet' essay:
Fred Brooks original silver bullet paper
Apart and aside from the fact he sees little or no value in things like objects or IDEs, he writes in an inpenetrable victorian style. It's either fine satire skewering the irony of luddite technologists, or the poor guy just doesn't have a clue how laughable his essay was.
As he snarkily pooh-pooh's the distribution of realtime stock and financial data as a web service, it's probably the latter. I used to work for a company who ran their own ticker plant and had software on the desks of almost every stock broker, investment banker and forex trader on the planet. The client/server requirments of the system were immense. The client had to be maintained on Windows, Sun, Mac and was being slooooowly ported to linux, was fragile as hell and a pain to install and upgrade. The server was a farm of eight midrange Sun or AS/400 boxes, fed by redundant T1's from the ticker plant, and this would only accomodate two or three hundred users.
Then we went to a web-based client, sort of like AJAX before people started calling it AJAX, and all the headache went away. It's not a small or trivial thing, and it radically changed the way business was done, and for the better.
Just because it's new and has a buzzword doesn't mean it's a flash in the pan. The moral of the story is to use your judgement, and avoid formulas. Even tried-and-true ones. Silver bullets may not exist, but technology doesn't stand still, no matter how many hours you've sunk into learning emacs and gdb.
SoupIsGood Food
XML works by freeing you from the need to come up with your own format and a parser. So, flat files, for example. Most people use completely braindead formats for flat files, like each data item on a line with no indication of what it might be, reinventing .INI files, or the even less complicated key/value approach.
That works, until you notice that it's not as easy as it seems. How do you represent arrays of data, or trees? Can you specify a string in Russian and have the parser not choke on it? What about Chinese? Can it handle Unicode? What if your format is "key=value", and the value contains a "=" or a newline? Can the key contain spaces? If you write "key = value", do the spaces get stripped or not? What if the first character of the value is a space?
I've seen all sorts of horrible tricks to deal with those problems, like "key=value" where the value is encoded in hex or base64.
XML is nice for that: The designers thought of all that already, designed it to be able to deal with all of them, and made parsers that work.
There can be few examples of an advanced industrial activity in which the ultimate decision-makers know so little about the technology involved, and have so little respect for the opinions of those who do.
"Hope springs eternal in the human breast" - indeed, in business (and especially sales) optimism is highly thought of, and realism often denounced as "cynicism" or "negative thinking". This is all very well in activities involving human beings, who can easily be manipulated through their emotions. However, it fails utterly when confronted with the cold, hard facts of the physical world.
When someone seems to be unrealistically hopeful, we speak of "getting a reality check". In other words, finding our noses hard up against the brick wall of ineluctable, unarguable facts. The problem with most software development projects is that the ultimate decision-makers - those who have the gold and, therefore, make the rules - are very rarely able to get a reality check until the project runs out of time, money, or both. They are hopelessly ill-equipped to make reasoned, educated judgments based on the arguments presented by vendors, analysts, and their own technical staff. So it's hardly surprising that over-optimism tends to creep in.
I have been giving talks about software engineering for about 20 years now, and I usually stress the fact that "there are no silver bullets". This warning is always greeted by vigorous nodding, knowledgeable smiles, and sometimes applause. Afterwards, I sadly feel, the people who have just agreed that there are no silver bullets go out into the exhibition hall or open their magazines, and resume... looking for silver bullets.
Ultimately, I see just two ways out of this dead end. Either decision-makers take the time, trouble, and mental effort to learn the necessary basics about software development and maintenance. Or they start choosing technical managers and architects who really know their stuff - and trust them implicitly. As time goes by, I hope that both these things will happen more and more.
I am sure that there are many other solipsists out there.
I think you've essentially hit the nail on the head there. XML is excellent at what it does. However what it does is not "everything", and the "silver bullet" marketing (Java + XML = "Enterprise"!) surrounding it causes people to get upset, because that's not what it is.
Marketing is, in general, really good at turning people against perfectly good technologies, because those in the know will always see through the lies, exaggerations and half-truths, but will then have a hard time conveying these to superiors or other colleagues who have had a little less experience and a glossy leaflet to gaze on.
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.
The only true Silver Bullet is really smart people. I've seen it time and again. If a project absolutely positively has to get finished by a particular date, put the best people in your organization on the project and turn them loose. Even the mediocre people on the team will start performing well above their normal levels. I'm not saying that adding new tools and technology won't help. I'm saying that adding really smart people will do far more than tools and technology.
I enjoyed the snarky and smart tone of the article. And I largely agreed with everything he said. However, I implied from his remarks (and comments here) that he could count the Xtreme Programming and agile methods among the false promises of the silver bullet. And I have heard them referred to by people I trust as silver bullets.
Before we start a religious war on whether XP/agile are silver bullets or not, let's step back and ask whether we're talking about different things. I think there is no silver bullet that will kill a software monster created by Big Up Front Design (BUFD).
It's a good thing to put serious, deep thought into what must be done before one starts work. You have to do your homework and you have to write down everything you know for certain up front. Trouble happens because after some point up-front design becomes mere speculation. You have to somehow confirm early design decisions made when you're ignorant.
In the old days before computers, Engineers built prototypes to do that. Nowadays, Engineeers (or the pointy-haired bosses who lead them) are addicted to the notion of "shipping the prototype."
I personally favor the notion of capturing "user stories" because stories have a way of separating "what" from "how" and stories are an effective way to communicate pertinent details between customer and developer while skipping over one's ignorance.
A trouble with BUFD is that it becomes a "proclamation" about software from the developer (or customer, depending upon the power-relationship). If we were gods, that would not be a problem, but we have limited knowledge and we have sort our our ignorance. But we're not and I think a "conversation" between the two is a more effective way to sort out what's wanted and what's possible.
In a "conversation" the software monster never grows so big that the ammunition in our clip (UML, agile/xp methods, high-level languages, today's microsoft buzzword) can't kill it.
TQM, it seems teaches constant positive feedback.
Actually, I remember the TQM craze well. However instead of learning about it from the trade rags, I decided to read Kaoru Ishikawa's book, "What Is Total Quality Control?: The Japanese Way". Dr. Ishikawa is the creator of the infamous "fish-bone" diagram.
The interesting thing about Ishikawa's book is that if you had to boil it down, it wasn't about tricks that would magically give your products "quality". Oh, there are some chapters on how to understand what customers' real requirements are (thus the fishbone diagram). But they aren't the heart of the book.
What the book really is, is a primer on character. And according to the book the bedrock characteristic of a quality producing organization is integrity.
It does no good to understand customer requirements if you don't understand your own products and processes; and you will never understand those if you fear the truth and you discourage its spread. So the first thing you need to do is eliminate the culture of fear: fear of failure,mistakes, and plain old bad news. Once fear is eliminated from the organization, useful information begins to flow. In Ishikawa's vision of the quality organiation, fear of the truth is the greatest enemy: victory in competition goes to the organization that discovers and rectifies its faults the quickest.
Which is why it is foolish to motivate with praise, particularly undeserved praise. I've never met an engineer worth his salt who really enjoys getting personal praise on more than a occasional basis. The good ones are more motivated with the prospect of becoming better. Praise has its uses; mainly to help maintain a realistically balanced view in the painful process of self improvement.
Manufacturing is different than software development. But it is true that the integrity and fear play a huge part in determining software quality. Some day I will write a book: Why Good Engineers Write Bad Software. The number one reason has to be this: not facing reality. This leads to the number two reason: not doing what you know you should be doing.
Both of these proceed from fear. A software development organization that eliminates fear eliminates the number one barrier to achieving its potential. In the end, the personal qualities of courage, compassion, and integrity that we bring to our work matter much more than any methodology.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.