The Whiz of Silver Bullets 244
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.'"
Well... (Score:5, Insightful)
Comment removed (Score:2, Insightful)
Silver Bullets works just fine (Score:2, Insightful)
Bullets don't kill people... (Score:5, Insightful)
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.....
Webservices are todays silver bullets (Score:3, Insightful)
And every body knows that XML itself is no longer a silver bullet. It is too natural and integrated to not use XML where it fits in.
What I worry about is the huge stack of technologies that are currently being built on top of it.
Webservices being the biggest of those and worse the stuff that goes on top of that:
XML Schemas, WS-YouNameIt, BPMN, BPEL4WS
It reminds me of a few years ago when choosing java for an enterprise project meant that you had to use EVERY component in the J2EE stack, so that every single class was a EJB and every single call was a remote call.
Now most projects has learnt to stay away from the "classic J2EE" approach, but are instead falling for the next silver bullet which invites to make the excact same mistake using Web Services
Webservices are great and has their uses, but I have seen projects that subscribe to the idea that every single component in the project should be a webservice and orchestrated by BPEL. Good luck.
There is always a meta-layer (Score:1, Insightful)
The simple rule of the thumb is (Oh, no, another silver bullet incoming): listen to the needs of your "troops from the trenches", your developers. Each innovation begins with someone's "scratching own itch". If your developers don't feel the same itch as the inventor of the new method/tool, then they will certainly suffer under the scratch devised and produce net worse results.
Managers should be evaluated not based on total of changes ("improvements") they did but on the difference between the damage they did when they acted without real need and gain they made when their actions where appropriate. Beeing frantic is not desirable feat for a leader. We don't need CYA excuses ("Don't fire me, I worked hard, I am up to date, I introduced all this new buzzword-named things I found on Internet") but responsibility, insight, competence, awareness. It shouldn't be easy-wheasely cakewak beeing a manager and following the path of "blame others" as it seems to be today.
Re:Bullets? (Score:5, Insightful)
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:
Re:Bullets? (Score:5, Insightful)
Re:Stop the BLAME GAME! (Score:5, Insightful)
Technoluddite? (Score:5, Insightful)
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
Re:Untried bullets (Score:3, Insightful)
Re:Bullets? (Score:5, Insightful)
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.
Re:Well... (Score:4, Insightful)
And this is what has to change. Saying that techs should make all the decisions is of course unrealistic, but in a sane company the management lets them evaluate the solutions before deciding.
Software development is a pathological case (Score:5, Insightful)
"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.
Re:Bullets? (Score:5, Insightful)
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.
Re:Technoluddite? (Score:1, Insightful)
So no deep familiarity with the guts of niche OSs.
And updates could be painlessly rolled out to all clients, requiring no reinstallation.
Standardised network connections, allowing common tools. Also load-balancing web-servers is quite a well understood problem.
Sounds like it solves a few problems to me.
Re:Bullets? (Score:2, Insightful)
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?
Observe that all these things are problems that only arise if you have humans generating the data. If a program generates it, then you never get bogus spaces or text in an encoding the program can't handle.
Guess what? XML is fragile when humans write it, too. What happens if they write a lowercase tag in uppercase? Or if they add a string in Chinese (Big5) to a file that's supposed to be encoded in UTF-8? Or if they forget a closing tag? If they write "<key> value </key>", will the spaces get stripped or not?
Besides, who said anything about designing your own format and writing your own parser for it? It's not like the only ready-made, well-tested, well-designed libraries are XML-based.
Re:Well... (Score:5, Insightful)
Why ? Think about it from the management's point of view. The choices they face are:
Which one should a sane manager choose ? Getting fired or getting a bonus ?
Re:Bullets? (Score:2, Insightful)
Ah Ha! My chance to get modded into oblivion by those who don't know anything!
XML is a tagging system. It may be useful for the transmission of data between dissimilar systems but even there it is a crappy methodology. It bloats the data with massive tags, if you parse it in anything but a linear fashion, it becomes a recursive method to make processes take forever and isn't worth anything more than a flat file with a table at the top to tell you where things are. XML only handles ASCII and doesn't do that very well. In fact it really goofs up when you get down to numbers. Imagine 12 types of nodes! (Reality if you have run the parser) It isn't even logically linear in operation. XML eats internet bandwidth like it is going out of style.
As to the "Silver Bullet" theory. Well XML is a whole lot better than a secret proprietary methodology, but that could have been solved by simply telling the file format.
What is going on is something a lot of us older programmers have known for a long time. We see subsituted for skill, planning and ability for massive structures that eat memory, and they do the job, sometimes and slowly. I remember open discussions that memeory would eventually expand to the point that we didn't have to worry about it in programming. Of course that geometrically degraded the performance. Sure you have enough memory now but what are you using it for?
Re:Silver Bullets works just fine (Score:4, Insightful)
Re:Sorry, no sale :p (Score:3, Insightful)
See, this is the problem with offshoring. It's not the quality of the foreign coders, it's the lack of a shared cultural context in which to collaborate. For instance, no American software company would put "Cluj" in its name.
Re:Technoluddite? (Score:5, Insightful)
How did "objects and IDEs don't solve every problem" turn into "objects and IDEs have little or no value"?
Silver bullet effect (Score:2, Insightful)
It's People (Score:4, Insightful)
Re:Bullets? (Score:3, Insightful)
By using XML instead of something simpler, the size of each network message being passed is increased tremendously, and the amount of processing required to create and decode the message is increase considerably compared to a simpler format.
Yes, the size can be decreased via compression, but then the messages become unreadable if you are tracing the connection somewhere in the middle (whereas a simple delimited message remains readable).
Silver Bullet Response Template (Score:3, Insightful)
If that doesn't work move on to:
$BULLET won't help you BECAUSE your programmers are retarded.
If that still doesn't have any effect...
$BULLET won't help you because your managers are retarded.
For BULLET in "Structured programming techinques" "Top down design" "Bottom up design" "Object oriented programming" C++ java XML "six sigma" "agile (or extreme) programming" scrum
Re:I've been in the business for nigh on 1/4 centu (Score:3, Insightful)
You are right on target. I have confused users with my creations for 2+ decades. I know over 10 languages, have been taught 15 or so, am currently conversant with about 3 (not counting markup constructions like HTML, XML,
Heck, when I worked for "HAL" we had a week long course on methodology. If fully implemented with all the requesite documents at each stage, all you would have is a CD full of documents and no product (no time).
I agree with you especially on job listings. These things are NOT written by the people who have a clue. They are more like shopping lists. HR asks for a skill set, some middle manager asks his workers what they know or are using (he doesn't know), that list is passed back, and HR tacks on 1-2 years for junior, 3-5 for intermediate, and 5+ for senior. And that is where you get silly things like "must know Java 1.4.02", like knowing 1.4.01 makes a person un-qualified. Yeah right.....
And the constant chase for the next best thing (management and techies). Had a manager which took a course in Total Quality Mangement (TQM). TQM, it seems teaches constant positive feedback. So every week I would get a memo telling me how good I was. The breaking point came when he called me into the office and asked "So what good thing did you do this week?".
Or the "Five Habits of Successful Suckers" series.
Yeah, it's a rant. I am SO tired of this bullshit. Give me a job, let ME interview the customer, get the F out of my way and let me complete the work.
Two unspoken words: agile and extreme (Score:5, Insightful)
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.
Re:Bullets don't kill people... (Score:3, Insightful)
As a manager you are tasked with developing software quickly and cheaply. I liken it to being a farmer. You can till the soil, plant the seeds, and pull the weeds, but you have no control over the basic requirements for success. You can not make the sun shine or the rain fall. You are at the mercy of forces outside your control, yet your survival depends upon the outcome. The farmer prays for rain or does an elaborate rain dance totally naked while smeared with mud of different colors (FYI farmers in the US gave up on the primitive practice of irrigation years ago in favor of the mud-smeared-naked-rain-dance).
As a manager you desperately look for something that will improve the odds of your survival. Since you cannot develop the software yourself, you try as hard as you can to find that silver bullet...
Re:Silver Bullets are just marketing (Score:2, Insightful)
Re:I've been in the business for nigh on 1/4 centu (Score:5, Insightful)
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.
Re:Well... (Score:3, Insightful)
IMarv
Re:I've been in the business for nigh on 1/4 centu (Score:4, Insightful)
It is no longer a fetish.
How exactly would you phrase that in a job listing? "Only people who 'get it' need apply"? Determining whether somebody does in fact "get it" is clearly best left for interview.
For examples, see my original posting. Let me give you an example of why the way job listing are usually written are broken.
Suppose you use WebWork in your application. So you say, "Must have three years of experience with WebWork". Now you have three engineers. Engineer A has worked on a WebWork based application for three years, although he has mostly been coding business logic POJOs. Engineer B has five years of Struts experience, and in the last six months has converted an application from Struts to WebWorks in anticipation of WebWork becoming Struts 2. Engineer C has been programming Java MVC applications for the web for ten years. He lead the development of an in house MVC framework in 1998, and has periodically done evaluations of Struts and WebWork, but neither has enough of and advantage to convert from the in house framework.
Under the criteria you have the job, only the least qualified candidate is going to get an interview.
Re:Bullets? (Score:2, Insightful)
That's probably the worst reason to use XML. What makes a database powerfull is that it can represent all relationships of data, not just the primary hierarchy of the data. XML does have a purpose, when you need to represent hierarchical data in a non-propriatary format that needs to be human readable or easily transferred between systems. Storing XML in the database directly is like driving to work 40 miles on the highway in your hybrid car, yes it works, but you loose some of the advantages that way.
Don't forget "Meta" Silver Bullets !!! (Score:3, Insightful)
Solutions vs Tools (Score:3, Insightful)
I think a lot of this comes down to the 'solutions mindset' vs the 'tools mindset'. A 'Solution' is self-contained, operates itself, and requires little thought. A 'Tool', on the other hand, requires a wielder (or operator), may need other tools to be effective, and requires thought and skill to use.
The problem is that computer technology, by and large, is much more a tool than it is a solution, while management tends to gravitate towards 'solutions'.
Most 'silver bullets' are in fact useful tools, if treated as such. When treated as a solution, they always come up short, because no tool, by itself, is a full-blown solution. The result is that management ends up using and discarding one silver bullet after another, rather than concentrating on gathering a useful set of tools and a group of people capable of using them skillfully.
Re:Bullets don't kill people... (Score:3, Insightful)
(ie. "we'll build a steel buidling, because steel is good - and we'll fasten the steel beams together with nails, because our carpenters know how to use nails.")
Then when it comes time to implement - the implementor starts the project already painted into a corner by the architect, and has to jump through all kinds of hoops via ugly hacks to get it to work.
System Architects who ignore low-level implementation details, architect systems doomed to failure.