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.'"

Comments

The Real Silver Bullet

[MarkByers]

Microsoft Vista! It's the silver bullet for everyone! Where do you want to go today? TM

Re:The Real Silver Bullet

[smittyoneeach]

You mean this stuff I've been quaffing for years is bogus? Piss!

Re:The Real Silver Bullet

[Zediker]

I thought the fact that it tastes like carbonated styrofoam water gave it away... no, im not a miller/budweiser fan... all american beers taste like carbonated water... its just a fact...

Re:The Real Silver Bullet

[Andrzej Sawicki]

Are you saying we are werewolves?

Re:The Real Silver Bullet

[ozbird]

Microsoft Vista! It's the silver bullet for everyone!

Silver bullet, or dum-dum bullet?

Re:The Real Silver Bullet

[Goose In Orbit]

Miller/Budweiser != All American beers (thankfully)

It's just that hardly any of the decent stuff gets to reach us on the other side of the pond...

Re:The Real Silver Bullet

[andrewman327]

This means that Linux is only used by werewolves! I knew it!

Seriously though, people need to learn that software is a tool. For example, houses would never get built without hammers, but you still need skilled workers putting in the hours to get it done.

Re:The Real Silver Bullet

[Pope]

I sincerely doubt that you have even tried "all American beers." There's more to the world of brewing than Miller, Bud, and Coors Light.

Re:The Real Silver Bullet

[iamwoodyjones]

After being at work for the last 12 hours, I'd say home :(

Re:The Real Silver Bullet

[jdbartlett]

Could you recommend an American beer? I've been in the country for a few years now, but remain reluctant to drink anything but imports after having tried a couple of Budweisers.

Re:The Real Silver Bullet

[Brian Boitano]

Wow, that site is awesome.

"Please type in your age."

"Please type in your age again."

"Please type in your age a third time."

"Coors light, the coldest tasting beer in the world."

Tastes cold, all right!

Re:The Real Silver Bullet

[rhaig]

find a local microbrew.

Re:The Real Silver Bullet

[metallic]

Just about anything from Samual Adams is good in my opinion. I'm a huge fan of their brewmaster collection and seasonal beers. Blue Moon by the New Belgium Beer Company is good as well as Anchor Steam from Anchor Brewing. Those are the only ones I can think off the top of my head right now.

Re:The Real Silver Bullet

[lord aDam]

Red Hook
Arrogant Bastard
Harpoon
Saranac
Blue Moon
Dogfish Head
Victory Hop Devil

And thats's just my short list for good American beer.

Re:The Real Silver Bullet

[gfody]

Correction, all Anheuser Busch beers taste like carbonated water.
Samuel Adams is a fine American beer.

Re:The Real Silver Bullet

[gfody]

Try a Sam Adams Summer Ale.
It's a seasonal brew only available til august.

Of course you need to try our micro brews - Gordon Biersch, Karl Strauss, BJ's etc. Checkout http://www.beertown.org/ to find one near you.

Re:The Real Silver Bullet

[fireman sam]

Samual Adams: Good for getting the taste of weed and hooker spit out of your mouth at 9:30am.

REF: see family guy

Re:The Real Silver Bullet

[Tablizer]

Microsoft Vista! It's the silver bullet for everyone! Where do you want to go today? TM

Seems wherever the viruses take me... :-)

Re:The Real Silver Bullet

[jdbartlett]

That ought to keep me busy/drunk!

Silver Bullets are just marketing

[Anonymous Coward]

It is our job as professionals to separate the hype from the reality. The parent is a troll....egads what has the software engineering world come to?

-ac

Re:Silver Bullets are just marketing

[ZTiger]

Problem is "professionals" are often order about by the ill-informed that seem to be incapable of listening or understanding the professionals.

Bullets?

[Anonymous Coward]

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.

Re:Bullets?

[CRCulver]

At least XML works. Instead of technologies, I'd be much more critical of development techniques that are pitched as silver bullets, like Extreme Programming. Remember that? All the rage a few years ago, with even level-headed publishers like O'Reilly getting in on the action --they even released a pocket guide, come on, what is this, devotion on the level of Mao's little red book? -- it was supposed to solve bottlenecks in development and result in cleaner, more easily maintainable code. Instead, all it did was make people blow a lot of money on books, and slow down output because in the XP you're supposed to code with your annoying coworker right there next to you with all his backseat driving.

If one codes in a way he's personally comfortable with, he can get the job done even if it involves a not globally ideal technology like XML, but when working methods are pushed down by above with no consideration for individual needs, that's dangerous.

Re:Bullets?

[Anonymous Coward]

Define "works"

Re:Bullets?

[BMazurek]

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:

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.

Re:Bullets?

[Xiroth]

If one codes in a way he's personally comfortable with, he can get the job done even if it involves a not globally ideal technology like XML, but when working methods are pushed down by above with no consideration for individual needs, that's dangerous.

Within reason, of course. If your code looks like this:

if( yes->strong )
yes->weak->run(fast);
b = when->walrus();
b.helloWorld();
delete b;

And it's suppose to be a generic method to manage mouse-clicks, the manager has some cause for complaint (and the rest of the team are likely looking to murder you the next time you nod off at your desk).

Re:Bullets?

[vadim_t]

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.

Re:Bullets?

[tfinniga]

As opposed to my generic walrus olympics opening ceremonies method?

Re:Bullets?

[mikek3332002]

and Here i thought it was about warewolf hunting tech.

Re:Bullets?

[smittyoneeach]

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?

Re:Bullets?

[Anonymous Coward]

In that case, your code is perfect. Carry on.

Re:Bullets?

[zootm]

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:Bullets?

[Haeleth]

Glad to see you enjoyed the Kool-Aid.

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:Bullets?

[Tom]

Absolutely correct! You need to verify that yes->weak->run is a valid function pointer before you call it, otherwise debugging will be hell. b.helloWorld(), on the other hand, should work fine even if it's not, provided you use the proper compiler.

Re:Bullets?

[cluckshot]

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:Bullets?

[vadim_t]

You kidding? It's trivial to make a program that generates something it can't parse back. Want examples?

void write_value(int handle, char *key, char *value) {
/* this is stupid, but not that hard to find */
 
    char buf[1024];
    strcpy(buf, key);
    strcat(buf, "=");
    strcat(buf, value);
    strcat(buf, "\n");
    fwrite(handle, buf, strlen(buf));
}
 
write_key(h, "example", " 2+2=4\n4*4=16");

Here you have a bit of code that very trivially writes something that can't be parsed back. Will the leading space be stripped? And even better, instead of that being written correctly, the data will be corrupted, with the first line being read normally, and the second being interpreted as key "4*4", value 16.

Encoding issues work the same way. It's trivial to write any random \0 terminated junk. It's a lot harder to correctly parse it back. What if the key is made of multi-byte characters, one of whose bytes has the value 61 (ASCII for '=')? A naive parser made for ASCII will sometimes correctly retrieve the key and value from an unicode file, but choke on the lines including characters it incorrectly interprets.

Re:Bullets?

[gutnor]

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++, ...

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, ..., 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.

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.

Re:Bullets?

[mobby_6kl]

> As opposed to my generic walrus olympics opening ceremonies method?

Yes, if those are just slimy fucking walrus-looking pieces of shit

Re:Bullets?

[Anonymous Coward]

Don't I wish it were that easy, I am sitting here trying to type with 6 pints (of beer)in my belly cause I have just watched an honest vendor lose a $5,000,000 contract. The opposition can in realatiy (or at least my perception of reality) can do less than half. The reason - NO MAGIC BULLETS.....

What is the difference between a software salesman and a used car salesman - the used car salesman knows when he is lying!

Why does this useless f'n game pays so f'n much. It would be much much easier if
A: I didn't care
B: The customer wasn't so bloody stupid and aware of when they were being sold a magic bullet!

I think my moto for the rest of the year (or until I I sober up) will be
Miracles happen - Magic is hard work!

SOFTWARE SUCKS!

Re:Bullets?

[hanshotfirst]

I agree with your original statement "It's trivial to make a program that generates something it can't parse back" -- That was the point of the article, I think - people are looking to the trivial solutions instead of putting in the effort to design non-trivial programs that are robust enough to handle real-world conditions.

The designer should know the boundary conditions for write_value(). If potential values may have characters embedded which are key characters to a later parser, then it needs to embed a form of escape for those characters. You have not included code for a trivial parser, but your comments imply it does a simple character match to parse out substrings of each line.

Making the following 2 trivial changes to your example will restore parseability, since you are reading a buffer at a time. If there is any possibility of your value containing "~~~" or "~~~" then just change the delimiter to some other easily-identifiable sequence that is unlikely to appear in your data. This may not be "trivial" any more, but it is still not a complicated solution.

void write_value(int handle, char *key, char *value) {
/* this is stupid, but not that hard to find */

char buf[1024];
strcpy(buf, key);
strcat(buf, "=~~~");
strcat(buf, value);
strcat(buf, "~~~\n");
fwrite(handle, buf, strlen(buf));
}

write_key(h, "example", " 2+2=4\n4*4=16");

Re:Bullets?

[Richard Steiner]

But XML is used in many situations where it isn't the best solution, like in system-to-system message formats where a simple delimited list of fields is far more efficient and at least as understandable to the trained eye.

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).

Re:Bullets?

[vadim_t]

Hehe, that pretty much proves my point. Look what we're getting into: We've started from a simple format. However, it turns out the problem isn't that easy to solve after all. So now you're piling up ugly workarounds. By the end of the project, this part of the code is going to end up as an unholy mostrosity. Seriously, read the links on that page to see what a mess you can make when coming up with your own format.

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?

Re:Bullets?

[hayden]

Java + XML = "Enterprise"

I hereby invoke Greenspun's 10th:

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Using XML as a programming language is the prime example of this. It is basically lisp with a different (but vastly more verbose) syntax and the more advanced concepts removed.

Re:Bullets?

[vadim_t]

In restrospect, that probably was a bit unclear. The good stuff is in the comments of the perl script, which lists all the problems with the format, includes links to the developer's explanation of the insane format and the bugzilla page suggesting doing something about it.

Re:Bullets?

[zootm]

Well, yes, XML is a data interchange format more than anything. On the other hand, it can be a useful representation of (simple) logical structures, which could be considered almost "progamming in XML". But no, in general, that's neither what it's for nor something it is useful for.

Re:Bullets?

