Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

The Whiz of Silver Bullets 244

Posted by ScuttleMonkey from the you-wont-have-to dept.
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.'"
This discussion has been archived. No new comments can be posted.

The Whiz of Silver Bullets More

The Whiz of Silver Bullets

Comments Filter:

  • The Real Silver Bullet (Score:4, Funny)

    by MarkByers ( 770551 ) on Wednesday July 26, 2006 @04:32AM (#15782525) Homepage Journal
    Microsoft Vista! It's the silver bullet for everyone! Where do you want to go today? TM

  • Silver Bullet in a Concealed-Carry Revolver (Score:4, Funny)

    by Anonymous Coward on Wednesday July 26, 2006 @04:41AM (#15782554)
    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.

    • Comment removed based on user account deletion
    • 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.

    • "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 [ncadp.org] on a

    • 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 occ

  • Well... (Score:5, Insightful)

    by Capt James McCarthy ( 860294 ) on Wednesday July 26, 2006 @04:42AM (#15782558) Journal
    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... (Score:4, Insightful)

      by archeopterix ( 594938 ) on Wednesday July 26, 2006 @06:01AM (#15782721) Journal
      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... (Score:5, Insightful)

        by ultranova ( 717540 ) on Wednesday July 26, 2006 @06:47AM (#15782825)

        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... (Score:3, Interesting)

      by zymurgy_cat ( 627260 )
      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.
  • 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.

    • Stop the BLAME GAME! (Score:5, Interesting)

      by SerpentMage ( 13390 ) on Wednesday July 26, 2006 @04:59AM (#15782593)
      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! (Score:5, Insightful)

        by mwvdlee ( 775178 ) on Wednesday July 26, 2006 @05:35AM (#15782657) Homepage
        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.
      • 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! (Score:5, Funny)

        by DoofusOfDeath ( 636671 ) on Wednesday July 26, 2006 @06:31AM (#15782791)
        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.
      • I think it's mainly high school and college kids saying Ruby (or whatever) will solve everything. Anyone in the real world knows better.
      • 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

  • UML and managers (Score:5, Funny)

    by cerberusss ( 660701 ) on Wednesday July 26, 2006 @04:48AM (#15782569) Journal
    Overheard while doing an internship at Logica CMG [logicacmg.com]:

    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!"
    • My department is being sold to LogicaCMG in a few months...
    • 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.
      • 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
    • 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?"

  • Sorry, no sale :p (Score:4, Interesting)

    by tibike77 ( 611880 ) <tibikegamez@yahoo. c o m> on Wednesday July 26, 2006 @04:49AM (#15782572) Journal

    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) ?
  • 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. :)
    • 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 [vim.org] 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.

  • Bullets don't kill people... (Score:5, Insightful)

    by PinkyDead ( 862370 ) on Wednesday July 26, 2006 @05:02AM (#15782599) Journal
    ... - 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.....
    • 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

    • 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

  • Untried bullets (Score:4, Interesting)

    by Knick-Knack ( 162724 ) on Wednesday July 26, 2006 @05:04AM (#15782602)
    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.

  • Webservices are todays silver bullets (Score:3, Insightful)

    by Laz10 ( 708792 ) on Wednesday July 26, 2006 @05:15AM (#15782622)
    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.
    • 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 (Score:4, Interesting)

      by DrXym ( 126579 ) on Wednesday July 26, 2006 @05:33AM (#15782652)
      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.

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

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

    • Sheesh [berkeley.edu]

      Kids today.

  • TFA is shallow hogwash (Score:4, Interesting)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Wednesday July 26, 2006 @05:30AM (#15782650)
    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.
    • 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".
    • 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 f

  • Fred Brooks original silver bullet paper (Score:5, Informative)

    by jonv ( 2423 ) on Wednesday July 26, 2006 @05:31AM (#15782651)
    Fred Brooks original silver bullet paper [berkeley.edu]
  • 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, ple
    • 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 fo

  • Technoluddite? (Score:5, Insightful)

    by SoupIsGood Food ( 1179 ) on Wednesday July 26, 2006 @05:45AM (#15782679)
    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? (Score:5, Insightful)

      by Peter La Casse ( 3992 ) on Wednesday July 26, 2006 @07:26AM (#15782955)
      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"?

      • "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? (Score:3, Interesting)

      by Jerf ( 17166 )
      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

  • Software development is a pathological case (Score:5, Insightful)

    by Archtech ( 159117 ) on Wednesday July 26, 2006 @06:07AM (#15782727)
    There can be few examples of an advanced industrial activity in which the ultimate decision-makers know so little about the technology involved, and have so little respect for the opinions of those who do.

    "Hope springs eternal in the human breast" - indeed, in business (and especially sales) optimism is highly thought of, and realism often denounced as "cynicism" or "negative thinking". This is all very well in activities involving human beings, who can easily be manipulated through their emotions. However, it fails utterly when confronted with the cold, hard facts of the physical world.

    When someone seems to be unrealistically hopeful, we speak of "getting a reality check". In other words, finding our noses hard up against the brick wall of ineluctable, unarguable facts. The problem with most software development projects is that the ultimate decision-makers - those who have the gold and, therefore, make the rules - are very rarely able to get a reality check until the project runs out of time, money, or both. They are hopelessly ill-equipped to make reasoned, educated judgments based on the arguments presented by vendors, analysts, and their own technical staff. So it's hardly surprising that over-optimism tends to creep in.

    I have been giving talks about software engineering for about 20 years now, and I usually stress the fact that "there are no silver bullets". This warning is always greeted by vigorous nodding, knowledgeable smiles, and sometimes applause. Afterwards, I sadly feel, the people who have just agreed that there are no silver bullets go out into the exhibition hall or open their magazines, and resume... looking for silver bullets.

    Ultimately, I see just two ways out of this dead end. Either decision-makers take the time, trouble, and mental effort to learn the necessary basics about software development and maintenance. Or they start choosing technical managers and architects who really know their stuff - and trust them implicitly. As time goes by, I hope that both these things will happen more and more.

  • I've been in the business for nigh on 1/4 century (Score:5, Interesting)

    by hey! ( 33014 ) on Wednesday July 26, 2006 @07:20AM (#15782935) Homepage Journal
    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.
    • 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 wit

      • Re:I've been in the business for nigh on 1/4 centu (Score:5, Insightful)

        by hey! ( 33014 ) on Wednesday July 26, 2006 @10:32AM (#15784528) Homepage Journal
        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.

  • Splendid stuff! (Score:4, Funny)

    by Rogerborg ( 306625 ) on Wednesday July 26, 2006 @07:40AM (#15783018) Homepage
    Reading this article has instantly solved all of my project management problems!
  • When you find a silver bullet, you usually end up shooting yourself in the foot.

  • It's People (Score:4, Insightful)

    by xbytor ( 215790 ) on Wednesday July 26, 2006 @08:44AM (#15783566) Homepage
    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 (Score:3, Insightful)

    by Greyfox ( 87712 ) on Wednesday July 26, 2006 @08:46AM (#15783580) Homepage Journal
    $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

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

  • Alternatives to silver bullets (Score:3, Funny)

    by ch-chuck ( 9622 ) on Wednesday July 26, 2006 @09:10AM (#15783782) Homepage
    Other things to try are

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

  • Two unspoken words: agile and extreme (Score:5, Insightful)

    by technoCon ( 18339 ) on Wednesday July 26, 2006 @09:29AM (#15783946) Homepage Journal
    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.

  • Inability to deal with complexity (Score:3, Informative)

    by Aceticon ( 140883 ) on Wednesday July 26, 2006 @10:01AM (#15784244)
    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).

  • Don't forget "Meta" Silver Bullets !!! (Score:3, Insightful)

    by MrData ( 130916 ) on Wednesday July 26, 2006 @11:25AM (#15784962)
    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.

  • Solutions vs Tools (Score:3, Insightful)

    by Oloryn ( 3236 ) on Wednesday July 26, 2006 @11:44AM (#15785140)

    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.

Slashdot Top Deals

"In the long run, every program becomes rococo, and then rubble." -- Alan Perlis

Close