Patterns of Failure

« Return to Article
  • laoris 2010-03-02 11:07
    I think that cloud looks more like a llama, actually.
  • Ed 2010-03-02 11:11
    laoris:
    I think that cloud looks more like a llama, actually.


    Possibly a poodle?

    Or perhaps the Michelin Man's canine friend.
  • SuperAnalyst 2010-03-02 11:12
    An interesting, if technical, article on the path to Code.Hades(), but where's the funny?
  • dkf 2010-03-02 11:13
    laoris:
    I think that cloud looks more like a llama, actually.

    And I only manage to see a tap (that's a faucet to you North Americans).
  • Wheaties 2010-03-02 11:19
    Yeah, been there, done that, have the scars to prove it. Where's the stories about watching the new hires' faces contort as you try to explain how the monstrosity works?
  • Engival 2010-03-02 11:20
    I've seen a few well designed intranet sites sharing a common user and permission system, without having to shoehorn every module into some unrealistic requirements. Does this automatically make it a WTF?

    It doesn't matter if you design an uber-app, separate apps, or some form of modular intranet; if you start from a bad framework or bad design goals, you end up with a WTF. If you have good design goals, and some sensible non-overreaching framework, you can end up with a nice system.
  • A Nonny Mouse 2010-03-02 11:24
    anyone else seeing phantom brown dots on the uniform application portfolio graphic..? maybe i need coffee (or less coffee, depending)
  • ClutchDude 2010-03-02 11:27
    This article underscores the importance for at least half-decent project planning.

    For instance, if at the framework level, they partitioned the code for each functional group off, they'd find themselves in a more manageable position. Sure, I want a simple calendar popup to be consistent through out the organization. UI can be a big and sometimes beast of a problem, so it makes sense to simplify it as much as possible so users can expect the same thing.

    The problem, as Alex points out, is that it's so easy to move beyond just centralizing UI.

    It was hard enough getting framework Foobar working in one application. Why would you redo that when you can just tack the need functionality onto that framework? It'd make your life a lot easier..until the logic between the two somehow-separate applications gets so intermeshed you can't pull them apart without breaking both.

    Side note, you might want to tell Softlayer that they misspelled "Washinton DC" in their banner ad.



  • James 2010-03-02 11:27
    Don't worry. That's a perfectly normal optical illusion.
  • Dan 2010-03-02 11:29
    laoris:
    I think that cloud looks more like a llama, actually.


    exactly what I thought hen I saw it too.
  • rudraigh 2010-03-02 11:29
    I don't see a dog in the cloud. Unless that dog is in a sheep costume.

    BuildMaster looks interesting.
  • lesle 2010-03-02 11:29
    A Nonny Mouse:
    anyone else seeing phantom brown dots on the uniform application portfolio graphic..? maybe i need coffee (or less coffee, depending)
    Yes. They're interstitial brown.
  • Hmmm... 2010-03-02 11:34
    This article attempts to take on a pretty huge topic. It seems to me to miss out on many key advantages of an architecture where disparate functionality can benefit from unified conventions and foundations. Aside from benefits to developers, a group of applications which share common elements can be easier for users to learn, faster to use, and easier to administer. You can certainly enforce these by convention, but the strength of convention in large groups is not usually very high without burdensome review processes.

    Further, if it becomes necessary to move information from one system to another, it is much simpler if the systems share a platform.

    My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.
  • Gump 2010-03-02 11:43
    laoris:
    I think that cloud looks more like a llama, actually.


    Damn, you beat me to it.

    Yeah, that's a llama.

    captcha: illum = when one is um, sick
  • Ben Burns 2010-03-02 11:52
    I don't think the problem here is the internal framework, it's the adoption of processes which don't allow for "the law of leaky abstractions." Unwillingness to accept a lack of perfection in a particular set of abstractions limits flexibility in design and leads to the problem you describe - overtly modifying the requirements to fit the system rather than the system to fit the requirements.
  • amischiefr 2010-03-02 12:06
    Hmmm...:

    My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.

    Yeah, I don't see what the problem is. Having a code base that extracts like functionality for reuse seems to be highly functional, not dysfunctional. Especially (which is mentioned several times in the article) user authentication. Why would you not want one centralized solution for this so that every application authenticates in the same way? We have such a system that returns a list of user roles which can be used in the application to determine access.
  • blah 2010-03-02 12:08
    TRWTF is VB5.
  • Marvin the Martian 2010-03-02 12:15
    Gump:
    laoris:
    I think that cloud looks more like a llama, actually.

    Yeah, that's a llama.

    No is no llama!

    Is Argentinian sheep. Onestly.
  • Doug 2010-03-02 12:17
    I'm not sure if the cloud looks like a dog, but I'm pretty sure the UberApplication looks like Norton SystemWorks ...
  • md5sum 2010-03-02 12:19
    Wow... I guess I'm missing the WTF here today, or maybe I'm missing what this article is saying, but I've worked on many systems (and am currently building a new one) where a single application layer lays the foundation for multiple application front-ends. Obviously bad design is bad design, and bad architecture is bad architecture, but built correctly with keeping the UNIQUE application logical units separate while re-using the NON-UNIQUE modules has many HUGE advantages. Among other things, it makes management of future development and changes in the shared components much simpler.

    Now obviously I'm not promoting a one-size-fits-all application model, but sharing DAO and security objects across multiple applications just makes sense.

    There are only 3 possible ways you would ever consider doing security for an application (AD w/ groups, single password for everyone, unique logins and permissions internally managed) maybe a 4th method if your application requires field level permissions for each user, but I always advise against that method due to the poor manageability.

    And obviously, you might have multiple different data sources, potentially different data types, but I have both built and worked on several different structures that support multiple data sources and types with GREAT ease of use for the developers, and reliability for the consumers.

    Considering the example cited here, if the "Disparate Application Portfolio" is the RIGHT way to go, and all of them use a copy of the same Data object. You find a bug in your Data object... you now have to re-deploy all of your applications. If they all share the same Data object, and none of them contains a unique copy of it, but rather they all point to a SINGLE, SOLITARY deployment of the Data object, then you only have to re-deploy the Data object.

    Maybe it's just me, and maybe I'm wrong, but (sadly) I've worked with all the models listed in this article, and the easiest and best in my experience has been pretty close to what's described here, minus the “how might we adapt the needs to meet our pre-determined requirements” part, which should never be a part of a development process.
  • Richard 2010-03-02 12:23
    Actually, it's pretty clearly a Chinese dragon. <piff> Llama, indeed...
  • Ray 2010-03-02 12:31
    There's an old saying a couple of my university professors would use for something like this:

    KISS - Keep It Simple, Stupid.
  • Franz Kafka 2010-03-02 12:32
    Hmmm...:
    This article attempts to take on a pretty huge topic. It seems to me to miss out on many key advantages of an architecture where disparate functionality can benefit from unified conventions and foundations. Aside from benefits to developers, a group of applications which share common elements can be easier for users to learn, faster to use, and easier to administer. You can certainly enforce these by convention, but the strength of convention in large groups is not usually very high without burdensome review processes.

    Further, if it becomes necessary to move information from one system to another, it is much simpler if the systems share a platform.

    My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.


    Mine says that the internal apps should share some code (via a core package, perhaps), but beyond UI and common mechanisms like auth, they should be separate.
  • Robert 2010-03-02 12:35
    laoris:
    I think that cloud looks more like a llama, actually.


    Wow, I was going to post that, and BAM, there it is in the first post.
  • Anonymous Coward 2010-03-02 12:36
    Richard:
    Actually, it's pretty clearly a Chinese dragon. <piff> Llama, indeed...

    Much closer to a Chinese lion. since spamfilter won't let me link, see: http://en.wikipedia.org/wiki/Lion_dance
  • md5sum 2010-03-02 12:36
    Franz Kafka:
    Hmmm...:
    This article attempts to take on a pretty huge topic. It seems to me to miss out on many key advantages of an architecture where disparate functionality can benefit from unified conventions and foundations. Aside from benefits to developers, a group of applications which share common elements can be easier for users to learn, faster to use, and easier to administer. You can certainly enforce these by convention, but the strength of convention in large groups is not usually very high without burdensome review processes.

    Further, if it becomes necessary to move information from one system to another, it is much simpler if the systems share a platform.

    My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.


    Mine says that the internal apps should share some code (via a core package, perhaps), but beyond UI and common mechanisms like auth, they should be separate.


    Which is exactly what I was referring to in my (somewhat lengthy) comment, and is also almost exactly what is pictured in the "UberApplication" diagram (that's supposedly so bad)...
  • Paul W. Homer 2010-03-02 12:45
    There is certainly a balance that developers have to make between trying to abstract everything, and just pounding out masses of overly duplicate code. However, just because this example of building an uber-system failed so miserably, it doesn't mean that the goal or their intentions were wrong.

    It sounds like they just didn't understand what problem they were really trying to solve. They collected together a big ugly mass of technology hoping that it would somehow magically solve their problems, however the real problem was how to make it intrinsically easy to quickly build and maintain new components.

    Technology by itself is never the issue, complexity management is.

    Still, these types of failures shouldn't lead developers to conclude that pounding out more redundant code in a large number of independent systems is a solution. One problematic uber-system is still way better than twenty badly written little ones. At least with the big system, when pointed in the right direction, there is some hope in getting it sorted out. With the little ones, only the better ones will eventually get updated. The rest will just rust away.
  • Michael 2010-03-02 13:05
    Good article. I figure the reason we think this way is because, as the article says, at a code-level finding and reducing redundancy is *usually* a good idea. However, at a macro-level, there are all these standards (like XML, SOAP, XML-RPC, etc) for providing loosely coupled interactivity between applications. Some of the standards even predate the Web!

    IMO, awareness of and adherence to existing standards is the key to avoiding this trap.
  • highphilosopher 2010-03-02 13:07
    md5sum:
    Wow... I guess I'm missing the WTF here today, or maybe I'm missing what this article is saying...
    the “how might we adapt the needs to meet our pre-determined requirements” part, which should never be a part of a development process.


    That part is the WTF.
  • Franz Kafka 2010-03-02 13:07
    md5sum:
    Franz Kafka:


    Mine says that the internal apps should share some code (via a core package, perhaps), but beyond UI and common mechanisms like auth, they should be separate.


    Which is exactly what I was referring to in my (somewhat lengthy) comment, and is also almost exactly what is pictured in the "UberApplication" diagram (that's supposedly so bad)...


    The reason the uberapp is so bad is that:
    1. developing an app requires an app template that doesn't quite fit the requirements
    2. even with that, it takes longer to develop than a custom one-off
    3. this leads to lots of unrelated apps stuck together in the same 'app'

    What should be done with code sharing is to share the lower layers of the stack and also horizontal concerns - common utils, DB access, logging, some UI widgets if practical. Forcing every app into a preselected mold doesn't really help much.
  • Bill Sorensen 2010-03-02 13:19
    I strongly disagree that this is a WTF. The implementation may have been, but the concept is valid. Microsoft's Composite UI Application Block (CAB) is based on this premise; it was seen as overly complex, so Prism (Composite WPF) was introduced as a replacement.

    We wrote a stripped-down version of CAB, which works well for in-house development. Users appreciate the consistent look-and-feel, and developers don't have to reimplement security for every application.

    Composition is good in software design. Removing duplication is good when coding. Why are these concepts bad for application design?

    The framework must be flexible enough to handle diverse requirements, but that's not that hard. Outside of vendor demos, most applications look very similar (and that's a good thing). Apple got it right, and Microsoft does try.
  • mfah 2010-03-02 13:21
    Doug:
    I'm pretty sure the UberApplication looks like Norton SystemWorks ...

    It's clearly Lotus Notes. This is exactly the sort of thing that happens with Lotus Notes (which is enough of a WTF in itself).
  • ObiWayneKenobi 2010-03-02 13:44
    Isn't the accepted best practice for software development to have your common modules and then reuse only those in other modules? It's a WTF if the "Customer Management Module" shares logic with the "Report Generation Module" but not if both make use of the Authentication Module and/or the Base Entity Module.
  • EatenByAGrue 2010-03-02 13:58
    A serious article on TDWTF. Ok, I'll go with it, since usually this site is dedicated to demonstrating what not to do.

    Although I don't agree with Joel Spolsky on everything he writes, he nailed this issue pretty well:
    http://joelonsoftware.com/articles/fog0000000018.html

    What happens with these types is that they see patterns and abstractions really well, which may or may not be useful for putting together a good software solution. I've worked with guys who were great coders and really bright folks, but because they were so focused on solving a generalized abstraction of the problem they never actually got around to solving the specific problem.
  • Ed Larmore 2010-03-02 14:09
    I think Alex makes interesting points. I've definitely seen requirements for a new system based on how an existing system works.

    But sometimes that actually makes a lot of sense. Often a customer doesn't know exactly what he wants until he sees it. So if he sees an existing system that does some similar things to the often vague notion in his head of what he wants, he might say "I want X but don't want Y, and I like Z but please change it to something a bit different". Wouldn't it then make sense to re-use requirements and code on the pieces he wants and modify requirements and refactor code for the things that he wants to change slightly?

    Now of course this strategy requires competent engineers and can be done poorly as any task can; but that doesn't make the approach somehow bad.

    Also, many security features are rather arbitrary; e.g., password requirements (must have 1 upper case character, 2 numbers and one special character). If a new customer can choose between an arbitrary password requirement that he has to pay money for vs. an arbitrarty password requirement that is already implemented, why not reuse the latter? Or if he really must have a particular password requirement that isn't implemented, why not refactor the existing password checker to use regular expressions, so that both the original app and the new app can use the same code?
  • James S 2010-03-02 14:17
    This seems like a great big DUH moment. *Every* business application is a database application. Every single one. And this is probably why Lotus Notes seemed like such a good idea. Only that once the thing was bought, insufficient resoruces are devoted to 1) telling everyone the plan to put everything into Notes, 2) making that plan actually happen. It all gets watered down and set aside and not communicated. At HQ, sure, there Notes-ing their brains out, but in the field offices, their not even sure what Notes is (other than horrible email client) and are busily building there own business-specific tools with Lotus Approach. (or now-a-days, a horrible combination of MS Excel and Access, with hooks into Outlook, that all runs on some Admin Asst's desktop). The problem is that big businesses are too big.
  • Vjg 2010-03-02 14:19
    That dog looks exactly like a cloud I saw last week... or was it a potato?
  • Jackson Curtis 2010-03-02 14:27
    I see a My Little Pony
  • Rob 2010-03-02 14:33
    SOA?
  • woah! 2010-03-02 14:38
    Engival:
    I've seen a few well designed intranet sites sharing a common user and permission system, without having to shoehorn every module into some unrealistic requirements. Does this automatically make it a WTF?

    It doesn't matter if you design an uber-app, separate apps, or some form of modular intranet; if you start from a bad framework or bad design goals, you end up with a WTF. If you have good design goals, and some sensible non-overreaching framework, you can end up with a nice system.


    Yeah this was a pretty poor TheDailyWTF article. Sounds to me like they were just using a skeleton in house framework, and as they needed to plug new applications in, some code went in to the wrong layer.

    This should just be a standard "someone invented their own shitty framework" wtf. Instead it ridicules what all software engineers try to achieve: never having to write the same line of code twice.
  • DES 2010-03-02 14:46
    md5sum:
    There are only 3 possible ways you would ever consider doing security for an application (AD w/ groups, single password for everyone, unique logins and permissions internally managed)


    Remind me not to hire you.

    md5sum:
    Considering the example cited here, if the "Disparate Application Portfolio" is the RIGHT way to go, and all of them use a copy of the same Data object. You find a bug in your Data object... you now have to re-deploy all of your applications. If they all share the same Data object, and none of them contains a unique copy of it, but rather they all point to a SINGLE, SOLITARY deployment of the Data object, then you only have to re-deploy the Data object.


    In the real world, the guys who maintain Application X stumbled across the bug in the Data object and fixed it, while the guys who maintain Application Y tweaked something (possibly unwittingly) so the buggy Data object works fine for them, and deploying the fix broke Application Y at the precise moment when the CTO was demonstrating it to the Gnomes from Zürich. As a consequence, the Gnomes return to Zürich without signing the multi-million-dollar contract, and the CTO fires the idiot who came up with the deployment procedure, viz. you.
  • Cliff Buttons 2010-03-02 14:48
    There was a classic Dilbert (so it must be true) where the consultants came in - decentralise everything that's centralised, centralise everything that's decentralised, and leave the dust to settle long enough for the next guys to reverse what you just did.

    That's because the real world is endlessly variable, IT is extremely rigid, and there's no single right answer to any problem.

    Take a company (hint, one I worked at) who insisted on 'online payslips' and had the scariest, shonkiest application and massive security holes in the corporate network to enable it. Nobody knew how the skunk app worked, they just knew it was a nightmare, and had to be migrated to different hardware, so they may as well look at it. Migration/redev would cost a minimum of £20k to fit the corporate security policy. It turned out for under £1000/year, they could revert to paper payslips (printed and sent throguh internal mail as opposed to everybody printing their own, which was what happened anyway) - but that couldn't be allowed - progress was progress after all. And in a market-leading IT company (one you know very well) these dual pressures of corporate compliance, legal compliance, security compliance and sheer bloody common sense, there was no single perfect answer. There never could be. This is a similar case - there is no 'right' answer, they're all wrong.

  • Quirkafleeg 2010-03-02 14:57
    Never mind all of this reuse-this-don't-reuse-that-put-this-in-that-layer stuff. What I want to know is this: is who's in charge of maintaining the GAF the GAFfer?
  • Franz Kafka 2010-03-02 15:30
    DES:


    In the real world, the guys who maintain Application X stumbled across the bug in the Data object and fixed it, while the guys who maintain Application Y tweaked something (possibly unwittingly) so the buggy Data object works fine for them, and deploying the fix broke Application Y at the precise moment when the CTO was demonstrating it to the Gnomes from Zürich. As a consequence, the Gnomes return to Zürich without signing the multi-million-dollar contract, and the CTO fires the idiot who came up with the deployment procedure, viz. you.


    Well sure, if your idea of deployment is "throw against wall and see if it explodes". If you validate a configuration before foisting it on the world, this won't happen (much).
  • Slicerwizard 2010-03-02 15:31
    How many birds does it take to make this "birds-eye"?

    What the hell are "authorization principals"?
  • The Wanderer 2010-03-02 15:48
    laoris:
    I think that cloud looks more like a llama, actually.
    Exactly my first thought.

    On second glance, though, I think it might be a camel.
  • frits 2010-03-02 15:56
    Jackson Curtis:
    I see a My Little Pony


    I see a Care Bear.
  • jmucchiello 2010-03-02 15:57
    The only thing even close to a WTF here is that these disparate programs share the same address space. I don't care if these six user functions share 99% of the same code (and that 1% is just the stuff to differentiate them). The only problem here is that they are all contained with one Überlauncher. The savings gains from signing on only once is not worth the pain when one app crashes and takes out the other ones.
  • MyNameHere 2010-03-02 16:06
    Yup I see it too. I was going to mention it but you beat me to it.
  • Bim Job 2010-03-02 16:20
    frits:
    Jackson Curtis:
    I see a My Little Pony


    I see a Care Bear.
    I see a pantomime horse.

    TRWTF is the silly multi-coloured "architecture" slide. This basically tells me that managers are in control, not engineers. And we all know where that leads.

    All this stuff about authentication, authorization, and templates? It sounds like the lunatics have taken over the asylum. For the first two, separation of concerns should take care of the issue: all that other modules require is a yes/no/file_not_found answer, coupled with a list of capabilities. (And it has nothing whatsoever to do with subtle differences between password requirements and the like.) For the third, You Do Not Re-Use Web Templates. Yes, you can modularize them. No, you do not include logic in them (refer to Terrence Parr for details).

    This sounds like a genuinely diseased organisation (three successive Architects?). It appears to be badly-managed, badly-directed, badly-staffed, and without any sane concept of testing or business analysis. I even suspect that, at ground level, the C# guys have little or no concept of inheritance and/or packages. Of course, I can't tell, because it's so generalised.

    What it doesn't sound like is much of an argument for Alex' proposition.
  • Bim Job 2010-03-02 16:25
    Oh yes, and "application metadata?"

    Really.
  • frits 2010-03-02 16:26
    Bim Job:
    ...I even suspect that, at ground level, the C# guys have little or no concept of inheritance and/or packages...


    I'm a C# guy, and I know that I can use my package to create inheritance. Oh!
  • Jaime 2010-03-02 16:31
    Franz Kafka:
    DES:


    In the real world, the guys who maintain Application X stumbled across the bug in the Data object and fixed it, while the guys who maintain Application Y tweaked something (possibly unwittingly) so the buggy Data object works fine for them, and deploying the fix broke Application Y at the precise moment when the CTO was demonstrating it to the Gnomes from Zürich. As a consequence, the Gnomes return to Zürich without signing the multi-million-dollar contract, and the CTO fires the idiot who came up with the deployment procedure, viz. you.


    Well sure, if your idea of deployment is "throw against wall and see if it explodes". If you validate a configuration before foisting it on the world, this won't happen (much).

    Unfortunately, this level of testing requires that the shared service maintainers are aware of every application that calls it. The library approach ony requires that the application developers test their application against the current version of the library.
  • Bim Job 2010-03-02 16:33
    frits:
    Bim Job:
    ...I even suspect that, at ground level, the C# guys have little or no concept of inheritance and/or packages...


    I'm a C# guy, and I know that I can use my package to create inheritance. Oh!
    You really are a slut, aren't you?
  • Anonymous 2010-03-02 17:04
    mfah:
    Doug:
    I'm pretty sure the UberApplication looks like Norton SystemWorks ...

    It's clearly Lotus Notes. This is exactly the sort of thing that happens with Lotus Notes (which is enough of a WTF in itself).


    No way. This is far too clean to be Lotus Notes. Lotus Notes can't be represented on any surface short of a hyper-cube, and that's only if you haven't customized it yet.
  • Psyckers 2010-03-02 17:08
    Considering how everyone else see's the cloud picture, just emphasises the point of this wanderful article / WTF.

    There are whole management disaplines that are fundalmentally looking at a 'silver bullet' pattern in clouds approach to coding. The article simply shows the fundalmental flaw in this approach and how we all now have examples of UberApplications.

    Pure Genius really.
  • md5sum 2010-03-02 17:09
    DES:
    md5sum:
    There are only 3 possible ways you would ever consider doing security for an application (AD w/ groups, single password for everyone, unique logins and permissions internally managed)


    Remind me not to hire you.


    PLEASE for the love of God, DO NOT hire me!

    DES:
    md5sum:
    Considering the example cited here, if the "Disparate Application Portfolio" is the RIGHT way to go, and all of them use a copy of the same Data object. You find a bug in your Data object... you now have to re-deploy all of your applications. If they all share the same Data object, and none of them contains a unique copy of it, but rather they all point to a SINGLE, SOLITARY deployment of the Data object, then you only have to re-deploy the Data object.


    In the real world, the guys who maintain Application X stumbled across the bug in the Data object and fixed it, while the guys who maintain Application Y tweaked something (possibly unwittingly) so the buggy Data object works fine for them, and deploying the fix broke Application Y at the precise moment when the CTO was demonstrating it to the Gnomes from Zürich. As a consequence, the Gnomes return to Zürich without signing the multi-million-dollar contract, and the CTO fires the idiot who came up with the deployment procedure, viz. you.


    In the real world:
    a) You don't demo your INTERNAL applications to your external customers.
    b) You test all of your applications against changes to the core framework.
    c) You never release a live application in the middle of a multi-million-dollar contract demo (DUH!).

    Additionally, the DEPLOYMENT procedure isn't at fault in your example (were it to ever happen), but rather the person who DEPLOYED it without having the appropriate tests passed.

    You're citing a broken process as a reason not to improve your development methods... fix your broken processes before you consider hiring anyone, least of all myself!

    Addendum (2010-03-02 17:17):
    Bim Job:
    All this stuff about authentication, authorization, and templates? It sounds like the lunatics have taken over the asylum. For the first two, separation of concerns should take care of the issue: all that other modules require is a yes/no/file_not_found answer, coupled with a list of capabilities. (And it has nothing whatsoever to do with subtle differences between password requirements and the like.) For the third, You Do Not Re-Use Web Templates. Yes, you can modularize them. No, you do not include logic in them (refer to Terrence Parr for details).

    This sounds like a genuinely diseased organisation (three successive Architects?). It appears to be badly-managed, badly-directed, badly-staffed, and without any sane concept of testing or business analysis. I even suspect that, at ground level, the C# guys have little or no concept of inheritance and/or packages. Of course, I can't tell, because it's so generalised.

    What it doesn't sound like is much of an argument for Alex' proposition.


    Thank God some people understand architecture (and apparently management as well) and know what they're doing!
  • Bim Job 2010-03-02 17:23
    md5sum:
    Thank God some people understand architecture (and apparently management as well) and know what they're doing!
    Ta. I didn't really think it through too much, so I'll probably disagree with myself in the morning.

    However, I'm with you on this one. Who's on Third?

    Frankly, I would have thought that this stuff is fairly obvious. I'm a little disappointed that Alex appears to be supporting the spaghetti-testing design pattern.
  • Christopher 2010-03-02 17:58
    dkf:
    laoris:
    I think that cloud looks more like a llama, actually.

    And I only manage to see a tap (that's a faucet to you North Americans).


    Hey, I'm in Canada and it's perfectly normal to call it a tap...
  • Balancing Act 2010-03-02 18:21
    So its a WTF to have 30 separate applications and its a WTF to have 30 applications integrated into one uber application. The problem here doesn't seem to be the uber application it is the fact that it is hard to design it correctly. Only in the last 5 years have we've seen really nice frameworks ranging from ruby on rails to sharepoint that try to solve this problem and let us move onto the next step. Even if we know the frameworks now exist its a business decision to decide how much money and effort to put into migrating all these mini applications and why would the business want to spend a whole lot of money potentially breaking something that is already working (mostly). Finally there is no guarantee that using our shiny new framework will be any better.
  • Bim Job 2010-03-02 18:27
    laoris:
    I think that cloud looks more like a llama, actually.
    I've changed my mind. It's a yak.
  • Dave McN 2010-03-02 18:43
    Good article & I enjoyed reading it but the real WTF i took from it is 'WTF are all those pictures of dragons and suits of armour on your company's website??' =P

    I get the whole 'slay your issues' theme but seriously, it makes it look more like a Games Workshop fan site, or a site for weekend role-playing, rather than one for a professional software solution.
  • e john 2010-03-02 18:56
    ObiWayneKenobi:
    Isn't the accepted best practice for software development to have your common modules and then reuse only those in other modules? It's a WTF if the "Customer Management Module" shares logic with the "Report Generation Module" but not if both make use of the Authentication Module and/or the Base Entity Module.


    Sure, but your common Authentication Module does not meet the needs I have for my common Authentication Module. And since you designed the Cusomer Management app and I designed the Report Generation app, we have a problem.

    Years ago I would have said that this was because there was nobody overseeing the various applications and spotting opportunities for true code reuse by mandating modules designed well enough to fit all the applications - the Chief Architect Team sort of hoohah that made sense to me then.

    Now, though, I feel that an effort of that kind will never succeed in a large organization because of the inability to allocate budget over long periods to that kind of team and because there is simply too broad a set of requirements to meet for these kind of "common" modules. With 16 apps, maybe we can make a common module. With 160 apps, it becomes less likely - highly unlikely, in my opinion. With 1600 apps, it is too expensive to consider the idea.

    So nowadays I think the only real failure is in our expectations ... sometimes the Common Stuff approach will work, but more often we have to be practical and reject it when it is not cost-effective ... but We All Knew That.
  • (username *)me 2010-03-02 19:08
    Alex Papadimoulis:

    ....After all, Duplication Is Evil, and it doesn’t make sense to re-implement....


    ....embrace the Don’t Repeat Yourself/Duplication Is Evil principle....


    Quoting out of context is fun!
  • a robot 2010-03-02 19:21
    It's a fire hydrant
  • Aussie Contractor 2010-03-02 19:39
    Do you work at my work?

    Oh and it was a Llama !!


    Captcha "valetudo" - same as last time I posted, my browser even remembered the text.
  • Estabon 2010-03-02 20:36
    How does a consultant learn that their entire architecture is wrong in a couple weeks? It's not like he actually knows the business or anything. All he saw was a large complex system he didn't understand and assumed it had to be the wrong way of doing things.
  • Dave 2010-03-02 21:01
    [quote user="Franz Kafka"][quote user="md5sum"][quote user="Franz Kafka"]
    * SNIP *

    The reason the uberapp is so bad is that:
    1. developing an app requires an app template that doesn't quite fit the requirements
    2. even with that, it takes longer to develop than a custom one-off
    3. this leads to lots of unrelated apps stuck together in the same 'app'
    *Snip*[/quote]

    1. To criticize a golden hammer you need to show the problem space is not entirely composed of golden nails. Wasn't enough detail on the templates to determine if they were reusable or a pain (apart from the editorial comment)
    Not saying it isn't WTF but the article doesn't show any of the reasons the templates are more customisation effort
    and less reuse. Or cover that the Enterprise wide requirements are hard or easy to re-implement.

    2. Build cost may be high support cost may be lower. less implementations of the same requirement and less variation in prerequisites = less support.

    3. Enterprise applications are related by the definition that they cohabit and need to play well.




  • MadX 2010-03-02 21:30
    The Uber Application resembles my Windows Desktop. Or do I see a llama?
  • Craig 2010-03-02 22:18
    Your coffee levels are fine; it's an optical illusion:
    http://en.wikipedia.org/wiki/Grid_illusion
  • DaveK 2010-03-02 22:59
    Slicerwizard:

    What the hell are "authorization principals"?
    Not a typo, just a highly-specialised technical term. Google it.

  • oheso 2010-03-02 23:40
    llama.

    Anyone who sees anything else needs to modify their medication levels.
  • awefawef 2010-03-03 01:09
    How is this a WTF? He was simply using SAP, or any other ERP that jams everything together into one Uber-App.
  • robbak 2010-03-03 01:43
    ClutchDude:

    It was hard enough getting framework Foobar working in one application. Why would you redo that when you can just tack the need functionality onto that framework?



    I've seen (and probably done) that. You don't seem to realize (until its too late) that the issue was learning the framework, and applying that in another application probably won't be a problem. So you apply your framework to the framework, (which you know because you wrote it), forgetting that the author of that framework stopped where they did for very good reasons - which you'll find out about shortly.
  • nisl 2010-03-03 02:30
    To me, making an uberapplication seems to be a bad way no matter how good the intentions are. High level feature reuse is supposed to be done with libraries, APIs and stuff like that.
    Frameworks are more for being capable to swap parts easily, such as database, presentation or network. Not to make different applications. Frameworks also tend to not work that way due to being hard to make.

    I work on a product that is a bit from all of the above. The parts that make it a monster to use is the sheer size of it, and the rotting code. It's also an accepted fact that it takes 6 months to learn enough to work on your own in the system. It takes another 6 months to actually start to understand how it all hangs together. There are people that have worked with the system for 10 years without understanding more than some parts of it. Not because they are bad programmers, but the system is kind of a mess of design principles, and exceptions from these principles for no apparent reason.
  • SenTree 2010-03-03 04:06
    Dave McN:
    Good article & I enjoyed reading it but the real WTF i took from it is 'WTF are all those pictures of dragons and suits of armour on your company's website??' =P

    I get the whole 'slay your issues' theme but seriously, it makes it look more like a Games Workshop fan site, or a site for weekend role-playing, rather than one for a professional software solution.

    I rather liked the dragon, although yes it's probably on the wrong site. What worried me more was this:
    His blog, The Daily WTF, is recognized as one the primary sources of best software practices within the industry...



    Addendum (2010-03-03 05:07):
    and I've just noticed there's a typo in there as well (in the original).
  • Severity One 2010-03-03 04:15
    With the emphasis on the über-Anwendung (once we're using German, might as well continue it), the article seems to sweep together a couple of proper development ideas into one big heap and declaring them evil.

    What's wrong with pre-determined requirements? They're called "non-functional requirements", and unless they're of the kind "the application must be written entirely in SNOBOL, use dBase II on our CP/M-based database server, and handle 1000 transactions a second", they are just as essential as functional requirements.

    What's wrong with code reuse? Or an application framework for that matter? Just because you can muck things up by taking a concept too far, doesn't mean that the concept itself is flawed.

    Maybe it's just my perception, but in very few of the stories or the comments, the support section ever gets mentioned. At least where I work, they love reusing the same components/lilbraries/whatever, because they have expected behaviour and they don't waste time analysing a problem in a completely bespoke application, whilst the customers are not receiving the service they paid for.

    The support section also has a large say in the non-functional requirements.

    But hey, we're developers who all live on Developers' Island, and communication with the support people is strictly unidirectional.
  • yr 2010-03-03 04:34
    I wonder if the acronym for Framework Application Portfolio is related to the application designer's activity.
  • MrOli 2010-03-03 07:52
    An interesting, if technical, article on the path to Code.Hades(), but where's the funny?


    Hush, Gra'hopper, and be taught.
  • Markku Uttula 2010-03-03 10:30
    Ray:
    There's an old saying a couple of my university professors would use for something like this:

    KISS - Keep It Simple, Stupid.


    I think the whole saying goes "KISS A TIT"... for "Keep It Simple, Stupid, And Think It Through". If you miss the latter part, the first part may cause more trouble than benefit in the long run.

    Bim Job:
    Oh yes, and "application metadata?"

    Really.

    If you start abstractions, you easily come up with something like this. First you have settings, and with time you want/need more and more configurability, and in the end it is not just settings anymore, so you need to come up with a "more abstract" name to describe it as to not be forced to use something like "the settings, localisations, etc." all the time. Calling it "metadata" saves you a lot of writing and keeps the end users on their toes because they are forced to play with an unfamiliar concept.
  • SQLDave 2010-03-03 10:34
    mfah:
    Doug:
    I'm pretty sure the UberApplication looks like Norton SystemWorks ...

    It's clearly Lotus Notes. This is exactly the sort of thing that happens with Lotus Notes (which is enough of a WTF in itself).


    DAMMIT DAMMIT DAMMIT. I was all loaded up w/ a "must be Notes" comment, then I saw yours. <sigh>

    This particularly caught my eye as Notes-like: "it was harder to test and deploy, and they never quite fit the business requirements".

  • davedavenotdavemaybedave 2010-03-03 11:09
    Severity One:

    But hey, we're developers who all live on Developers' Island, and communication with the support people is strictly unidirectional.


    Speaking from the support end, it's not unidirectional, as such. The situation's more analogous to receiving email with POP3 and sending with SMTP. Developers send down their decrees from on high in plain(ish) English via direct voice or text communications, but are unable to interpret feedback via that protocol. We support staff have to find other ways of getting the message across - deliberately encouraging users to break the system until it gets fixed, for example, or making sure that the CEO asks to be upgraded to the new (and very buggy) release of the company software so he is forcibly made aware of the bugs.

    If all else fails, the sysadmins can always fit the developers up as work-place kiddy/animal/gravel-porn-viewers without too much trouble. Or the CEO, come to think of it...
  • porky 2010-03-03 12:00
    It's a cock and balls.
  • Jax 2010-03-03 13:22
    Why didn't they just use libraries? Sounds to me like they consolidated the "integration" code as well as the libs and that was their problem.

    Just push common code to some libs and re-do the integration of those common components for each different app. Job done.

    Certainly don't need to re-write it all.
  • Sam 2010-03-03 13:50
    A Nonny Mouse:
    anyone else seeing phantom brown dots on the uniform application portfolio graphic..? maybe i need coffee (or less coffee, depending)

    That's a well known optical illusion.
  • Bim Job 2010-03-03 14:04
    davedavenotdavemaybedave:
    Severity One:

    But hey, we're developers who all live on Developers' Island, and communication with the support people is strictly unidirectional.


    Speaking from the support end, it's not unidirectional, as such. The situation's more analogous to receiving email with POP3 and sending with SMTP. Developers send down their decrees from on high in plain(ish) English via direct voice or text communications, but are unable to interpret feedback via that protocol. We support staff have to find other ways of getting the message across - deliberately encouraging users to break the system until it gets fixed, for example, or making sure that the CEO asks to be upgraded to the new (and very buggy) release of the company software so he is forcibly made aware of the bugs.

    If all else fails, the sysadmins can always fit the developers up as work-place kiddy/animal/gravel-porn-viewers without too much trouble. Or the CEO, come to think of it...
    Good lord, I hope you're not serious about any of that.

    Apart from forcing the CEO to eat his own dog-food. And maybe the gravel-porn thing.

    Have you ever considered the possibility that your POP3 feed from on high is actually a management channel, rather than a developers' channel? Of course, it's possible that you work in the single, solitary environment in the whole wide world where developers issue "decrees."

    In which case, I've got news for you. It's even nastier and considerably more dysfunctional out here...
  • Bim Job 2010-03-03 14:09
    Estabon:
    How does a consultant learn that their entire architecture is wrong in a couple weeks? It's not like he actually knows the business or anything. All he saw was a large complex system he didn't understand and assumed it had to be the wrong way of doing things.
    Don't go into the consultancy business, kid.

    You'll be broke within the week.
  • Postnam 2010-03-03 15:42

    In the real world:
    a) You don't demo your INTERNAL applications to your external customers.
    b) You test all of your applications against changes to the core framework.
    c) You never release a live application in the middle of a multi-million-dollar contract demo (DUH!).


    Remind me not to invite you into the real world.
  • anon 2010-03-03 16:15
    Sounds like Iron Speed.
  • xlfs 2010-03-03 20:24
    "Worse, the requirements conversation shifted from “how can we build software to meet these needs” to “how might we adapt the needs to meet our pre-determined requirements.”"

    This is extremely true in my company. So sad.
  • Dave 2010-03-03 20:36
    Uber-Application may be miss read to think that the decision to develop a frame work is bad. It certainly isn't miss read to think it is easy though :)

    A bad re-use of template/framework/language or component can be because the designer re-using the component is unaware of the reasoning and situation that lead to the creation of the component.

    Sometimes due to lack of assessment of its appropriatness for re-use bad choices are made.

    Sometimes though the decision is a political one that has nothing to do with appropriatness and every poor bastard involved in the project knows they are creating an abomination.
  • dumbname 2010-03-04 04:59
    I would like to christen this as the
    "SAP R3 Anti-Pattern".
  • RogerWilco 2010-03-04 05:31
    mfah:
    Doug:
    I'm pretty sure the UberApplication looks like Norton SystemWorks ...

    It's clearly Lotus Notes. This is exactly the sort of thing that happens with Lotus Notes (which is enough of a WTF in itself).
    I think having a common framework between applications isn't necessarily bad. It's when the conformance to the framework becomes a goal in and off itself that you get into problems.

    But Lotus Notes is a different level altogether. I have the feeling it tries to be its own operating system/window manager.
  • Paul 2010-03-04 06:25
    woah!:
    Instead it ridicules what all software engineers try to achieve: never having to write the same line of code twice.


    I'm not sure about that...

    'never having to write the same lump of code more than three times', possibly.

    If you spend all your time programming with abstraction and reusability in mind, you will take many times longer to produce much more complicated code than necessary.

    The first time you need something, write it for that one time.

    The second time you need the same thing, copy, paste, tweak.

    The third time, make it reusable.

    By the time you need something three times, you pretty much know it's going to be a commonly needed thing. The first time, even though you may THINK you'll need it again, you probably won't, so why waste the time making it reusable.

    Also, by the third time, you have gained much more knowledge about HOW it will be used, and any edge cases, and strange requirements, etc.
  • unknown 2010-03-04 14:39
    Can't you see a dog sleeping in the cloud?
  • Xyclops 2010-03-04 16:48
    SenTree:
    Dave McN:
    Good article & I enjoyed reading it but the real WTF i took from it is 'WTF are all those pictures of dragons and suits of armour on your company's website??' =P

    I get the whole 'slay your issues' theme but seriously, it makes it look more like a Games Workshop fan site, or a site for weekend role-playing, rather than one for a professional software solution.

    I rather liked the dragon, although yes it's probably on the wrong site. What worried me more was this:
    His blog, The Daily WTF, is recognized as one the primary sources of best software practices within the industry...



    Addendum (2010-03-03 05:07):
    and I've just noticed there's a typo in there as well (in the original).


    Why don't the diagonal lines on the main site match up? I couldn't focus long enough to read much text because it made me feel seasick.
  • SenTree 2010-03-05 04:32
    Xyclops:
    Why don't the diagonal lines on the main site match up? I couldn't focus long enough to read much text because it made me feel seasick.
    The red lines are the outline of a sort of fat arrow on the page background. Of course, you rarely see the whole arrow because it's covered by the text box once the page has rendered (I have a very slow connection on some days...).
  • Unanimous 2010-03-05 15:54
    The real wtf is that the cloud looks more like an Alpaca than a dog.
  • John Doe 2010-03-08 07:15
    This technical reasoning in article is crap. Uber apps are usually product of management megalomania, not programmers coding them.
  • e john 2010-03-10 19:26
    By the way - you don't "automate" much less "manage" the software development process with a build tool.

    <shameless_plug>This, along with the medley of technologies and platforms, was why they sought our help in managing and automating their development processes with BuildMaster.</shameless_plug>

    I suspect the poster of being a Salesman, than which there are few less credible.
  • hobart 2010-03-12 08:46
    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 2010-03-13 14:48
    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 2010-03-19 01:36
    Good lord, I'm glad I'm not the only one. I learned my lesson, though; and repented of my sins.
  • cindy 2010-12-16 02:46
    find for all kinds of amazing watches and women handbags

    http://replica038.com/
  • tanus 2012-07-03 00:42
    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.