[smallpaul]

I agree totally (from a very biased point of view). XML is not a silver bullet but if you've ever seen a two week project stretch into months as you discovered more and more quirks of the proprietary syntax someone handed you then you'll see the need for a standard. Does it solve world peace? No. Does it save the industry hundreds of thousands perhaps millions of dollars in parser-writing and subtly incorrect systems? Probably. I find it quite funny when people accuse XML of not solving an insoluable problem -- at the same time that they are declaring the problem insoluable! If a marketer sold you a solution to an insoluable problem then shame on both of you: the technology does not deserve the blame.

Re:Bullets?

[zootm]

Why does this useless f'n game pays so f'n much. It would be much much easier if
A: I didn't care
B: The customer wasn't so bloody stupid and aware of when they were being sold a magic bullet!

Yeah, that's kinda a problem with the complexity of the subject. People just buy what's best presented ("ooh, that's shiny!") because they're often completely incapable of purchasing things on the merits of the presented systems. This is something I've encountered a lot myself, and I've only actually been in this industry for a little over a year.

Re:Bullets?

[IMarvinTPA]

So, you want to represent data, heh?
Here are three choices I've gotten to work:
JSON
XML
CSV
Have you ever seen nested CSV files? They're truely bizzare to see, but if you have a sufficiently powerful parser, they can be read. New Line characters are to be record separators only when they are fully outside of quotes. Commas are to be used as field separators, only when they are fully outside of quotes. Quotes are to be used as content descriminators only when not doubled up.
The closest thing to a CSV spec that I've ever found.
My silver bullets of choice? Data encoding for transfer.
My next favorite silver bullet set, Web Services.
My other favorite silver bullet set, Programming Languages.

IMarv

Re:Bullets?

[BMazurek]

Your basic tenet seems to be, "Why reinvent the wheel."

Okay, why reinvent the wheel? S-Expressions have been around since the 60's. They are far simpler to understand and use than XML. They show the equivalence of data and code (von Neumann, anyone?) when considered in the context of Lisp. They are more economical than XML. In fact, it's hard to find a way in which they are not superior.

But this doesn't get us any closer to the issue you don't seem to grasp: XML is a data representation. The underlying problems still exist. What does the data mean? You've added a turtle between you and the problem. That's the XML parser. The XML parser really does very little for you. Now you walk a parse tree. It's a lot of effort for ver little payoff. To rephrase: It's not a silver bullet. Consider the S-Expression alternative in Lisp. Make methods out of portions of the code. But S-Expressions aren't a silver bullet either.

For more on this, there is a wonderful description by Erik Naggum that is worthy of serious consideration:
    http://groups.google.com/group/comp.lang.lisp/msg/ 9a30c508201627ee

Brad

Re:Bullets?

[IMarvinTPA]

• 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.
  • Gee, thanks, at least now I know what I'm getting verbosely.
• 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!) )
  • Awesome! Now I have found the perfect excuse for why I don't need to document my code! (I know I should...).
• Reduce database problem ( storing XML as blob in the DB - no need to call the DBA when you change the data format )
  • Yippie! Now, I just have to search using "XML_Blob LIKE '%<answer>42</answer>%'".
• Solve configuration problem ( now configuration file are in XML that means it is easy to understand )
  • Uh, I didn't realize I had a problem with INI files, now, how do I comment out an option?

Dear XML God, please save my soul.

IMarv

Re:Bullets?

[Anonymous Coward]

I bet you don't get a gold star next to "Works well with others" on your performance.

If one codes in a way he's personally comfortable with, he can get the job done even if it involves a not globally ideal technology like XML, but when working methods are pushed down by above with no consideration for individual needs, that's dangerous.

Was anyone else as scared about this statement as I was? Please don't make me work on this guys code... I've seen way to much "personally comfortable with" code already.

Re:Bullets?

[gutnor]

<reply> xmlgodquery element not found. Your prayer is not properly formatted. </reply>
<curse type="BurnInHell">Burn in hell, flat file format heretic !</curse>
</xmlgod>

Re:Bullets?

[Zerbs]

storing XML as blob in the DB - no need to call the DBA when you change the data format

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.

Re:Bullets?

[vadim_t]

Okay, why reinvent the wheel? S-Expressions have been around since the 60's. They are far simpler to understand and use than XML. They show the equivalence of data and code (von Neumann, anyone?) when considered in the context of Lisp. They are more economical than XML. In fact, it's hard to find a way in which they are not superior.

Can you have namespaces? You don't have to use them in XML, but it's something that certainly comes handy sometimes.

But this doesn't get us any closer to the issue you don't seem to grasp: XML is a data representation. The underlying problems still exist. What does the data mean? You've added a turtle between you and the problem. That's the XML parser. The XML parser really does very little for you. Now you walk a parse tree. It's a lot of effort for ver little payoff. To rephrase: It's not a silver bullet. Consider the S-Expression alternative in Lisp. Make methods out of portions of the code. But S-Expressions aren't a silver bullet either.

I don't get it. Did I say something different? XML is simply a way of encoding data in such a way that if you want to say, parse your browser's history or bookmarks you can do that using a standard library, instead of getting a headache trying to understand some horrible format in the style of "Mork" (see my other posts in the thread for links on it).

Of course it doesn't specify what the data means. Nor it should, because that's not the point of it. How the hell can any markup format do that, anyway? It's simply an unsolvable problem in this respect. Databases don't solve the problem either, but that doesn't make them useless, right?

But, since I don't know Lisp, please provide an example in XML and S-Expressions, with an explanation of how S-Expressions are better. I've seen your link, but it's completely useless. It's completely devoid of any technical information. It's a fairly amusing rant, but completely useless for the purpose of backing your point.

Re:Bullets?

[dindi]

Thank you ...

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("ThisIsTheFirstNameOfTheCustomeOfTheTrans action") during the transaction ...

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

Re:Bullets?

[IMarvinTPA]

Dare I ask what that would have looked like if I had sent it to the SOAP god? (Rhetorical question answered below.)
Although an error from the REST god would simply be an HTTP 400 Bad Request or 409 Conflict and contained the above..
IMarv
(Nice whitespace lost to slashdot.)
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope ">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:MalformedXML</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en-US">soapgodquery element not found. Your prayer is not properly formatted.</env:Text>
</env:Reason>
<env:Detail>
<e:myFaultDetails
  xmlns:e="http://soapgod.example.org/faults" >
<e:message>soapgodquery element not found.</e:message>
<e:errorcode>666</e:errorcode>
</e:myFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>

Re:Bullets?

[Jesus_666]

Also, XML is easier to reverse engineer than flat files. I'm currently in the process of reverse enginnering a rather simple format used in an RPG character management software, but even though it's just a plain ASCII file it's still annoying because the format does nothing to distinguish between the actual data, internal metadata and obsolete values (let alone signifying which value is which). When I'm done I will write a translator that turns the stuff into an XML document for use with my own software. Even without documentation this*...

<character>
<name>Drongo</name>
<birthdate>12-02-07</birthdate>
<height>189</height>
<weight>70</weight>
<isMale>true</isMale>
<hitpoints now="12" max="20" />
<level>1</level>
<exp>0</exp>
</charakter>

...is much more readabe than this:

Drongo
7
2
12
189
70
TRUE
12 20
1
0

While XML can't replace writing a good documentation it does make life easier when you have to interpret the data and don't have access to the documentation. It provides context.


* The examples don't reflect the actual formats, but they are similar, especially the flat file. The XML format is a rather hairy thing with internal non-XML namespaces which I don't want to inflict upon you.

Re:Bullets?

[hanshotfirst]

I'm not surprised to prove your point - I think we are in agreement at most levels. We've just gone though the usual routine of build a quick and obvious implementation - fix the bugs with a bandaid - repeat. Nasty. We each are making different assumptions about the parser, since the parser code is not displayed here. Even simplicity is not a silver bullet, demonstrating there is no shortcut to well-thought-out design, regardless of the implementation technology or methodology.

Re:Bullets?

[Antique Geekmeister]

Oh, there have been plenty. Remember when Java was "Write once, Run Anywhere"? Or when Perl would make all programs easy to write because there were so many ways to do the exact same thing? Or when LISP was hailed for its abstract programming, and turned out to be worse than XML for letting programmers handwave about made up functions that never actually got specified? Or Object Oriented programming? Or stylesheets?

Re:Bullets?

[Anonymous Coward]

Are you sure you've ever used XML? Your complaints about it indicate a lack of knowledge, or a troll. I'll give you the benefit of the doubt and assume you're stupid instead of malicious.

Re:Bullets?

[PitaBred]

But then you have to write your own parser, where you just dump the data into an XML parser and get usable data out of it. If you don't have the bandwidth, then I agree. But XML is definitely the path of least resistance in many data transfer applications.

Re:Bullets?

[BMazurek]

Of course it doesn't specify what the data means. Nor it should, because that's not the point of it. How the hell can any markup format do that, anyway? It's simply an unsolvable problem in this respect.

What if you came up with an XML DTD that could represent a Java program structurally? What if you then wrote a Java program to manipulate those XML data files? Then what if you wrote that program in your new XML-Java language?

The program is the code. The code is the program.

Now generalize the concept. For any XML data file, what if you could enhance your language so that the XML elements actually corresponded to calls (subroutine, methods, jumps, whatever)?

I've seen your link, but it's completely useless. It's completely devoid of any technical information.

The technical information is elsewhere. The movie trailer shouldn't tell you how a movie ends....it should encourage you to go see the movie.

For more trailers, I'd recommend many of the essays at http://www.paulgraham.com/

Re:Bullets?

[vadim_t]

What if you came up with an XML DTD that could represent a Java program structurally? What if you then wrote a Java program to manipulate those XML data files? Then what if you wrote that program in your new XML-Java language?

Why would I even want that in a format that's made for the markup of data? XML is perfectly well suited for one thing, creating structure in a document in a way that takes into account the problems inherent in the task. It's just like CSV, or the /etc/passwd format, only much fancier and usable for more purposes. This is history entry, and inside it, this is the URL, this is the timestamp, and this is the visit count. That's what it's for.

Not to mention, I don't think I even want any sort of executable code inside my data when I'm trying to load records into a database. Sure you could be really clever there, but that's one place where I really don't want infinite loops screwing up a batch process.

The technical information is elsewhere. The movie trailer shouldn't tell you how a movie ends....it should encourage you to go see the movie.

