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
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:
I thinks most engineers are smart enough to understand there is no single solution to every problem. They may have biasses, but most damn well know that there are problems for which the other solution is best. What you are talking about is a vocal minority of zealots versus a very large majority that can't be bothered to deal with them. The problem is that, typically, engineers are the silent majority and managers are the vocal minority.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
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.