• Bim Job (unregistered)

    Oh yes, and "application metadata?"

    Really.

  • (cs) in reply to Bim Job
    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!

  • (cs) in reply to Franz Kafka
    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 (unregistered) in reply to frits
    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 (unregistered) in reply to mfah
    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.

  • (cs)

    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.

  • (cs) in reply to DES
    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 (unregistered) in reply to md5sum
    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 (unregistered) in reply to dkf
    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 (unregistered)

    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 (unregistered) in reply to laoris
    laoris:
    I think that cloud looks more like a llama, actually.
    I've changed my mind. It's a [image] yak.
  • Dave McN (unregistered)

    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 (unregistered) in reply to ObiWayneKenobi
    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 (unregistered)
    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 (unregistered)

    It's a fire hydrant

  • Aussie Contractor (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to Franz Kafka

    [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]

    4. 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.

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

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

  • MadX (unregistered)

    The Uber Application resembles my Windows Desktop. Or do I see a llama?

  • Craig (unregistered) in reply to A Nonny Mouse

    Your coffee levels are fine; it's an optical illusion: http://en.wikipedia.org/wiki/Grid_illusion

  • (cs) in reply to Slicerwizard
    Slicerwizard:
    What the hell are "authorization principals"?
    Not a typo, just a highly-specialised technical term. Google it.
  • oheso (unregistered)

    llama.

    Anyone who sees anything else needs to modify their medication levels.

  • awefawef (unregistered)

    How is this a WTF? He was simply using SAP, or any other ERP that jams everything together into one Uber-App.

  • (cs) in reply to ClutchDude
    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 (unregistered)

    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.

  • (cs) in reply to Dave McN
    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).

  • (cs)

    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 (unregistered)

    I wonder if the acronym for Framework Application Portfolio is related to the application designer's activity.

  • MrOli (unregistered) in reply to SuperAnalyst
    An interesting, if technical, article on the path to Code.Hades(), but where's the funny?

    Hush, Gra'hopper, and be taught.

  • Markku Uttula (unregistered) in reply to Ray
    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.

  • (cs) in reply to mfah
    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".

  • (cs) in reply to Severity One
    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 (unregistered)

    It's a cock and balls.

  • Jax (unregistered)

    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 (unregistered) in reply to A Nonny Mouse
    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 (unregistered) in reply to davedavenotdavemaybedave
    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 (unregistered) in reply to Estabon
    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 (unregistered) in reply to md5sum
    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 (unregistered) in reply to Anonymous

    Sounds like Iron Speed.

  • xlfs (unregistered)

    "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 (unregistered)

    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 (unregistered)

    I would like to christen this as the "SAP R3 Anti-Pattern".

  • (cs) in reply to mfah
    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 (unregistered) in reply to woah!
    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 (unregistered)

    Can't you see a dog sleeping in the cloud?

  • Xyclops (unregistered) in reply to SenTree
    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.

  • (cs) in reply to Xyclops
    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 (unregistered)

    The real wtf is that the cloud looks more like an Alpaca than a dog.

  • John Doe (unregistered)

    This technical reasoning in article is crap. Uber apps are usually product of management megalomania, not programmers coding them.

  • e john (unregistered)

    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.

Leave a comment on “Patterns of Failure”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article