Then what's the point, I wonder? I'm not interested in reading rants that include more on politics and the state of the world than a technical issue it's supposed to be about. I notice you still haven't provided examples, btw.

Re:Bullets?

[sgt_doom]

This is extraordinarily humorous - seeing that it originates from Boeing...

Re:Bullets?

[BMazurek]

Why would you want that? You advocated for it. You said:

XML works by freeing you from the need to come up with your own format and a parser.

I simply point out that with sexp, here is your parsed data

data

Even better, here is you performing the desired operations on your parse tree:

(eval data)

Yes, it's just that easy. If that doesn't fulfill your requirement, why did you advocate for it?

Now, to make you feel a little more safe, as little or as much done during processing as you require....including nothing, if you're worried about your database issue. The data/code is inert until you try to execute it. That shouldn't be hard to understand...you do exactly the same thing (but with a lot more code) when you do it with XML.

I know it's a little scarey and seems a little spacey. All I can do is tell you that everything will be okay, and it will be an eye opener.

I notice you still haven't provided examples, btw.

You're right. Simple examples don't do it justice and your arguments don't indicate that you're really not interested in learning. But if you would like to learn, ponder defining methods for +, -, /, *, log....(they're inbuilt in most languages...I won't provide you with an implementation).

% (+ 5 (* 3 4))
17

Now, imagine a dialect where you define methods like html, body, head, etc that output html tags. Or a dialect that describes docbook. You define two sets of methods: one that downtranslates to html and one that translates it into LaTeX. Execute your code / data and you get the output you want.

If you don't see the utility, I'm not surprised. I understand. I've heard it said that most people don't really don't understand the power until they've done it for a couple of years. But once you do....they'll never go back.

If you are really interested in learning and not just saying "I don't get it", I recommend you pick up a copy of SICP - Structured Interpretation of Computer Languages. It's the first year MIT computer textbook. I have a B.Sc and an M.Sc. in Computer Science and 10 years in the industry since then...and I learned a lot going through the textbook about a year ago. Peter Norvig (Google's Director of Research) points out that SICP has an unusual Amazon rating distribution. It's double-humped: a large number of 0's and a large number of 5's with nto a lot in between. The speculation it comes down to people who get it, and people who don't. It's worth it if you get it...the names that seem to get it and advocate it are titans of computers and computer science.

I find it interesting that the people that are closest to XML are usually the people that are most vocal about the limitations and misconceptions of it, and talk most fervently about the benefits of things like sexps. The company I worked for had a precursor to XML that preceded it by about 7 or 8 years (before my time). We had Tim Bray as a founder. We purchased Microstar (yes, that one). I've worked with ex-Omnimark people. I can't explain why, but the people that are closer to working with XML...not at a high level, but at a low level seem to drift toward sexps as they go...

Just some observations...

Re:Bullets?

[vadim_t]

But we're talking about different things here.

XML is simply a way of formatting data, it's NOT supposed to be executable! When I'm loading records into my database, all I'm interested in an easy way of figuring out which is the URL and which is the timestamp. The parser gives me that, after that I can easily generate a SQL query.

I'm not saying that what you describe isn't useful, I'm saying that it's not WANTED for some purposes. In Perl I often make config files that are Perl scripts that when executed return a hash with the config data, and that can be really neat and useful, but sending Perl code through a socket to be eval'ed on the other end would be insane, and a security nightmare, and also would require a Perl interpreter on the other end.

I started this whole discussion to explain what XML is good for. It doesn't solve world hunger, or make coffee. It's not supposed to do calculations or do anything fancy. It's a way of providing structure to a document, which when fed to a parser results in a parse tree, freeing me from the issues of having to deal with charsets, delimiters and all that crap, and that's really all I want from it.

Re:Bullets?

[BMazurek]

I claimed XML is just a data representation. You claimed that XML gave you so much more than a data representation. If you do genuinely believe that, and like XML because it is a tool that offers you certain benefits, then it would seem logical to find the best tool to accomplish the task.

I simply point out that other tools that are even simpler than manipulating XML parse trees and have additional benefits that you might like.

Expand your toolkit. You may not like it. But at least you'll know the tool is there and what it can do.

At least you'll know.

Re:Bullets?

[vadim_t]

Huh? I claimed what? I described XML as essentially an evolution of constructs like CSV and the /etc/passwd format. I think I already said it about 20 times: XML is there to free me from the need to write a parser and dealing with all the annoying issues like encoding and delimiting data, because those issues take work to satisfactorily solve, and I have better things to do with my time than writing parsers for programs whose primary purpose has nothing to do with parsing.

Hell, it doesn't even have to be XML, Data::Dumper, Storable and YAML solve the same problem, only are rather less standard and have significant disadvantages.

Re:Bullets?

[BMazurek]

Huh? I claimed what?

You claimed that XML gave you so much more than a data representation.

XML is there to free me from the need to write a parser and dealing with all the annoying issues like encoding and delimiting data, because those issues take work to satisfactorily solve, and I have better things to do with my time than writing parsers for programs whose primary purpose has nothing to do with parsing.

Sounds to me like your original assertion:

XML works by freeing you from the need to come up with your own format and a parser.

I assert that a parsed XML tree really doesn't buy you that much. You must still walk your structure manually. Who does the semantic validation? How many XML instances in the wild use a doctype declaration? How many adhere to a DTD? Almost none that I've seen. They are ad-hoc constructions used to store data. The data representation format has value, but claiming the parser in such situations adds significant value is a silly argument. You must still do a lot of semantic validation as your code walks the data structures associated with the parsed instance. Even in instances that adhere to a DTD, if the underlying data is at all complex you'll have code that follows very closely what the DTD states....why can follow what in what contexts. Wonderful. But shouldn't all data in the system be defined in one place? Isn't that the whole rationale for the DRY principle? Why is it okay to duplicate it in this context?

According to your original argument, you like XML because it frees you from certain drudgeries. I say that it's great you're so impressed. Here is another tool that can free you from so much more. Give it a shot. You may discover ways to break chains you don't even know are there.

Re:Bullets?

[vadim_t]

Sounds to me like your original assertion

That would be because it is my original assertion

I assert that a parsed XML tree really doesn't buy you that much. You must still walk your structure manually. Who does the semantic validation?

You of course, who else? I don't really get what you're getting at. What do you propose as the alternative? ANY method of data input is going to require validation of some sort, unless you can be sure your data has already been validated, for instance by a database set up with check constraints and triggers that make sure nothing that doesn't make sense can get in, and that just moves the validation somewhere else.

Making your data executable isn't going to fix it, either. For instance in Perl I can make a config file that's a Perl script that returns a hash, but then I still have to walk and validate it in the program that uses it. Or I could make it consist wholly of function calls to the main program, but then those functions need to validate their arguments. You can't really escape from that.

The data representation format has value, but claiming the parser in such situations adds significant value is a silly argument.

Of course it adds significant value. Just try to extract something of interest from a complex format, like that Mork monstruosity Mozilla used. To reliably get a bit of data from something like that can easily require you to spend hours writing a parser for it. If it's stored in XML, you just link to an XML library, discard everything that doesn't interest you, and get the bit of data you want in just a couple of minutes.

For instance, I'd really love a C to XML filter. Sure the output would be horribly ugly, but unlike with C source, it'd be trivial to write a program that for instance outputs all the functions in a file and their arguments.

In Windows, if you want to get say, the list of the last URLs typed into IE, you just take the registry API, query the right keys, and get the results. I hope you're not going to tell me the API is not a significant value in comparison to trying to write code to interpret the contents of user.dat.

Re:Bullets?

[Richard Steiner]

Simple message parsers are trivial, and once one is written, it's just as convenient for reuse as Xerces or any other XML parser ... and it's a lot less complex.

For applications (such as airline Type B messaging) where customers are billed by data volume, it can make a large difference financially as well -- bandwidth is not the only consideration.

Silver Bullet in a Concealed-Carry Revolver

[Anonymous Coward]

Consider the following scenario. You have told your boss, in total honesty, that your software code will need 8 weeks to complete. Your boss cuts your time to only 4 weeks and then pressures you by hinting that he may fire you if you do not comply with the new accelerated schedule.

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.

Re:Silver Bullet in a Concealed-Carry Revolver

[CRCulver]

In this case, if you under 18 years of age...

How many software firms hire 16-17 year-olds?

Re:Silver Bullet in a Concealed-Carry Revolver

[Anonymous Coward]

Judging by the quality, quite many of them.

Re:Silver Bullet in a Concealed-Carry Revolver

[cerberusss]

If you are over 18 years of age, you need to weigh the situation carefully.

HOLD IT RIGHT THERE buddy. That sounds an awful lot like BDUF.

Re:Silver Bullet in a Concealed-Carry Revolver

[Mjlner]

"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."

You don't live in the US, do you? In the US, persons under the age of 18 are tried, convicted and executed on a regular basis. Well actually, they aren't being executed until later on in life (nowadays), since the appeals process does take some time.

Re:Silver Bullet in a Concealed-Carry Revolver

[umghhh]

While walking the earth (and working for big corporations) I encountered countless technologies you can qualify as silver bullets. They all come wrapped up in shiny packages and beside obvious help in technical work are usually supposed to find cure for cancer, eliminate poverty and among many other things arange peace for the world. Alas I hardly remember what they are all about. But I recall two that managment team tried on us:

1. faultless software policy
2. '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.

Re:Silver Bullet in a Concealed-Carry Revolver

[mobby_6kl]

Judging by the quality, quite many of them.

Why did you choose to insult my abilities as a software developer?

Re:Silver Bullet in a Concealed-Carry Revolver

[Anonymous Coward]

Dude.. that only works if he is a werewolf.. or possibly a vampire.

Re:Silver Bullet in a Concealed-Carry Revolver

[G-funk]

Because you're 18 years old, you're in a 7-11, you don't know shit about shit AND PULL UP YOUR PANTS!

Well...

[Capt James McCarthy]

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.

Re:Well...

[Anonymous Coward]

If Vendors would stop preaching that they are the next 'silver-bullet' then perhaps this would stop.

There are *two* reasons for this.
1. the previous silver bullet didn't work.
2. people really cannot learn.

Re:Well...

[archeopterix]

If Vendors would stop preaching that they are the next 'silver-bullet' then perhaps this would stop.

This sentence might be true, but is meaningless. Vendors will do whatever sells. Period.

