Mike Spille on Overreacting

Discussions

News: Mike Spille on Overreacting

  1. Mike Spille on Overreacting (20 messages)

    Mike Spille, in "Action Hippo Rangers!," has written up a good analysis of the "overreaction syndrome."
    Beware the 180 degree turn. Be wary of the knee-jerk reaction. Recognize that one data point does not a curve make. All things in moderation, especially moderation.
    Along the way, he describes a new (and potentially inefficient) Extreme Programming variant, iXP, described as:
    ...having each developer add 1 character to the code and bounce it back to the other guy, where he adds one more character and bounces back to the other guy, etc. In 3 or 4 hours they'd have a "for" loop coded up and then write a 50,000 page article on the success of TDD, ping-pong development and doing a shot everytime you type the letter 'i'.
    He offers examples (drawn from experience?) such as:
    omewhere, someone is finding Singletons to be the single biggest threat to their codebase. Right now, as you read this, they are starting a movement in their group to eradicate all singletons and embrace Inversion of Control. Right now, as you read this, those same people are planting the embryonic seeds for their demise - they are creating the future where all of their objects are created by the container, and the profiler reveals that 97% of the system's runtime is spent inside the IoC code. Their successors will then valiantly and selflessly dedicate themselves to re-writing the system with no container and to use only singletons and "new".

    John in Kentucky finds Java a little tedious at times. He's thinking of throwing away his entire multi-million dollar investment and do everything in Ruby on Rails. A young woman in her 3rd year of college will, in 4 years time, emerge from academia to have John fired as she blazes the trail to recode all critical systems in C++ "because of the proven benefits of static type safety and C++'s leading role in that arena". A young boy, now hacking his copy of a driving game to show faintly pixelated boobies, will hack that future corporate culture, and prove that static unsafe code is for wusses and Smalltalk 2042 is the One True Way. He will then have a sex change and evanglize Forth for the remainder of this career.
    His view of the future of EJB3 is summarized as well:
    Today we see the new cycles, with all the players changed and the details different, but the pattern is clear and its unchanged. We see a vision of "standardizers" spitting on XML everywhere and espousing EJB 3 annotations in their knee-jerkism to XML abuse. And I'll bet you twenty bucks and a pint (of vodka) that 5 years from now those same, exact people will be pissing and moaning about people hard-coding database names in their annotations and leading a charge to move as much into configuration as possible.
    His point is that dedication to a single governing concept is usually a Bad Thing, that a certain amount of pragmatism is good to have in hand. Do you think he's correct in his view of the industry and the contortions it endures?

    Threaded Messages (20)

  2. Mike Spille on Overreacting[ Go to top ]

    I think he's correct and it gets old. It gets monotonous that everytime a new technology or "widget" comes out that it's immediately touted as the "new thing to change all existing things".
  3. Mike Spille on Overreacting[ Go to top ]

    Very funny and well-written. Although I have to admit, Mike offering us a cautionary tale against overreacting is a bit like Hani lecturing us for being pottymouths.
  4. http://joelonsoftware.com/articles/fog0000000069.html
  5. http://joelonsoftware.com/articles/fog0000000069.html

    While I agree with Joel's basic premise in this article I have to mention two things.

    1. Netscape's demise has a lot more to do with the tactics Microsoft used against them than with any technical direction they pursued. It might have helped them dig their grave faster but it's not the key reason.

    2. I find it hard to take Joel seriously after reading his diatribe on why exceptions are bad and you should catch everything and turn exceptions into return codes. Come to think of it, not only is it one o the dumbest things I've ever read on software development, it's a great example of over-reacting.
  6. I was just sayin'[ Go to top ]

    All I wanted to do was point out that someone else has made similar comments. In the articleI cited, he's just going on about how programmers want to throw the previous version away, which is in the same ballpark as Mike's comments.

    As for the rest:

     - On your first point, well, everyone has an opinion.

     - On your second, and just to make it crystal clear, the comments on exceptions are in another article altogether.
  7. You can't construct a curve with one point but you can with two.

    -Pete
  8. You can't construct a curve with one point but you can with two.-Pete

    Yeah, it's called a line. That'd offer only a slightly better conclusion.

    (Always has to be one smarta**)
  9. You can't construct a curve with one point but you can with two.-Pete

    Is that what you call a straight curve?
  10. SOAPS[ Go to top ]

    Is the "new tech" hype the IT world's version of SOAP Operas? wouldn't life be boring without all that noise and hype. bring on the hype. In fact everyone should rewrite their apps to use async soap ws. While we are at it, we should rebuild Hoover dam.

    </sarcasm>

    peter
  11. Re-writing apps[ Go to top ]

    While I agree it's not usually a great idea to rewrite an app from scratch sometimes it's the best option.

    My experience is that most code is not written for maintainablilty. Given that, over the span of a decade (and sometimes less) unmaintainable code tends to become more unmaintainable.

    At some point, the cost of maintenance and support exceeds the cost of a new application (and supporting the new bugs.) Unfortunately the new apps are rarely more maintainable that the the original because the expectation is that the new technology will solve all the problems.

    Or, like my current situation, the original code is so dysfunctional and inscrutable that there's no value in retaining it.
  12. Today we see the new cycles, with all the players changed and the details different, but the pattern is clear and its unchanged. We see a vision of "standardizers" spitting on XML everywhere and espousing EJB 3 annotations in their knee-jerkism to XML abuse.

    We're a major supporter, vendor, and pusher of EJB3 technology and we're definately not saying annotations are the silver bullet. These are our guidelines for when to use annotations.

    Anyways, XDoclet has been popular for years before any draft of the EJB3 specification ever came out. Developers have *already* decided they like annotations and find them useful.

    BTW, I know that Mike is not attacking EJB3 directly and agree with his premise that a single governing concept is usually a Bad Thing.

    This is what scares me about the whole SOA thing. That the average developer will hear about SOA and think they have to apply it to every application they need to write. Believe me, I've been through the CORBA fad in the mid 90's where everybody architected their applications to be split up into separate distributed objects. What a nightmare. Wouldn't want to go through fighting that type of architecture again. I hope most developers realize that SOA is a niche thing. A way to integrate different business units or organizations, not to write single applications.

    Bill
  13. +1
    It is a rare event when a
    major supporter, vendor, and pusher
    has a sane and not overhyped policy and understanding of SOA and its applicability.

    Another interesting observation is whether or not a past CORBA experience has anything to do with more down-to-earth view towards SOA. Having been through ups and downs of CORBA myself I happened to have very similar mindsets towards SOA.

    Nikita.
    GridGain Systems.
  14. This is what scares me about the whole SOA thing. That the average developer will hear about SOA and think they have to apply it to every application they need to write. Believe me, I've been through the CORBA fad in the mid 90's where everybody architected their applications to be split up into separate distributed objects. What a nightmare. Wouldn't want to go through fighting that type of architecture again.

    Hey, you have given a perfect example of overreaction here! You have been through years of CORBA abuse (not a nice thing, indeed) and now you tend to use the CORBA=nightmare example everytime you need to stress the "no silver bullet" concept. I recall other postings where you stated that.

    My problem here is that you and others who underwent this uber-IIOP mistreatment are spreading, involuntarily, false concepts. Last week I tutored a bunch of juniors that were about to go out consulting in the bad, unfriendly world of the customer's software factory. Well, one of the freshmen, when I mentioned CORBA in my explanation of the EJB architecture, immediately saw an opportunity of showing he was up-to-date with cool technology by saying: "Hey, but CORBA is no longer used, isn't it?". The guy had not the faintest idea what on earth IIOP was, and what its relationship with RMI could ever be, and what the similarities with EJB were. He had just heard the notion of (CORBA == abandonware) by corridor eavesdropping. Too bad that he is currently practicing his J2EE apprenticeship on IONA ASP, which is intensively and extensively IIOP-based. This is what I would call "result of overreaction", and is certainly not helping the poor fella to understand what he is doing in his job...

    Take also note that I used JBoss to teach them J2EE though I knew they would end up using Orbix in production.
    I hope most developers realize that SOA is a niche thing. A way to integrate different business units or organizations, not to write single applications.

    Here I agree 101% with you. But what is needed is that most architects realize SOA is a niche thing.

    Paolo Guccione [currently disguising his MDA as a SOA to make it acceptable to managers & customers]
  15. I hope most developers realize that SOA is a niche thing. A way to integrate different business units or organizations, not to write single applications.

    By "niche" thing, do you mean, "Very few organizations will ever benefit from or use SOA"? Or do you mean, "SOA is best used in connecting systems, so don't try to apply it everywhere, especially within your systems"? Or do you mean something else entirely?

    I wouldn't call SOA a niche thing because I think it will be widely applicable--useful to most organizations on the planet. However, I agree that it shouldn't become the default application architecture.

    --Kevin
  16. Today we see the new cycles, with all the players changed and the details different, but the pattern is clear and its unchanged. We see a vision of "standardizers" spitting on XML everywhere and espousing EJB 3 annotations in their knee-jerkism to XML abuse.
    We're a major supporter, vendor, and pusher of EJB3 technology and we're definately not saying annotations are the silver bullet. These are our guidelines for when to use annotations.Anyways, XDoclet has been popular for years before any draft of the EJB3 specification ever came out. Developers have *already* decided they like annotations and find them useful.BTW, I know that Mike is not attacking EJB3 directly and agree with his premise that a single governing concept is usually a Bad Thing. This is what scares me about the whole SOA thing. That the average developer will hear about SOA and think they have to apply it to every application they need to write. Believe me, I've been through the CORBA fad in the mid 90's where everybody architected their applications to be split up into separate distributed objects. What a nightmare. Wouldn't want to go through fighting that type of architecture again. I hope most developers realize that SOA is a niche thing. A way to integrate different business units or organizations, not to write single applications.Bill

    Err, that's kind of the opposite of what SOAs are intended to do. They are about isolating business functions and recomposing them in new ways to adopt to changing business processes. If you start to get visibility into how datacenters are being (re)composed, you'll see this as a trend and not a small niche. Moving toward SOAs is categorically different than decomposing all application internals into distributed objects (seen that nightmare unfold as well). Its a bad analogy. I would give more nuanced advice: understand well how your applictions will fit into the overall IT architecture and especially how they will support changes in the business much more effectively. I think your "average developer" is more than capable of understanding that.

    BTW, Mike, this short piece is one of the best blog entries I've read in a long time.

    Greg
  17. Shu Ha Ri and Overreacting[ Go to top ]

    Mike's blog post reminds me of the Shu state of Shu Ha Ri (see http://c2.com/cgi-bin/wiki?ShuHaRi and http://www.aikidofaq.com/essays/tin/shuhari.html for info). We often don't have time to achieve Ha in any discipline, so we are in an almost continual state of Shu (and occasional Ha), searching for the One True Way without ever becoming a true master of any given way, then looking back at all the time we wasted trying to find the ultimate answer.

    Further, as mathematical thinkers concentrating on reducing algorithms to individual steps, developers have a tendency to put rules around everything, leaving us in a continual state of Shu.

    Overreactions seem to happen when there is extreme time pressure, which is pretty much all the time. (Doesn't it seem counterintuitive to overhaul everything when time is short?) A rational response (which has limits, granted) is continual incremental improvement.
  18. Shu Ha Ri and Overreacting[ Go to top ]

    A rational response (which has limits, granted) is continual incremental improvement.

    I completely agree. The problem is that so much development is done as if it is the ultimate solution that will never change. Incremental improvements become extremely difficult and risky.

    Over the years, I've come to the conclusing that it's more important to make code easy to change than it is to come up with "The Ultimate Solution ™"

    I'd rather have a mediocre solution that is flexible than a 'great' solution that is competely entrenched.
  19. CAVEMAN[ Go to top ]

    I can see it now, Mike Spille hunting big game with his bare hands and matching zebra skin underwear and bootie.
  20. Mike Spille on Overreacting[ Go to top ]

    His point is that dedication to a single governing concept is usually a Bad Thing, [...]
    I think he's overreacting...

    SCNR,
    Lars
  21. 97%[ Go to top ]

    I've been thinking over and over about it and I still don't see how 97% of the system's runtime is spent inside IoC code. Maybe Mike uses another IoC framework than I do.