software development bywords

Trends and fashions are amusing to observe, regardless of their actual merits (by which I mean that some are alternatively driven by marketing, or popularity). The software development world (no way am I going to condone the word "blogosphere") may be essentially susceptible to passing fancies, because of the difficulty in getting software development done right, on time, and within budget. Anything promising a marginal advantage is worth a look-see.

One characteristic that made me chuckle recently was the tendency to either coin or co-opt words, then repeat those words as a sign that one is "in the know". Hence, those words are bywords to prove which "side" someone is on. Again, the worth of ideas or movements expressed by a software development byword is not what I'm addressing here; those ideas of substance can be batted around endlessly by people other than me who (think they) have more familiarity with them. My point is only to call attention to the fact that bywords seem to garner so much importance.

Some food for thought, writing ™ after each byword:

1. How long until someone decides to sell an agile™ alcoholic drink?
2. When will there be an RFC for Web 2.0™? Did I miss the RFC for Web 1.0™? How about Enterprise 2.0™?
3. Speaking of enterprise™, what was the magic point at which Linux suddenly stopped being a hobbyist's toy and started being a business tool?
4. If I make a POJO™ that extensively relies on and calls into external tools to do many common tasks, is it still a POJO™?
5. What are the last remaining gaps in WS-*™ to achieve XML document sentience?
6. Who's the poor sucker whose project shall be stuck with the last remaining -ails™ name, Fails?
7. Where do I find the TDD™ framework for unambiguously ensuring I have the client's software requirements correct?
8. At the time all logic has been properly decentralized into separate services in my dandy SOA™, what happens when my messaging server goes kaput?