It is not the techs who decides what comes in and what goes out. It is normally driven by cost.

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.

Re:Well...

[ultranova]

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.

Why ? Think about it from the management's point of view. The choices they face are:

1. Listen to the your tech department and make a decision based on their (hopefully realistic) estimate. The company continues steadily onward and you get fired since you didn't manage to improve it, and therefore the stock doesn't rise enough to meet the stockholder's demands.
2. Listen to claims you know full well are sweet lies and make estimates based on them. The company gets a hopelessly overoptimistic estimate on its future fortunes, the stock price goes up, and you get a fat bonus. When the lie is found out, you can claim that you were lied to and can't be blamed for anything.

Which one should a sane manager choose ? Getting fired or getting a bonus ?

Re:Well...

[zymurgy_cat]

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.

Re:Well...

[julesh]

When the lie is found out, you can claim that you were lied to and can't be blamed for anything.

At which point the CEO looks at you, looks at the marketing material you reported to him as truth, looks back at you, back at the marketing brochures, and fires you for being hopelessly naive.

Re:Well...

[plopez]

You forgot: "brush up resume to show your accomplishments and get a better job elsewhere before the chickens come home to roost". By the time the disaster hits, you should be ling gone.

Allow you successor to reap what you have sown.

HTH

Re:Well...

[IMarvinTPA]

You're assuming the CEO isn't hopelessly naive. If he is, then you're still safe.

IMarv

Re:Well...

[Hoi Polloi]

You aren't safe because the company may be doomed due to poor leadership (and you'll go down with it).

Re:Well...

[IMarvinTPA]

There are levels of safe that include other benefits.
If the company fails, you get unemployment. If you get fired, you don't.

IMarv

Re:Well...

[Anonymous Coward]

Tell that to the workers from Enron

Re:Well...

[Shadowlore]

Why ? Think about it from the management's point of view. The choices they face are:

      1. Listen to the your tech department and make a decision based on their (hopefully realistic) estimate. The company continues steadily onward and you get fired since you didn't manage to improve it, and therefore the stock doesn't rise enough to meet the stockholder's demands.
      2. Listen to claims you know full well are sweet lies and make estimates based on them. The company gets a hopelessly overoptimistic estimate on its future fortunes, the stock price goes up, and you get a fat bonus. When the lie is found out, you can claim that you were lied to and can't be blamed for anything.

Which one should a sane manager choose ? Getting fired or getting a bonus ?

I think the real question is "Which one would an ethical manager choose?

Re:Well...

[freedom_india]

YEAHHH ! Right !!!

The CEO is a Virgin Mary and am Elvis Presley...

Sheesh what a naive statement. Enough to make me throw up my morning coffee...

Here around

[aepervius]

it is RUP, ITIL. Now everybody in the management swear by those. Naturally softwaer engineer are forced to draw nice UML diagram before those are sent in gigantic 98 pages document to the otusourcing team, for a change which should have taken at most 20 hours we get weeks of works. I would accept it if this was linked to an increase of quality of code, less bugs, and lower end cost. But this is not. Still this has been declared a success by our management.

Re:Here around

[Anonymous Coward]

Regarding UML, this article from the same author is good :

http://www.acmqueue.com/modules.php?name=Content&p a=showpage&pid=130

Re:Here around

[Some Bitch]

Don't blame ITIL because your change management process is broken, ITIL is just a framework not a step by step instruction manual.

strangly this whole thing

[atarione]

  <grab refreshing beverage>Coors Light

  <message>made me want to drink a Coors Light - The Silver Bullet....luckily lust in time I realized Coors Light is terrible
  </message>

</sarcastic +5 funny whoring>

Re:strangly this whole thing

[Anonymous Coward]

Your XML is off. You needed a tag.

<shudder />Too much XML coding for me, I think.

Re:strangly this whole thing

[indifferent children]

Your XML is off. You needed a tag.

Fortunately, /. has non-validating moderators.

Re:strangly this whole thing

[not-enough-info]

Since we're into making OT silver bullet references...

In the Marine Corps, "Silver Bullet" is the term used for the rectal thermometer the corpsmen stick you with.
It's mostly just a homophobic scare tactic to get everyone to drink water and not malinger.

UML and managers

[cerberusss]

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!"

Re:UML and managers

[mwvdlee]

My department is being sold to LogicaCMG in a few months...

Re:UML and managers

[cerberusss]

LOL, nou de ene manager is niet de andere. Het was daarnaast toendertijd CMG, niet Logica.

Re:UML and managers

[smutt]

You should do what I did when that exact same thing happened to me. Leave!

Re:UML and managers

[Anonymous Coward]

Not atypical. I work for them (hence anon).

A complaint made about me recently: "you know what the problem with you is? You know what you're doing."

Re:UML and managers

[Anonymous Coward]

I once blew an interview (well, maybe I was already done at that point) by making fun at tools that generate gargantuan UML class diagrams from a codebase, with each box carrying comprehensive lists of methods and variables. Such diagrams are generally posted on a wall and become part of the manager's office decor, along with the Microsoft Project charts.

After making that remark, I noticed that my interviewer (a manager) wasn't laughing.

Re:UML and managers

[cerberusss]

I'll never forget when the going got tough a few years back. CMG tried (and succeeded) laying off some twohundred engineers by using a loophole in the law. If I ever talk to their recruiters, I'll definitely give them a piece of my mind.

Re:UML and managers

[cryfreedomlove]

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.

Re:UML and managers

[julesh]

Is it just me who, if told to do some software projcet "using UML" that really wasn't appropriate for it, who would turn up to a meeting a few weeks later and say "What? You didn't mean User-Mode Linux?"

Re:UML and managers

[Prof.Phreak]

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.

Re:UML and managers

[G-funk]

Hey, I know some UML. Enough to use it. I'm no ninja or anything but enough. And I put it on my resume. I'll tell you why I have to put in on my resume, because it's a bullshit-buzzword. I've had so many job descriptions that require UML, and the a couple of the last few jobs I've had all "required" UML, and you turn up and find that it's not used at all, or there's an out-of-date class diagram somewhere on the fileserver.

Sorry, no sale :p

[tibike77]

As opposed to China or India, however, my outsourcing plan would focus on a small town in Romania - for it is only in Transylvania where the werewolf can be hired to work with an unrivaled vigilance to avoid the whiz of silver bullets.

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) ?

Re:Sorry, no sale :p

[indifferent children]

ever heard of Cluj-Napoca

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:Sorry, no sale :p

[sharkey]

What about wooden stakes and garlic?

Re:Sorry, no sale :p

[acklenx]

Of course not... they'll put the "Cluj" in the box and ship it!

Re:Sorry, no sale :p

[tibike77]

Ok, I thought I knew a thing or two about English in general, even slang too (and there's always google to the rescue or urbandictionary, still nothing)... so, what's wrong with "Cluj" anyway ?

Re:Sorry, no sale :p

[Anonymous Coward]

Cluj sounds a whole lot like Kludge...

Re:Sorry, no sale :p

[Scarblac]

It's the name of the town. He didn't say the companies were named that (though I had to check Google first to realize that...)

Re:Sorry, no sale :p

[Eccles]

It looks and sounds much like kludge, a clumsy or inelegant solution to a problem.

Re:Sorry, no sale :p

[Chris Abernathy]

It will bring the word "Kludge" to mind for many English speaking software-types ...

http://en.wikipedia.org/wiki/Kludge

Re:Sorry, no sale :p

[gr8dude]

I happen to speak Romanian as well; "Cluj" - as the others have noted, will remind people of 'kludge', which is certainly not a welcome thing in software.

For the other slashdotters - 'Cluj' is prononced as 'Klooj' (as the 'ouge' in the French 'rouge'), so it doesn't sound like a kludge to a native romanian.

Stop the BLAME GAME!

[SerpentMage]

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.

Re:Stop the BLAME GAME!

[mwvdlee]

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.

Re:Stop the BLAME GAME!

[tezza]

I could not agree more. Alex E. Bell is Preaching to the Converted.

But worse, has he opened his eyes?? Is he so *blinkered* that he does not see that Silver Bullets exist in all spheres of human activity?

Failing Football Team? just add Wayne Rooney
Global Warming? just change your lightbulbs to savers
Middle East Crisis? just send in Condaleeza Rice
Endemic Crime? everyone would be fine if there was Education, Education, Education.

This guy needs to get out more.

Re:Stop the BLAME GAME!

[DoofusOfDeath]

How about those that preach Open Source will solve all problems? Or how about Ruby? What about Perl, Java, Linux?

I agree with you 100%. Those people are just wrong-headed and can't be reasoned with. It's Python that accelerates software development.

Re:Stop the BLAME GAME!

[indifferent children]

It's Python that accelerates software development.

In our shop, it's Java that accelerates software development, and I don't mean the programming language.

Re:Stop the BLAME GAME!

[Mr. Underbridge]

I think it's mainly high school and college kids saying Ruby (or whatever) will solve everything. Anyone in the real world knows better.

Re:Stop the BLAME GAME!

[DoofusOfDeath]

I know this is kind of off-topic, but since we're talking about Python anyway...

The reason I thought to make that joke about Python in the parent posting is that in reality, I really *am* tons more productive in Python than in Java or C++. I found that when I went from C++ to Java, I got maybe a 1/3 reduction in the time it took to complete comparable projects. My Python projects probably take only 50% as long to complete as comparable work in C++.

Have you guys had similar experiences?

I suspect it has to do with the following issues:
(1) I don't need to think about deleting objects properly, in most cases.
(2) When debugging, most things have a string representation that I can
        print with very little programming effort.
(3) A very useful set of of built-in container types: dictionaries, lists,
        sets, etc. And unlike C++'s STL, it takes very little code to use them.

To be fair to C++/Java, as my codebases get bigger, I do sometimes start to wish that Python cleanly supports the notion of "interfaces", so that I can use them to document what methods I need a class to provide. But in general those problems get shaken out pretty early in testing anyway, so it's not that big a deal to not have explicit interfaces.

Thoughts?

Re:Stop the BLAME GAME!

[Anonymous Coward]

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.

No, the problem is with the entire notion of there being a "silver bullet".

No one tool is idea for all things. Sure, OSS or Ruby might be good for some things...but Windows and VBScript are good for something else. You need to be able to identify the right tool for the job in front of you, and stop trying to cram your favorite tool into a task it just was never designed for.

Re:Stop the BLAME GAME!

[LWATCDR]

You left out Ajax and Web 2.0

People need to understand that good tools do not replace the craftsman.
It is possible to write a good program in Visual Basic, Perl, forth, c, or even 6502 assembly.
All good tools do, is make the work go faster. But there is a limit to even that. It takes time to care.
I do think that some programing languages are better than others. I hated Forth, and I refuse to lean any language that is tied to one operating system. Those are my likes and choices. Unlike a lot of people I like Java I think it is the best solution for some of the tasks I do.
I find Perl fast for quick and dirty programs and for quick CGIs.
I use PHP for web applications but frankly I find it kind of finicky as far as compatibility between versions.
c is c. It is simple and powerful but I really like objects.
C++ is c with objects tacked on. Better than nothing but the lack of a root object that everything is a descendant of bothers me.
Fortran, COBOL, and Basic I learned in college and high school. Not much use to me now. I do remember that I really didn't like COBOL.
Pascal was the first programing language I learned and I really did like Modula-2.
Maybe I will fall in love with Python or Ruby. Smalltalk interests me but it seems to be a bit of a walled garden like Java. Not really at home on the any OS.
I would probably love Objective C on Mac 0S/X.
I am afraid that we live in a imperfect world. No easy answers except good tools and hard work.

Re:Stop the BLAME GAME!

[AuMatar]

I find I can program at least an order of magnitude faster in plain C (or occasionally C++ used as C with classes) than Java, and 2 orders over Python. The pure simplicity of C makes it far easier to use. And I prefer deleting my own objects, not only are my programs more efficient for it, but I find doing that kind of maintenance on your own makes you think about cleanup and error handling properly. Plus I don't have to swear when my code breaks due to me using spaces to indent and some other dev using tabs (Python, I'm looking at you).

