• hobart (unregistered) in reply to EatenByAGrue
    EatenByAGrue:
    Although I don't agree with Joel Spolsky on everything he writes, he nailed this issue pretty well: http://joelonsoftware.com/articles/fog0000000018.html
    Not sure he does nail the issue here. TBH, I'm struggling with what his point is.

    Is it that abstraction sometimes goes too far? True, but the example of p2p is a pretty poor one. If you take the original Napster, remove the "music only" thing and get to peer-to-peer as he suggests, you don't get something that "misses the point". You get torrents, or you get iPlayer (oh, and p2p lending still has a fair chance of being a big thing).

    Is it that some people over-hype technology? Well, duh. But that's been the same with every product that's been sold since the dawn of time - that's marketing. Can't really see what it's got to do with "architecture astronauts".

    Or is it that most people don't care about the underlying architecture? Again, true. But just because most people don't really care about the fact that something is underpinned by XML, it doesn't make the people who came up with XML, or someone building an architecture based around XML, an "architecture astronaut" who's run out of oxygen.

  • JJ (unregistered)

    If I were to put a label on this article, I'd say it's about the state of trends in evolution of so called "Enterprise Systems" and the fine line that exists between the good usage and bad usage of patterns; and the reasons that could lead to such a situation. The article takes the example of a wrong turn were the end result seems to make sense in regards to certain principles, but was driven by bad decisions.

    Having seen some HR/Finance systems in medium to big corporations, I can attest that quite often, the excessive use of patterns mix the concerns at higher level just enough so that implementing specific business rules related for example to salary can become a nigthmare; the flow of data can also become badly broken; or the dependencies could become unmanageable. Lack of foresight is not necessarily to blame because changes in that kind of softwares can take a heck of a long time and span multiple people.

    Interestingly enough, this thought process seems to apply equally to organization changes in companies of the same sizes, were we could compare the choices of companies having multiple HR, Finances or IT departments versus companies centralizing everything and at the end of the day thinking about outsourcing those groups. It is definitely arguable that some companies can and do benefit of such changes, but what makes it so?

  • Calvin (unregistered) in reply to Wheaties

    Good lord, I'm glad I'm not the only one. I learned my lesson, though; and repented of my sins.

  • tanus (unregistered)

    This reminds me of MSN messenger 2011. It has its own library and runtime. The library: one massive package that after you install it, which you have to, you may as well install all other programs; which are small in comparison; though you may just messenger. And everytime there is a new version you get prompted to update to the new one. Imagine something like this: a 100MB library and 7 5-12MB applications. And one only really want 1 application.

Leave a comment on “Patterns of Failure”

Log In or post as a guest

Replying to comment #:

« Return to Article