Meet the new boss, same as the old boss v2
Sometimes you read something that you can't summarize without losing a lot. I just can't find any extra words in this post, so here it is in its entirety:
1) Whatever language is currently popular will be the target of dislike for novel and marginal languages.
2) Substitute technology or methodology for language in #1. In the case of methodology, it seems a straw man suffices.
3) Advocates will point to the success of toy projects to support claims for their language/methodology/technology (LMT).
4) Eventually either scale matters or nothing matters. Success brings scale. An LMT is worthy of consideration only after proving out at scale.
5) Feature velocity matters in early stage Web 2.0 startups with hyperbolic time to market, but that is only a popular topic on the Web for the same reason Hollywood loves to hand out Oscars.
6) Industry success brings baggage. Purity is the sign of an unpopular LMT. The volume of participants alone will otherwise muddy the water.
7) Popularity invites scrutiny. Being unfairly blamed for project failure signals a maturing LMT; unfairly claiming success, immature LMT. Advocates rarely spend much time differentiating success factors.
8) You can tell whether a LMT is mature by whether it is easier to find a practitioner or a consultant. Or by whether there is more software written *with* or prose written *about* the LMT.
9) If you stick around the industry long enough, the tech refresh cycle will repeat with different terminology and personalities. The neophytes trying to make their bones will accuse the old guard of being unable to adapt, when really we just don't want to stay on this treadmill. That's why making statements like "Java is the new COBOL" are ironic; given time, "N+1 is the new N" for all values of N. It's the same playbook, every time -- but as Harlan Ellison said of fiction, every story has already been told, but nobody was listening the first time.
10) Per #9, I could have written this same post, with little alteration, ten, twenty or thirty years ago. It seems to take ten years of practise to truly understand the value of any LMT. Early adopters do play the important role of exploring all the dead ends and limitations, at their cost. It's cheaper to watch other people fail, just like it hurts less to watch other people get injured.
11) Lisp is older than I am. There's a big difference between novel and marginal, although the marginal LMTs try to appear novel by inserting themselves into every tech refresh cycle. Disco will rise again!
12) If an LMT is truly essential, learning it is eventually involuntary. Early adopters assume high risks; on the plus side they generate a lot of fodder for blogs, books, courses and conferences.
13) I wonder if I can get rich writing a book called Agile Lisp for Web 2.0 SOA. At least the consulting and course revenue would be sweet. Maybe I can buy an island. Or at least afford the mortgage payments on a small semi-detached bungalow in the Bay area.
14) It requires support from a major industry player to bootstrap any novel LMT into popularity. The marginal LMTs often are good or even great, but lack sponsors.
15) C/C++ remain fundamental for historical reasons. C is a good compromise between portability and performance -- in fact, a C compiler creates more optimal code than humans on modern machine architectures. Even if not using C/C++ for implementation, most advocates of new languages must at least acknowledge how much heavy lifting C/C++ does for them.
16) Ditto with Agile and every preceding iterative methodology. Winding the clock back to waterfall is cheating. I'm more sophisticated than a neanderthal, but that won't work as a pick up line.
17) Per #13, I don't think so, because writing this post was already a chore, let alone expanding the material to book length. Me an Yegge both need a good editor.
This covers the technology pretty well. All he left out was the reason so much is coming back.
No comments:
Post a Comment