In the end, it comes down to how the developer thinks. C fits very naturally into my mindset- tell it what to do succinctly and don't get fancy. And I find the code written in this style is far, far, far easier to read, debug, and maintain than pretty much any Java or Python I've ever read. YMMV.

Re:Stop the BLAME GAME!

[bnenning]

I really *am* tons more productive in Python than in Java or C++. I found that when I went from C++ to Java, I got maybe a 1/3 reduction in the time it took to complete comparable projects. My Python projects probably take only 50% as long to complete as comparable work in C++.

Have you guys had similar experiences?

Absolutely. Of all the languages I've used, Python puts up the fewest barriers between my thoughts and converting them to working software. It's certainly not a magic bullet because it won't do your thinking for you, but I'm significantly more productive in Python with 6 months of experience than I am in Java after 10 years.

Re:Stop the BLAME GAME!

[Anonymous Coward]

>> It's Python that accelerates software development.
> In our shop, it's Java that accelerates software development, and I don't mean the programming language.

When he said that Python accelerated their software development, he wasn't talking about a programming language, either...

I mean, why do you think they call him DoofusOfDeath? :-)

Silver Bullets works just fine

[lmoelleb]

There is abselutely no problem sticking to your silver bullet.... Instead of choosing the right tool for the task, choose the right task for the tool. This also ensures you don't waste your time with web development as there is no tool that is right for web development, just tools that suck slightly less than the others. :)

Re:Silver Bullets works just fine

[j-pimp]

This also ensures you don't waste your time with web development as there is no tool that is right for web development, just tools that suck slightly less than the others. :)
GVIM works pretty well for me. I also use NVU for RAD prototyping. Oh and I auctually wrote a useful webservice in C# using SharpDevelop so that counts as well.

The sad part is vim sucks the least of these three, although SharpDevelop is starting to support the ASP.NET thing pretty well.

Re:Silver Bullets works just fine

[John Nowak]

All web development sucks if you consider the fact that ultimately HTML gets involved. Toss in CGI and/or Flash and you might as well just kill yourself now and get it over with.

Re:Silver Bullets works just fine

[heson]

Yeah, why cant we use hypertext enabled laTeX for the web.

Bullets don't kill people...

[PinkyDead]

... - 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.....

Re:Bullets don't kill people...

[MosesJones]

Hello! Welcome to idiot town... population you. You'll want the train to Cluesville, it leaves at seven.

Most of these Silver Bullets are great ideas

A silver bullet is something that will produce an order of magnitude increase in project performance. I take it that you have read the world's best book on Software Development haven't you? I'd recommend the 25th aniversary edition with the Silver Bullet essays in it.

Sure there are good technologies, and idiots who implement them badly. The whole point of the article with in reference however to technologies that make claims that contradict Fred Brooks's essays and the muppets who keep thinking "hey it must be true, its on a poster". They are NOT Silver Bullets, there are no such things as Silver Bullets.

If you haven't read Brooks you shouldn't be in IT.

Re:Bullets don't kill people...

[PinkyDead]

And, equally, I would recommend TFA to you - if you haven't read it then you shouldn't be replying to my post. Try to keep in context instead of showing off that you've read a book.

Alex Bell describes XML as a 'Silver Bullet' - he is alluding to the notion of a Silver Bullet being a technology that can actually solve a significant number of problems, but that is taken up by the ill-informed as being capable of solving all problems. This is not Brooks' original meaning of Silver Bullet, but is one which has come to be a common understanding of the term. This is why he put's the term in quotes.

XML is a great idea but XML is often used badly and XML is heralded by those that don't understand it as 'the solution to all our problems'.

Those are the only points I made - but please, feel free to beat your Strawman to death.

Re:Bullets don't kill people...

[MosesJones]

From the article
"There are plenty of examples in the software engineering realm that demonstrate blatant disregard for Fred Brooks's sage advice asserting that there are no silver bullets"

And oddly your claim that This is why he put's the term in quotes I can't quite find the bit in the article that says "Silver Bullet" in quotes.

So you've read neither the article nor the book?

Re:Bullets don't kill people...

[digitalgiblet]

The "silver bullet" approach makes perfect sense if you imagine for a moment that you are a manager trying to deal with software development. There is a 99% chance that you have a management background, not a technical one. There are exceptions, but even managers who had a technical background are unlikely to have an understanding of the current technical ecosystem.

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:Bullets don't kill people...

[jafac]

The basic source of this problem is "System Architects" - who, as part of their design methodology, avoid "implementing" (ie. looking at specific details of technology) in designing the system.

(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.

Re:Bullets don't kill people...

[Tablizer]

Most of these Silver Bullets are great ideas, but give them to some moron who half knows how they work...

But this is probably also true of the things they replace. The best COBOL programmers are probably many times more productive, including maintenance, as the average Java programmer.

Re:Bullets don't kill people...

[jsiren]

Says Jafac, on system architects:

"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."

This is a very good analogy. Where this steel project fails worst is not the decision to use steel, nor the decision to assemble with nails, although these two are in direct and obvious conflict, which could have been avoided.

The failure of this kind of a project is ignoring the expertise within the company (the carpenters, who could have told the system architect that nails are for wood); they know how to use wood at the company, without additional training, which is an advantage over steel.

For the fictional construction company, the transition to steel - i.e. the first steel building project - would have incurred significant overhead because of the need to gain expertise by means of training and recruitment, which would only be worthwhile if the costs could be reasonably expected to be recovered in a reasonable time, so that future steel buildings could be made at a profit. In other words, it's as much an investment as any other.

The IT business is as much a business as construction. The "silver bullet" promises to be a once-and-for-all solution to some particular problem, which may not be very well defined: "install this and never worry about single sign on!" Silver turns into lead when the problem turns out to be something completely different from what the vendor promised to solve: this single-sign-on software doesn't solve the problem of integrating several legacy user databases with incompatible data; this virus scanner and that firewall won't solve the problem of Joe Friendly User responding to a "security advisory" from his bank, requesting that he verify some personal information...

To find the solution, you must first define the problem. I think the silver bullet ends up many times creating a ragged, bleeding exit wound in its user's foot because the target hasn't been well defined. Just like any bullet, it must be aimed very carefully, or it will do more harm than good.

--js/fi--

Re:Bullets don't kill people...

[WNight]

There are many silver bullets. Go into the average C shop and give them Python or Ruby. Watch how much quicker all the "mundane" stuff gets done. Some critical piece of OS code might still need C, and they'd probably use it for glue, but regexes, complex data representations, networking, and many other things would fly.

What there aren't, is one-size-fits-all silver bullets. What's revolutionary to someone else may be mundane, or irrelevant to you. But as far as single changes that can more than double productivity (if used properly), there are many.

That said, most projects that I've seen have failed because of implementation issues... Teams who use the numeric primary key to look up the item name, then use string comparisons to check it against others, rather than using the guaranteed unique primary key... They could have used an optimized boyer-moore string search to speed this up, but it wouldn't fix the design. For projects/teams like this, there is no magic technology because whatever it is will be misused.

Untried bullets

[Knick-Knack]

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.

Re:Untried bullets

[Saint Fnordius]

In other words, the silver bullet is only useful if you have the right calibre gun.

Re:Untried bullets

[Knick-Knack]

Quite. Brilliant.
I think we've invented a new adage.

Re:Untried bullets

[bzipitidoo]

To paraphrase an NRA slogan, bullets don't kill projects, people kill projects.

It doesn't matter how good planning systems or ideas are, if management insists on abusing them to hide things, gloss over details, avoid doing Real Work, evade hard questions, and deny reality, projects will almost certainly fail. UML, flowcharts, and such like can be useful, but they are easily abused too. Yet, part of the problem may be that these planning tools do lend themselves to abuse. These tools lead some people to think they can predict and schedule that which is inherently unpredictable. I once had a PHB whose brilliant plan was:

1. Whip up a project plan in UML, by himself, in one morning.
2. Ignore or disparage all our input, protestations, requests for clarifications, feedback and simply order us to carry out his plan.
3. For the failure, blame everything but himself. Most especially blame it on our lack of faith in UML. If there'd actually been some success, then take all the credit, because it's plans that count, not implementation details.

However that PHB was so wrongheaded and clueless (and absolutely determined to refuse to admit he didn't know what the hell he was doing), no system could've helped him. He'd ask stuff like whether we thought it would take 1 week or 2 weeks to achieve something, and not ask the rather more crucial questions of whether that something was a good idea, or possible. Anyone who tried to raise such issues would get squelched. Then he'd of course point to the questions he had asked as evidence that he was working with us and getting our feedback. It didn't help that his equally clueless boss, a man who religiously tried to ram everything, however unknown or impossible, into The Schedule, seized on this dreck as fodder for his work. It wasn't sane steps that were being scheduled, it was all goals of unknown difficulty that were being scheduled. Can't blame that sort of thing on UML. Anyone have any examples of projects where good people were led astray by tools such as UML? Perhaps a case where the engineers knew their business and had picked and hammered out planning methods that worked for them but management suddenly required they switch to UML, and the result was poor? I can't see UML causing such a problem-- seems it would be fairly easy to take a good plan and dress it up in UML style.

Current silver bullets

[Anonymous Coward]

.NET and thin clients feature heavily in my day to day role. Trying to argue that turning an existing C++ thick client with literally hundreds of dialogs into a web service based .NET application is pointless. Management believe that this is the way forward and therefore we have to deal with it. Now we're half C++, half .NET, half thick, half thin bastard child which consumes twice the resources of the old product and all the budget is allocated to business functionality so we can't complete the job they told us to start.

Re:Current silver bullets

[VAXcat]

Just be glad you're not old enough to have gone through the fourth generation language management wars...managers were convinved by that hype that we could buy thes products and then we'd be able to get results by talking to the computers in English, just like the ones on the Enterprise in Star Trek. Instead, some incredibly resource wasting applications were produced, that had to be communicated with in a strange dialect of broken English - sort of a machine pidgin language...

Webservices are todays silver bullets

[Laz10]

XML as the simple thing it is, works perfectly.
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.

Re:Webservices are todays silver bullets

[freedom_india]

What do you mean "It reminds me of a few years ago when ..." ???

You are not from the future, right?

Re:Webservices are todays silver bullets

[DrXym]

I wouldn't say XML is a silver bullet, but the act of forcing you to structure your data and use extremely robust libs to read / write it sure has its benefits. I wish in fact that all apps read and wrote their configs through common libs. Something akin to PAM, but for config files would be an enormous benefit to Linux where every app and its uncle seems to use a different format.

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.

Re:Webservices are todays silver bullets

[NotZed]

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.

Re:Webservices are todays silver bullets

[Jesus_666]

How exactly are XML Schemas something bad that grows on top of web services? A Schema is a way of defining the structure of an XML document in another XML document. And IMO it's easier to use than DTDs.

There is always a meta-layer

[Anonymous Coward]

Don't blame inappropriate, blind, forcing of new methods and tools upon developers by ignorant, parroting managers on that methods and tools - those are someone's successfully deployed solutions which didn't work elsewhere, as they could had been expected not to.

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.

Why 'silver bullets'?

[Peter Mork]

So, what's a 'silver bullet' supposed to be good for? Killing werewolves, right? (Or wererats or warehouses or werecanaries.)

Given that it's really only good for one extremely limited function, why in the world does a 'silver bullet' represent a solution to a wide range of problems?

Re:Why 'silver bullets'?

[Anonymous Coward]

They're not only good for killing were*s, they'll kill anything. Hence the term 'silver bullet' being applied to a solution to a wide range of problems.

Re:Why 'silver bullets'?

[Calinous]

Silver bullets were presumed to be much more precise in firing than normal lead bullets - I saw this in an american movie (but I don't remember which)

Re:Why 'silver bullets'?

[Tim Browse]

Sheesh

Kids today.

Re:Why 'silver bullets'?

[jc42]

Silver bullets were presumed to be much more precise in firing than normal lead bullets ...

I remember seeing the explanation of this in an old Lone Ranger movie: Because a silver bullet is so expensive, you don't fire them off in volleys like people do with lead bullets. You take careful aim before you pull the trigger.

Unfortunately, the usual management approach with silver software bullets is to supply them to the entire staff, and demand that they be fired at every target at every opportunity.

There's a serious danger of metaphor overload here. But sometimes it help if you have some idea why the metaphor arose.

Re:Why 'silver bullets'?

[Anonymous Coward]

I think the author is referring to Rocky Mountain Gold, aka Coors. It's the silver bullet and it works every time. I've been known to be wrong.

Re:Why 'silver bullets'?

[Anonymous Coward]

Well, when all you have are silver bullets, every problem looks like a Werewolf!

Re:Why 'silver bullets'?

[Tablizer]

So, what's a 'silver bullet' supposed to be good for? Killing werewolves...?

I catapulted my copy of "Java UML Web Services with XML Ajax 2.0 Unleashed" right into the heart of a werewolf, and it worked! Woffie's dead as a log!

TFA is shallow hogwash

[Qbertino]

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.

Re:TFA is shallow hogwash

[LarsWestergren]

Oh, so buzzwords can be used to disguise laziness and bad implementation? Where's the news?

Yes, it is yet another article that can be summed up by "Some technologies are overhyped and used inappropriately".

Re:TFA is shallow hogwash

[Idolatre]

There's no "right" way to represent something in XML, it depends on your application's context. In some contexts, it may be perfectly valid to have different data types for utterance_in_a_state_of_speechlessness and utterance_in_a_state_of_happiness. I may have two different classes for representing UtteranceInAStateOfSpeechlessness and UtteranceInAStateOfHappiness (both inheriting from the Utterance base class) with different attributes specific to each type of utterance, and want them to be deserialized from XML to the right class. Or I may want spechlessness utterances to initiate a process that attempts to resolve the speechlessness problem, while happiness utterances are simply logged in a database (for the purpose of generating a monthly report of hapiness utterances) and acknowledged.

Don't try to be too generic for your context, it would lead to:
<message>
    <event>Utterance</event>
    <eventParam name="state">Speechlessness</eventParam>
</message>,
which would be the XML equivalent of having a std::vector<void *> (a typed container that holds untyped values). If that's then submitted to a generic DoAnything web service, it would then mean your web service will contain code to route that message to the right place, instead of letting the programming language/web server/integration engine route the request to the right class/orchestration based on method name and data type.

It's fine to try to be as generic as possible, but the right balance between genericity and specificity is different from one context to another. So my idea of having two different data types for different states of utterances may just be additional overhead for some contexts, and then you would be right to have a generic Utterance class with a state and no subclasses.

Re:TFA is shallow hogwash

[poot_rootbeer]

For one: 'utterance_in_a_state_of_speechlessness' should be 'utterance state="speechlessness"'

Why not a 'state type="speechlessness"' parent node with an 'utterance' child? After all, it is an utterance IN a state of speechlessness...

Open-endedness can be a curse. There are too many valid ways to specify any data structure in XML. And yet, you invariably end up having to deal with someone who chose a horribly INVALID way to do it. It's quite a phenomenon.

Fred Brooks original silver bullet paper

[jonv]

Fred Brooks original silver bullet paper

Re:Fred Brooks original silver bullet paper

[Anonymous Coward]

Thank god! Someone else notices that this is a PAPER - not an ARTICLE.

Here's a tip for the /. ed's

- if it has references at the bottom - it's a 'paper'.

If you cant spot the difference between writing styles from a 'paper' and an 'article' you're a pretty pathetic journalist - go back to university .

*sigh*

[hagbard5235]

I am currently involved in a lot of remediation of silver bullet stuff. Don't get me wrong. I love XML, get a lot of milage out of using UML to drive MDA tools, am an advocate of publishing web services etc. The problem is, so much of it is done in an ass hatted way. And then I get called in, late in the project, to tell folks exactly how screwed they are.

The root problem is people using tools they never bother to even vaguely understand. If you aren't going to bother to understand the technology, please don't use it. Please, I'm begging you, you'll just screw it up. Or at the very least, find someone who *does* understand the tech to advise you.

Re:*sigh*

[Jellybob]

I feel for you - I'm working at a small design/web agency which seems to be populated by people who really want to avoid knowing anything about how the web, or the tools we use work.

The problem here is that it's very cultural - the manager doesn't want to know the details, and refuses to accept that squirting ink on a piece of paper is not something you can compare developing web applications to - I'm building a site for his other company at the moment, and one of the "specifications" is that all content for a page should be visible without scrolling.

And I put specifications in quotes, because his idea of giving a spec is to draw a couple of interface ideas, wave at it, call you Reg a lot, and then wrap up the meeting. Any questions about processes get waved away as details, and then when the project is over budget, past deadline, and nothing like what the client asked for, it's our fault.

Not that I'm bitter or anything.

Technoluddite?

[SoupIsGood Food]

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

Re:Technoluddite?

[wildBoar]

How did this solve your problems ?

Re:Technoluddite?

[Anonymous Coward]

I'm guessing that there was only one code-base to maintain (the one server-side).
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:Technoluddite?

[Peter La Casse]

Apart and aside from the fact he sees little or no value in things like objects or IDEs

How did "objects and IDEs don't solve every problem" turn into "objects and IDEs have little or no value"?

Re:Technoluddite?

[Jerf]

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.)

Re:Technoluddite?

[smallpaul]

"Objects and IDEs don't solve every problem" is a self-evident truth

"Marketers over-hype things" is also pretty widely understood.

So what is he saying that is actually interesting? It would be much more productive to write an article on the appropriate limits of the use of particular technologies than to spew truisms as if they were deep wisdom.

Re:Technoluddite?

[Penguinoflight]

Objects mostly slow you down when writing code, and although an OO approach should make code easier to read, it usually makes the code significantly longer. For a few situations OO code is still better, but unless it's necessary it usually has little value.

Re:Technoluddite?

[Anonymous Coward]

Apply some critical thinking here -- the company he works for (Boeing) does what? Do they work with financial data? Or
are they doing something less ethereal like, say, building airplanes?

Re:Technoluddite?

[nasch]

Isn't it possible this was a slow, fragile, poorly-designed system that got rewritten? It sounds to me like the fact that it got rewritten probably had more to do with the solution than the fact that it became a web service.

Re:Technoluddite?

[sgt101]

This is rubbish.

If it could have gone away due to a change in client, why not change to a simple client without using HTTP - instead using any TCP/IP based messaging system.

Just doesn't ring true or mean a damn thing.

Re:Technoluddite?

[ralphdaugherty]

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.

      Everyone who is Sun or AS/400 knows you don't know what you're talking about, so I guess that leaves a small group from the Windows arena who may buy it.

  rd

Re:Technoluddite?

[Anonymous Coward]

"he writes in an inpenetrable victorian style"

This should be a clue that you are what we call mentally challenged. It would seem that everyone else was able to understand it. Perhaps something's wrong with the rest of the world?

I'll ignore the logical inconsistancy of your first line, as I suspect it would take too much effort to explain it.

Before you go calling the Pot Black, you might want to take a look at your own statements, as you come across as a complete idiot.

Re:Technoluddite?

[Tablizer]

Then we went to a web-based client, sort of like AJAX before people started calling it AJAX, and all the headache went away.

That is because decent GUI widgets are a relatively *old* technology, invented in the 70's, commercialized in the early 80's and matured by the early 90's. The web is just taking the long and winding road to implimentating biz Gui's decently.

Re:Technoluddite?

[usidoesit]

>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. That'd be a thing called "defining the problem" or even "contacting the problem", since nobody ever does this. Nobody. That's why anyone who does the simplest first step of going towards the problem seems to walk on water.

Silver bullets ..

[Anonymous Coward]

Clearly a hunter loot.

Hmmm.

[drolli]

Either you know what you are doing - or not.

Software development is a pathological case

[Archtech]

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.

references but not links?

[gizmo_mathboy]

I know this is nitpicking but how can one have an article that uses superscripts for references but not links?

Do I fault the author or the publisher?

Asshats

[Jaxoreth]

The problem is, so much of it is done in an ass hatted way.

I think you mean 'half-assed', unless your problem is getting rooted by script kiddies.

The root problem is people using tools they never bother to even vaguely understand.

Ah. I stand corrected.

Flow Charts - UML

[Anonymous Coward]

I started out learning flow charts.
I migrated to strucured software development and PDL.
I learned Yordon-Demarco data flow diagrams.
I learned and began using UML.

It seems like we learn new technologies every few years that bring incremental improvements. However, software development is still stuck in a very manual, very craftman-like paradigm.

I too worked on a project that thought XML and web services were the solution to all the problems of man and machine. All must be controlled by the BEPL.

A one size fits all solution (common with silver bullets) is NOT the answer. We need to think beyond that and use ALL the tools at our disposal.

When will software development really achieve the gains that it is capable of? When will it be a mix between the skilled craftsman creating the low-level, optimized components, and the journeyman creating the final product from skillfully reusing the stable, optimized, well-tested components (or objects or libraries or web services)?

Sound analogy

[bjk002]

If we equate "Manager who buys into this crap" with the werewolf, and watch as said manager's project(s) fail miserably, in the end, the silver bullet has/will effectively done/do its job.

I've been in the business for nigh on 1/4 century

[hey!]

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.

Splendid stuff!

[Rogerborg]

Reading this article has instantly solved all of my project management problems!

Silver bullet effect

[chrism2202]

When you find a silver bullet, you usually end up shooting yourself in the foot.

It's People

[xbytor]

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.

Silver Bullet Response Template

[Greyfox]

$BULLET won't help you if your programmers are retarded.

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

More than just XML

[Gr8Apes]

He rants about UML as well, and the effects of UML and XML and WSDL and WebServices and design issues such as strong typing versus weak typing, although I couldn't figure out if he was for or against weak typing. For API/integration layers, I prefer "weak" typing, as your API becomes cleaner by passing more generic data. I've personally seen a project where the integration API was around 400 methods defined for the API to essentially support about 5 functions, because there were multiple parameters possible for each call.

What he was really ranting about was the "integration" problem, via data modeling, protocols, and architecture, and the fact that all the silver bullets for this have pretty much just shifted the burden of real work somewhere else. I agree with him on this. Whether that was intentional, I don't know, but everything he lists was pretty much spot on for integration. (He did mention a couple of side uses: XML for configuration and UML for Use Cases which do not necessarily apply to integration).

I recall one project where we had to write the design doc and use cases for a bit of code first, to follow process. The problem? Well, this particular design was an adapter for a properietary internal undocumented API. That means that to be able to write the design doc accurrately, we had to write the code.

Process violation! Alarm bells going off. Men in black suits swing down from the ceiling.

Ok, so it wasn't that bad - but we wrote the code while doing the design doc, and then spent the 4 weeks of "build" time refactoring the code to actually be maintainable at a leisurely rate. Actually wound up being a win-win situation. The only reason we were able to do this was because the normal UML guys (BAs in our case) were completely clueless about the internals of the system and didn't even know where to begin drawing use case diagrams. Otherwise, I'm sure we would have gotten a nice set of useless diagrams like "user sits at computer", "magic happens", "user happy", please fill in "magic happens".

The old saying

[vertinox]

When all you have are silver bullets, all problems look like a werewolf.

Alternatives to silver bullets

[ch-chuck]

Other things to try are

1) Stake thru the heart
2) Garlic worn around the neck
3) Holy water
4) Crucifix
5) Sunlight

Re:Alternatives to silver bullets

[Anonymous Coward]

Beheading would be a good choice if you find yourself mistaking wherewolfs for vampires. It kills surprisingly many things.

Re:I've been in the business for nigh on 1/4 centu

[RetroGeek]

Amen!

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, ...). I forget how many "methodologies" I have been exposed to.

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.

Tagging Beta

[DesireCampbell]

I tagged this story 'werewolf' :)

What would BOFH do?

[RoboProg]

--clickety--

Company policy against that sort of thing you say? I'm not sure, you'll have to look in the backup vault, in case we had it archived.

--slam--

Two unspoken words: agile and extreme

[technoCon]

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.

Re:Two unspoken words: agile and extreme

[Anonymous Coward]

"In preparing for battle I have always found that plans are useless, but planning is indispensable." -- Dwight D. Eisenhower

Re:Two unspoken words: agile and extreme

[kabdib]

If you plan, and you adhere slavishly to the plan (BUFD / waterfall / etc.) , you are screwed. You'll have an unworkable plan, and a mess, because you didn't know what you were doing.

But if you don't plan (pure agile / "verbal documentation" / just hacking away), you are also screwed. You'll have an unworkable mess because you didn't know what you were doing.

The common thread I've seen is: Successful systems are done by smart people who know what they are doing. How did they come to know that? They failed a lot, and studied at the feet of masters (who similarly failed).

Around the third or fourth time I do something, it's pretty damned good. Initial efforts usually suck. Brooks again: "Plan to throw one away. You will anyway."

"the" silver bullet in IE

[mp3phish]

position: relative;

Use it in every element, it is the silver bullet to fix every CSS bug that IE contains.

WRONG

[amliebsch]

FYI, you need to update your talking point. The Supreme Court has already held that executing minors is unconstitutional. See Roper v. Simmons.

Inability to deal with complexity

[Aceticon]

For a couple of years now, i've been entertaining the theory that a great many people in IT (especially managers) have trouble dealing with tradeoffs, side-effects and feedback loops whenever a choice has to be made on how the development process is to be setup/changed. The longer the chain of side-effects, the more complicated the feedback-loops or the less self-explanatory/measurable the tradeoffs, side-effects or feedback-loops are, the more likelly they will be ignored or not understood.

Hence the common practice (in some countries) of selling impossible deadlines to customers and then using overwork to (try and) achieve those deadlines, when, via the "tired developers make more bugs" and the "low morale" negative feedback loops, overwork usually leads to LONGER development times and a long tail of bugfixing after release but before the software is accepted for production.

The same theory could also explain the recurring reliance by some managers on the next "silver bullet" to solve all their problems - silver bullets are always sold as solving everything and having no downsides (thus no tradeoffs) and no side-effects (and thus no negative feedback loops).

Re:Inability to deal with complexity

[g8oz]

The longer the chain of side-effects, the more complicated the feedback-loops or the less self-explanatory/measurable the tradeoffs, side-effects or feedback-loops are, the more likelly they will be ignored or not understood.

A brilliant way to put it!

It applies to politics as well. Witness the Iraq invasion, the idea fits perfectly.

Inability to deal with complexity

[Aceticon]

For a couple of years now, i've been entertaining the theory that a great many people in IT (especially managers) have trouble dealing with tradeoffs, side-effects and feedback loops whenever a choice has to be made on how the development process is to be setup/changed. The longer the chain of side-effects, the more complicated the feedback-loops or the less immediatly obvious the tradeoffs, side-effects or feedback-loops are, the more likelly they will be ignored or not understood.

Hence the common practice (in some countries) of selling impossible deadlines to customers and then using overwork to (try and) achieve those deadlines (via the "tired developers make more bugs" and the "low morale" negative feedback loops, overwork usually leads to LONGER development times and a longer tail of bugfixing before the software is accepted for production).

The same theory would also help explain the recurring reliance by some managers on the next "silver bullet" to solve all our problems - silver bullets are always sold as solving everything and having no downsides (thus no tradeoffs) and no side-effects (and thus no negative feedback loops).

No Silver Bullet but a Silver Hammer

[Latent Heat]

I wanted to buy a box of 20 gauge shotgun shells, but that was in a glass case under lock and key while stacks of boxes of high-power 30 caliber hollow point cartridges were on open shelves in anticipation of deer season.

When I finally got someone at Wal Mart to open the glass case, the dude asked "how many boxes?" After the big production to get at them, I meekly asked for one box, but I thought of saying, "How bad a shot do you think I am?"

Back to the original topic, Brooks lists "High level languages" as a "Silver Bullet" -- they are perhaps not a silver bullet, but I am hard pressed to doing everything in macro assembler. OO is perhaps not a silver bullet, but I am so accustomed to that feature that I am reluctant to give that up either.

The one doubt I have about OO is that there will always be a need to bundle data with functions that operate on that data, and the Lisp/Haskell/OCaml people keep talking about closures and related things. I have the uneasy feeling that if OO is not the silver bullet it is then the silver hammer (everything looks like a nail) and that we are reinventing things that had been figured out in Lisp with OO, UML, Design Patterns, and all of the crazy things we do with objects.

If what your really need is to pass a pointer (OK, OK, reference) to a function conforming to a desired signature and what you end up doing is defining a class, creating an object instance, and passing an object reference to get such a thing to get at that one function, OO is the modern Cobol -- it has the functionality you need, but you have to type in a lot of boilerplate code to get it.

Re:I've been in the business for nigh on 1/4 centu

[julesh]

I've seen programming paradigms come and go (structured programming)

Structured programming is gone? I hadn't noticed.

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".

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.

Mod Parent Down! Article is Satire

[Anonymous Coward]

The article was satire! He was saying that XML doesn't do everything. Go reread the article; you obviously misunderstood it.

You must have modded yourself up - there's no other explanation.

Re:I've been in the business for nigh on 1/4 centu

[hey!]

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.

Re:I've been in the business for nigh on 1/4 centu

[hey!]

Structured programming is gone? I hadn't noticed.

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.

He needs a thesaurus

[Anonymous Coward]

After seeing the word "silver" used for the 29th time I'd say he was guilty of depending on a gimmick in his writing.

Don't forget "Meta" Silver Bullets !!!

[MrData]

I am surprised Mr. Bell did not mention the latest wave in Software Development, "Meta" Silver Bullets, ie nebulous heuristics which are neatly packaged and given an MBA friendly label. Currently the mother-of-all Meta Silver bullets is "Agile Development" , which has only proven successful for the guys who write books about it and sell seminars on the subject.

Corrollary

[rewt66]

When the problem you have is a werewolf, all your tools look like silver bullets.

If you don't get it, think of it this way: When your problem is driving a nail, all your tools look like hammers. Yeah, you can drive a nail with a screwdriver (if the nail is small enough) or a wrench, but hammers work better.

But in software development, most problems turn into werewolves eventually, so...

Re:TFA is shallow hogwash MOD UP!!

[bensch128]

Wow, mod parent UP!! He hits the nail right on the head.

My viewpoint on the article is that the author got what he deserved. He gave out a
vague description of his problem so he got a vague solution back.

I was recently reviewing a software design document that correctly paid much-needed attention to the objective of supporting configurable behavior. As opposed to simply documenting how the design would accommodate said configurability, the design description also included the following commanding statement a number of times: "The configuration data will be stored in XML." I

He gets what he deserves!

I'm starting to get extremely annoyed when bosses just say "implement configurable behavior" or "just make the system work right" or "just use your best thought" and then come back to you compiling that the system doesn't work right. Of course it doesn't work right. The boss didn't put any thought into what he actually wanted!! This is why design documents are a waste of time. They are completely unrelated to reality since reality WILL BE THE CODE!! So program smart, program agile/XP/http://martinfowler.com/ieeeSoftware/cont inuousDesign.pdf/

Cheers
Ben

Solutions vs Tools

[Oloryn]

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:Solutions vs Tools

[jake-in-a-box]

Good thought. The way I see it, it's management that is supposed to be the solution to the problem. They (we) use tools to manage. As you say, we get lazy and try to get the tool to be the solution. That's abdicating responsibility. In literature they call it deus ex machine, Arther Clarke called it "any sufficiently advanced technology." I call it F.M. - the cargo-cultish belief that someone (John Frum?) else will take care of the issues.

Hmm, I read that article in Queue more than a month ago. I think we are pretty far afield from the original. ...hence my sig: To hear the gods laugh, tell them your plans...

It depends on the definition of 'Silver Bullet'

[sheldon]

I didn't much care for TFA, as I thought he was as simplistic as the people he complained about.

You're right, people who propose that Open Source is the secret to all problems, without really understanding what the problem is and have no answer as to how Open Source could solve that, are problems.

The same is true of any technology. Obviously the reason why a new technology was created because somebody perceived a problem with the old technology. Why do we use XML rather than comma-delimited files? Because XML includes definition of the data, rather than having to also ship a seperate document which describes what's in the CSV file.

However, the other truth is that new technologies introduce new problems. It may be slower to parse an XML file than a CSV file, the XML file may take up much more space on disk, etc. Are these problems show stoppers for your implementation? That depends.

That's the key. It all depends.

I think what TFA was really complaining about, when he gave the example of the using XML for configuration, is that there was no detail as to why. Why was XML chosen instead of other methods?

All technologies suffer from this, and the problem with zealots is that they fail to address those issues.

I keep following the Ruby on Rails discussions here on /. and elsewhere trying to understand what it does for me. Thus far I'm not impressed. Much of what the zealots point to as strengths, I already have using VS.NET wizards with ASP.NET 2.0. I can drop a data connection on a page, and I can have it automatically implement the CRUD functions when I attach the connection to an editable grid view, etc.

The wizards work great when you are tossing together a sample, or a very simple application. Where they fall down is because most apps aren't that simple, and you start having to do joins and manipulation of the data and such, which is why we build our own custom data layer.

What I haven't seen from the zealot's discussion is evidence that they've gone beyond the simple applications yet.

The same is true of the marketers. If you go through an ASP.NET training webcast, they'll show you the wizards too. They want you to think how easy this all is... woo hoo. buy it now. The reality is a bit more complicated, but there are aspects of the easy stuff you can use, like binding a grid to a dataset or better yet a collection of business objects. It just isn't as easy to demo and market.

I'm open to any new technology, but I'm going to think through it's ramifications. While I don't like people who advocate a hammer for ever screw... I also don't care for people who argue for the devil we know and lose track of the benefits of the new devil.

Re:No Silver Bullet but a Silver Hammer

[Jesus_666]

we are reinventing things that had been figured out in Lisp with OO, UML, Design Patterns, and all of the crazy things we do with objects.

We are even reinventing the design principles behind the Lisp syntax. ;)

Re:I've been in the business for nigh on 1/4 centu

[radtea]

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.

For a given value of "our". As you point out, some people get it, some don't. The people who don't are called "managers".

The older I get, the more convinced I become that certain types of brain damage are common amongst managers. Toward the end of his life my father had a series of small strokes that damaged his temporal lobe. Although he could still read and write, carry on a conversation and do some kinds of reasoning perfectly well, he more-or-less lost his ability to estimate the time a task would take, to sequence events, and to understand that simultaneous actions are exclusive (that is, while a person is doing X they cannot at the same time be doing not-X.) My mother actually noticed the first effects during a trip when he suddenly became incapable of understanding that it was going to take five hours to get between points A and B. He could follow the argument, but the result was meaningless to him.

I have observed exactly the same deficits to be common in project managers. I think it might be instructive for one of these groups doing fMRI studies to have a look a manager's brains and see if they have any temporal lobe deficits. It would really explain a lot.

Re:I've been in the business for nigh on 1/4 centu

[asuffield]

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.

Indeed. My take on all this is that people just don't care all that much about whether a given project is successful, or whether the product is any good. Sure, they'd like it to happen, but it's not all that important to them and they aren't going to go out of their way to make it happen. The industry seems to encourage this attitude.

After all, there will always be another project after it, so you'll still get paid. And if the product sucks, you can simply delude yourself that it didn't, by revising your objectives to match what was produced. Finishing the project is the only thing that counts, not how well it works or how much better it could have worked.

"Silver Bullet" beer sucks

[gordonb]

My friend Bill and I made a serious study of this several years ago. We had a blinded pair-wise taste test of beers, which included all premium beers available in cans in Sna Antonio, some 16 brands at the time. These were poured by Bill's wife Linde into identical chilled mugs and the tasters were blinded.

In an attempt to assess the reliablility of the ranking and the reproduciblilty of the test (kappa statistic), many pairs were re-tested.

After over 400 pair-wise taste tests, the winner was, believe it or not, Schlitz Beer. I was stunned. I always viewed Schlitz as a rather low class piss, but was I wrong. Interestingly, Anheiser-Busch products occasionally scored well but exhibited marked variablility in quality, apparently from batch to batch.

Coors scored poorly - next to last- which happened to confirm my opinion of the company and Mr. Coors' politics

P.S. I usually drink St. Pauli's at my house, but in the cooler on the boat, it's no longer blue runners but Schlitz.

Re:"Silver Bullet" beer sucks

[NeoBeans]

My friend Bill and I made a serious study of this several years ago. We had a blinded pair-wise taste test of beers, which included all premium beers available in cans in Sna Antonio, some 16 brands at the time. These were poured by Bill's wife Linde into identical chilled mugs and the tasters were blinded.

Wow! I've heard of people being blinded by grain alcohol, but I've never heard of a microbrew so strong that it blinded tasters! :-)

Re:I've been in the business for nigh on 1/4 centu

[greywire]

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.

IBM is developing memory storage that is essentialy the same as punched cards on a microscopic scale.. http://www.zurich.ibm.com/st/storage/millipede.htm l.

Hope you cave is well furnished. :)

Transylvania? Who?

[RomulusNR]

Look, now, it's *vampires* that are from Transylvania, not werewolves. Silver bullets work on werewolves, not vampires. Vampires need a stake through the heart or sunlight. Now get it right, dammit, or everything else you say is meaningless.

Re:No Silver Bullet but a Silver Hammer

[il_diablo]

I think what he was referring to here about HLL, OO, and the other technologies you cite is that, at their time of inception, they were considered THE "silver bullet".

Think back to when all your examples were first introduced. They were touted as the fix-all. After the market hype died down, technical folks were able to sort the wheat from the chaff and figure out just WHERE in their processes these new technologies could fit (if at all!).

It was only after this point in the "solution lifecycle" that the tech became indispensible, because it FINALLY was just used to do what it was good for, not everything management and vendors billed it as.

Depends on how you factor the code.

[HornWumpus]

Some OO implementations are more like onions then others. Some coders apparently think complexity hiding means to obfuscate needlessly.

But good coders were basically writing OO code before the language was inforcing for them. They just used different buzzwords. Calling Functions on data structures is an awfull lot like calling a method of an object.

Consider...

[Anonymous Coward]

Consider the following scenario. You have told your boss, in total honesty, that your software code will need 8 weeks to complete. Your boss cuts your time to only 4 weeks and then pressures you by hinting that he may fire you if you do not comply with the new accelerated schedule.

Since the manager is just looking for a date to pacify his boss (or client, in a smaller company), don't fret this. Agree. Then, when the delivery date comes make up a reason for the delay and throw in a "and this is good because" bone for him to take upline. Remember, he's now committed to you in the project -- it's halfway done! -- and CAN'T fire you without jeopardizing the project further. YOU have HIM over a barrel once the project is underway.

Been there. Done that.

That does it...

[Tablizer]

I'm convinced. I'm gonna trade in my oversold silver bullet for a golden hammer!

It's the Programmers - not the Tools.

[Moe1975]

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

offtopic

[cmr.Pent]

Sorry to be off topic, but could you please contact me cmr.Pent(a)gmail.com or somehow tell me your email? It's regarding FastDIB library.

Re:offtopic

[jdbartlett]

Because we weren't offtopic already!

Character

[Khelder]

The character theme is one that is in Stephen Covey's "7 Habits" books. In Principle Centered Leadership, for example, he emphasizes that you cannot be a good leader without good communication, which requires trust, which requires that you be trustworthy. I'd recommend the book for anyone in a leadership role.