• Alcari (unregistered)

    Ugh, it's like an onion of bad coding and poor choises. Start with a functional core program and add 30 years of various programming hacking at it, in whatever language they prefer, to make it do a little bit more.

    and you end of with 10-second-save-operation monstrocities such as these.

    Did we switch to latin CAPTHCAs?

  • troels (unregistered)

    Wow, a 24-tier architecture!

    ... oh, and I'd like to upmod s. for the comment about '''The "garage style" and the "enterprise style".'''

  • (cs) in reply to Aleks
    Aleks:
    Those people propose "just do it the simplest way" approach. Well, that works if you are going to run away. In most other cases it does not. We could also talk about "lean" development which proposes development without forward looking assumptions - most people take this as "choose the assumption that yields the simplest code now". Wrong.

    The simplest way is usually the best and easiest way. It is easy to write, easy to maintain, and easy to extend. Ok maybe I'm not talking about the most simplest way, as it is slightly harder to write generic code than to write specific code. The point is if you have two systems the simpler system is almost always better.

    The simpler a system is, the easier it is to maintain, and the fewer bugs it will have.

  • (cs)

    Ok... so let me get this straight...

    Second we "Custom AJAX/JavaScript framework captures all fields into an XML document and sends to a webservice via an XmlHttp request" So at this point, we have an XML document that represents the data?

    Thirdly: "Web service code creates a graph of 'business entity objects'" Sweet so we've converted the XML document into an easy to use graph(hmmm what sort of datatype is a graph?) This sounds good. This graph should be easier to parse and to work with than XML. Excellent!

    Fourth: "Objects are serialized into an XML document through a custom serialization engine"

    Uhhhhh.. Uhhhhhh.. Uhhhhh.. Didn't we already have an XML document?

    XML like any tool has its uses. But once that XML crossed the boundary from client to server it pretty much outlived its usefulness. Reading the process list sounded to me like someone took a 10 step process and said... "I know how to fix this, I'll add XML..." And ended up with 24 steps.

  • Some Guy (unregistered)

    Some applications need lots of flexibility. Some applications bend in ways they shouldn't.

    Sensible applications are made out of nicely separated, robust pieces with well-defined roles. This kind of application appears to have been made out of tinker toys.

    Sure, you can reconfigure it and make it do almost anything, but you'll spend all your time trying to keep the damn thing from falling apart.

  • Alan Shutko (unregistered) in reply to Aleks
    Aleks:
    One more thing. I've seen numerous comments made here by those who obviously never had to actually develop a large software product and then maintain it long term. Instead, they create something (simple) and then run away as far and as fast as they can.

    That's close to the background of a great many developers I work with who overdesign monstrosities like this. Generally, they've developed a medium-sized product and maintained it through a few releases. They've seen a couple cases where "Gee, if I had done things this way, this particular change would be so much easier." And then comes the second system effect, where they go crazy thinking up extension points to every possible thing they can think of. But they've never maintained anything long term, so they have no idea how much effort they're wasting building things that won't get used, or putting in code in advance to make one type of modification easier, which makes other modifications more difficult.

    Too often, this type of design changes a modification from "change one file in your primary implementation language and modify the database structure" to "change two files in your primary language, a few XML files, add a bunch of rows to several tables in the database, and by the way, you have to do this across five projects." All so that a certain type of modification (that rarely is required, as it turns out) is less work than doing it in simple and clear code.

  • tray (unregistered)

    Thank God I'm a C++ programmer!

  • no (unregistered)

    There's always a big case statement somewhere.

  • nick (unregistered)

    i've limited experience with large apps

    there's one ms guy who told my ex boss that apps should be as "close" to DB as possible.

    for me, i didn't care. the complexities i've experienced resulted in low morale and loss of programmers.

  • Ken (unregistered) in reply to Aleks
    Aleks:
    While I agree that this particular occurence seems to have all prerequisites for WTF certification, I cannot generally agree with previous comment from "ObiWayneKenobi".

    We have seen their past WTF and the fact that they seem to transform data back and forth many times for apparently no good reason.

    However, my experience has thaught me to account for possibilities I cannot see immediately. Are there any long term plans for this app? How long? How extensible does it need to be? How many components does it have? What are its integration requirements? It may not be as simple as it seems...

    One more thing. I've seen numerous comments made here by those who obviously never had to actually develop a large software product and then maintain it long term. Instead, they create something (simple) and then run away as far and as fast as they can.

    Those people propose "just do it the simplest way" approach. Well, that works if you are going to run away. In most other cases it does not. We could also talk about "lean" development which proposes development without forward looking assumptions - most people take this as "choose the assumption that yields the simplest code now". Wrong.

    Again: I am not defending the company stated in the article, but argue against blanket statements made by those like ObiWayneKenobi...

    Said like someone who has somebody else's money to spend. Why would you build in all that complexity for an app with a user-base only in the hundreds? Must have cost / continue to cost a fortune to be that "flexible". Would you buy a ranch instead of an apartment, just in case you decide to get some horses later?

  • ajk (unregistered) in reply to bryan986

    sounds like a real Rube Goldberg machine - gratz!

  • Barney (unregistered) in reply to bryan986

    This is a typical example when computer "scientist" and other "experts" come up with an over-engineered solution.

  • Aleks outed! (unregistered) in reply to Aleks

    MEMBER OF MIDDLE-MANAGEMENT FOUND

  • NewbiusMaximus (unregistered) in reply to Aleks
    Aleks said: One more thing. I've seen numerous comments made here by those who obviously never had to actually develop a large software product and then maintain it long term. Instead, they create something (simple) and then run away as far and as fast as they can.

    And of course those that have had to maintain systems long term frequently get to clean up the mess of the code-and-runners. Sometimes you don't get permission/time/resources to clean it all up correctly, and you end up with code that does things for no good reason. Sometimes there really was a reason, but it was done away with and nobody had time to remove the code that was no longer needed.

    Yeah, it's fun to point and laugh at crazy code (I know I've done my share), but crazy code isn't always the result of somebody's total incompetence. Real life is often complicated enough to make people choose to do things in a way that can be ridiculed by somebody that doesn't know all the details.

  • (cs) in reply to Aleks
    Aleks:
    Those people propose "just do it the simplest way" approach. Well, that works if you are going to run away. In most other cases it does not. We could also talk about "lean" development which proposes development without forward looking assumptions - most people take this as "choose the assumption that yields the simplest code now". Wrong.
    In my experience, overly complicated systems break much earlier due to the large number of components and dependencies. Whenever a new version of a library, a framework, a database system etc. arrives, you can only hope the system will survive the upgrade. Maintenance is difficult since the same bits of information are copied into many abstraction layers, using different languages, e.g. a HTML page, a javascript program, a DTD, a C++ program, a stored procedure, a database table, etc., all of which must be changed just to add a new field. If you are unlucky, the development tools required for one layer might become discontinued one day, forcing a feature freeze or absurd workarounds in the other layers.

    For that reason, I'm a strong proponent of the "Do the simplest thing that could possibly work" rule.

  • Dan Krüsi (unregistered) in reply to s.
    s.:
    Gygax:
    Where's the wooden table in the process?

    You're confusing the two standards of WTF apps. The "garage style" and the "enterprise style".

    If these were carpenter works, the first would be driving nails into wood using a screwdriwer's handle (because you've hit your finger with a hammer and deemed it 'insecure') while the other is where you build a hammer factory factory factory (a factory that builds custom factories that build factories building specific tools, say specific kinds of hammers).

    Great analysis - agreed!

  • Jens (unregistered)

    Yeah well the problem arises when what is essentially trivial changes requires changes at every link of the chain. If you implement these things correctly it should be enough to make a couple of changes to the business rules of the system, e.g. what information is required to fill out an order or something. Such changes should automatically propagate throughout the system.

  • (cs) in reply to bryan986
    bryan986:
    Only 18 more steps and their system could do anything!

    No, no, no. It WILL do everything. Hilarious :)

  • Rune (unregistered) in reply to Aleks

    As a reply to the above messages.

    I work at a company that has build a large piece of software that needs to be maintained long-term. It's a simple 3-tier model with a database(cluster) backend, a ****load of custom application serves and another bucket of webservers. Ofc a SOAP interface is included. And I can tell, almost none of the terms used in the big corporate example are used by us. And yet, the application is still easy to maintain. The simplest way does not necessarily mean that it's also the least maintainable way. You just need a good design.

  • (cs)

    Hmmm <tastes code> needs more XML!

    Actually the real WTF is that the forgotten password email (for some reason the site had forgotten who I am) still says "Worse Than Failure". I mean - the site has been renamed again for a WHOLE DAY!

    No excuses - that's just sloppy.

  • (cs) in reply to Phil
    Phil:
    People need to begin "large" software projects by using the most straightforward approach, and then abstract and generalize things ONLY when it will be used in 3 or more locations in the code. And ONLY when there is a clear case of how this improves things.

    I thought this was one of the 'mantras' of good programming.

    1. If you need something once, just write it for that one situation
    2. If you need it twice, write it again - probably based on the first time, possibly using cut & paste
    3. If you need it three times, consider generalising it

    People who generalise at step (1) are making things a lot harder for everyone involved - themselves AND maintainers.

    It's generally a lot quicker and easier to write and maintain non-generalised code than generalised code.

  • Tei (unregistered) in reply to Phil
    Phil:
    @Aleks

    You know what the most extensible software ever created was? A programming language! If your goal is to have a maintainable and extensible program, the best way is to just write code that solves the problem in a clean way. People need to begin "large" software projects by using the most straightforward approach, and then abstract and generalize things ONLY when it will be used in 3 or more locations in the code. And ONLY when there is a clear case of how this improves things. Not blind religious dogma design pattern faith where you turn off your rational faculties and blindly do what someone else tells you to do because you are scared to use your own mind.

    After years of "architects" creating monstrosities, the general perception is that coding is hard so developers go through huge contortions to add indirection to their code in the wishful thinking of eliminating the need for code all together. They believe the contradiction of magically more maintainable code by creating indirection and complexity.

    Computers are best controlled by programming languages. Anyone who attempts to create full extensibility above the programming language is a fool and don't pretend like you don't see that happen over and over and over again.

    I agree with you. But OOP adds architecture code, and can result and simpler solutions.

  • Shakje (unregistered) in reply to ObiWayneKenobi

    While ObiWayneKenobi's comment is not something I would generally agree with, it is qualified with the 'because "professional programmers do it this way"' point. Anyone who is doing something purely because it is the way it is done shouldn't be adding uneccessary complications. The point of design patterns, or rewriting some API calls is down to experience, or knowing a very good reason to do so. Factories have their place, as do well designed interfaces, but using them all over the place without any real reason to do so is pointless.

    Implying that anything that improves extensibility, increases the company codebase or makes code easier to maintain is all bad means I cannot possibly agree with the whole comment, since I have seen plenty of code that not only introduces unnecessary complications, but blatantly ignores established design patterns and laughs in the face of extensibility, both of which would have made my job a hell of a lot easier.

  • James (unregistered)

    I'm in favor of developing using the simplest code possible to implement what you think they're going to want in near-to-mid future.

  • Dan (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    No, thanks. The fact that these systems go into production, and the developers pat themselves on the back for being so professional, and totally ignoring built-in tools that would make it a lot easier, is truly WORSE THAN FAILURE

    Hey... Worse Than Failure! That'd make a great name for a website about IT disasters.

  • Bob (unregistered)

    I'm getting to the stage of downgrading candidates at interviews if they sound too 'academic'. As soon as they start wittering on about factories, abstraction, etc, I start to wonder what their 'Hello world' would look like.

  • Adi (unregistered)

    COM+ is lacking.

  • Atario (unregistered) in reply to Aleks

    One word:

    YAGNI

  • (cs) in reply to Bob
    Bob:
    I'm getting to the stage of downgrading candidates at interviews if they sound too 'academic'. As soon as they start wittering on about factories, abstraction, etc, I start to wonder what their 'Hello world' would look like.

    Maybe that should be a programming test: "write what you would consider a well architected 'hello world' program"

    Anyone who writes something over 5 lines long gets thrown out. ;)

  • (cs) in reply to m0ffx
    m0ffx:
    Off topic: Are other people finding the forums are broken?

    I get http://forums.thedailywtf.com/ giving a 302 redirect to http://forums.worsethanfailure.com/Default.aspx, which DNS lookup then fails on. WTF?

    Yes, I'm having problems as well - same as you.

    Add

    74.50.106.245 forums.worsethanfailure.com

    to your hosts file

  • Blip (unregistered) in reply to Aleks

    One thing is for certain; even if You spend the next year figuring out what might be needed in the future, You will find that when the dreaded change request arrives, You'll need to write new code and "refactor" anyway.

    Thus; My simple advice is; spend that time later, but don't be an idiot.

  • Anonymous Coward (unregistered)

    Appears that somebody did the twelve step program, TWICE.

  • Cloak (unregistered) in reply to Aleks
    Aleks:
    While I agree that this particular occurence seems to have all prerequisites for WTF certification, I cannot generally agree with previous comment from "ObiWayneKenobi".

    We have seen their past WTF and the fact that they seem to transform data back and forth many times for apparently no good reason.

    However, my experience has thaught me to account for possibilities I cannot see immediately. Are there any long term plans for this app? How long? How extensible does it need to be? How many components does it have? What are its integration requirements? It may not be as simple as it seems...

    One more thing. I've seen numerous comments made here by those who obviously never had to actually develop a large software product and then maintain it long term. Instead, they create something (simple) and then run away as far and as fast as they can.

    Those people propose "just do it the simplest way" approach. Well, that works if you are going to run away. In most other cases it does not. We could also talk about "lean" development which proposes development without forward looking assumptions - most people take this as "choose the assumption that yields the simplest code now". Wrong.

    Again: I am not defending the company stated in the article, but argue against blanket statements made by those like ObiWayneKenobi...

    KISS is what comes to my mind first. They will certainly not NEED all that stuff. And if they do in 10 years you have had 100s of users + hardware suffering from an eventual extension somewhen in the future (the new system is about to come soon...). Just ridiculous. But I imagine the 1000s of hours at some 50 to 100 dollars each. That was, of course, a deal with the consultant company the consultants couldn't resist. A simple system that does the same would just have meant one person working for 6 months. But here that must have been some 20 persons working for 2 years. That is, of course, an argument during a period of unemployment...

  • Cloak (unregistered) in reply to Josh
    Josh:
    The real WTF in all of this is the environmental impact that such garbage has.

    Take all of those extra CPU cycles needed to run all of those factories, configuration bits, and message-passing bits, and multiply it by all the requests you'll get. It adds up to lots of wasted CPU cycles, which results in more heat output and more energy usage.

    Creating such complexity might stoke your ego, but it also causes global warming... so STOP IT, dammit!

    Sounds silly what Josh wants to tell us but OTH it would be interesting to have kind of a measure as to how wasted energy this could be. I think we would all be quite surprised.

  • bullet (unregistered) in reply to Aleks
    Aleks:
    While I agree that this particular occurence seems to have all prerequisites for WTF certification, I cannot generally agree with previous comment from "ObiWayneKenobi".

    We have seen their past WTF and the fact that they seem to transform data back and forth many times for apparently no good reason.

    However, my experience has thaught me to account for possibilities I cannot see immediately. Are there any long term plans for this app? How long? How extensible does it need to be? How many components does it have? What are its integration requirements? It may not be as simple as it seems...

    One more thing. I've seen numerous comments made here by those who obviously never had to actually develop a large software product and then maintain it long term. Instead, they create something (simple) and then run away as far and as fast as they can.

    Those people propose "just do it the simplest way" approach. Well, that works if you are going to run away. In most other cases it does not. We could also talk about "lean" development which proposes development without forward looking assumptions - most people take this as "choose the assumption that yields the simplest code now". Wrong.

    Again: I am not defending the company stated in the article, but argue against blanket statements made by those like ObiWayneKenobi...

    "However, my experience has thaught me to account for possibilities I cannot see immediately " Coul not disagree more with this statement. It is a mistake to build functionality into a system that is not required. If you're talking about designing a system to allow for extensibility in known and anticipated directions, sure, that's fine, but adding the level of complexity of say a Windsor container and MVPC front end, just because that offers maximum extensibility in directions that are not anticpated is crazy. The level of introduced complexity is extraordinary, and to anyone examining the code later, the apparent lack of any obvious reason for it makes the code harder to understand and therefore harder to maintain than if it was written to simply do what it needed to do.

  • Aleks (unregistered) in reply to bullet
    bullet:
    "However, my experience has thaught me to account for possibilities I cannot see immediately " Coul not disagree more with this statement. It is a mistake to build functionality into a system that is not required.

    That comment was not meant for designing software but evaluating articles on this site. Sorry. This site is great for all sorts of WTFs but sometimes we just don't know whether the product is WTF or its requirements are...

  • J (unregistered) in reply to caffeinatedbacon

    Yes, clearly, many of these people have completely forgotten that they're on the Internets.

    These comments have actually made great reading. I'm pretty new out of college, I have studied design patterns, and I'm trying to build my own piece of software. It's good to see well-reasoned opinions that don't immediately leap to the two oft-seen extremes of "Design-pattern-hatred" and "Design-pattern-worship."

    Thanks for the intelligent comments.

  • :-X (unregistered)

    Needs more XML. :-X

  • YourMoFoFriend (unregistered)

    Crap, I could swear I worked on one of those...

  • The Great Quux (unregistered) in reply to Aleks

    Aleks -

    The issue is that premature optimization (or premature overdesign) is (one of the) roots of all evil. If the first system is designed to be 'too simple' and the client is growing beyond it, the answer is to learn from the first design and build a better one. Again, here you have to avoid the second-system effect (the temptation to throw in everything you missed the first time). A simple system can be redesigned and even modestly changed a lot easier than a large one, and that kind of inertia kills a lot of development projects. In the above WTF, the submitter ran away from the large system too!

    CAPTCHA: luptatum

  • coder (unregistered) in reply to Aleks

    but argue against blanket statements made by those like ObiWayneKenobi...

    Your an ass, and "Architects" just like you are responsible for why software sucks

  • Ringo (unregistered)

    Lately I've been getting the impression people are coming up with unnecessary levels of abstraction and complexity just to justify their jobs and large budgets. Sure, the system could be written as Perl CGI scripts by one guy in a couple weeks, but that won't let you use buzzword1 and buzzword2, and it won't keep your team of 15 developers busy.

    A huge "enterprise" system might be necessary when your site gets thousands of hits an hour, but for most sites it's just overkill.

  • Jenda (unregistered) in reply to bryan986
    bryan986:
    Only 18 more steps and their system could do anything!

    The fun is that it WOULD do anything. And noone would have any chance to find out what.

  • Jenda (unregistered) in reply to Ringo
    Ringo:
    Lately I've been getting the impression people are coming up with unnecessary levels of abstraction and complexity just to justify their jobs and large budgets. Sure, the system *could* be written as Perl CGI scripts by one guy in a couple weeks, but that won't let you use buzzword1 and buzzword2, and it won't keep your team of 15 developers busy.

    A huge "enterprise" system might be necessary when your site gets thousands of hits an hour, but for most sites it's just overkill.

    And I bet my trousers (which ever pair you choose) that a Perl (that is mod_perl, FastCGI, PerlEx or something like that) solution would have a much better chance to survive the load than that tower of Babel of layers over layers over layers.

  • Jenda (unregistered) in reply to s.

    That would be EU approved garage style. Except that it would not. There would be too many regulations and mandatory protections to even dare to have a garage, much less to try to actually do anything there.

  • (cs) in reply to Aleks
    Aleks:
    However, my experience has thaught me to account for possibilities I cannot see immediately. Are there any long term plans for this app? How long? How extensible does it need to be?
    The standard reply to this kind of thing is YAGNI. You ain't gonna need it.

    Building an infinitely-extensible monstrosity today, because someone thinks they're going to really take advantage of all that extensibility in ten years' time when the business needs it, is a huge mistake. You really, truly, seriously, should not be doing work today for which you do not have a business case today.

    Look, if your code is written well, it will be just as cheap to extend it in ten years' time if the business need genuinely does arise. Conversely, if you make it horribly complicated by abstracting things to death "just in case", it will be more difficult to extend in ten years' time, because by then all the people who understand the hideously complicated design will have left the company anyway.

    (Other people may well have made these points already. I don't know, because I no longer read anything but the featured comments. Well done, Alex... yet another brillant idea turns out to have predictable disadvantages! :)

  • 99% (unregistered) in reply to Aleks

    99 percents of the systems mannered in such a way are claimed to be long-term. Actually. none of them survives the firt impact with the reality - when one of the shitdevelopers quits.

  • (cs)

    Kiss comes to mind. "Strutter" especially.

  • edcode (unregistered) in reply to Iago
    Iago:
    Aleks:
    However, my experience has thaught me to account for possibilities I cannot see immediately. Are there any long term plans for this app? How long? How extensible does it need to be?
    The standard reply to this kind of thing is YAGNI. You ain't gonna need it.

    Building an infinitely-extensible monstrosity today, because someone thinks they're going to really take advantage of all that extensibility in ten years' time when the business needs it, is a huge mistake. You really, truly, seriously, should not be doing work today for which you do not have a business case today.

    Look, if your code is written well, it will be just as cheap to extend it in ten years' time if the business need genuinely does arise. Conversely, if you make it horribly complicated by abstracting things to death "just in case", it will be more difficult to extend in ten years' time, because by then all the people who understand the hideously complicated design will have left the company anyway.

    (Other people may well have made these points already. I don't know, because I no longer read anything but the featured comments. Well done, Alex... yet another brillant idea turns out to have predictable disadvantages! :)

    ++

  • Verloc (unregistered) in reply to Ringo
    Ringo:
    Lately I've been getting the impression people are coming up with unnecessary levels of abstraction and complexity just to justify their jobs and large budgets. Sure, the system *could* be written as Perl CGI scripts by one guy in a couple weeks, but that won't let you use buzzword1 and buzzword2, and it won't keep your team of 15 developers busy.
    Pretty much this. In fact, I do not think that The Beast belongs on here at all. I think that it is a well engineered and elegant solution. The real WTF here is all the people who are thinking that The Beast has anything to do with solving the problems of the end users. No, The Beast instead answers several other questions for us. For Management, "How do we build and maintain our personal empire within the company?". For an 'Architect', "How do I cram even more buzzwords onto my resume?" and "How do I get these suckers to give me a huge pile of money?".

Leave a comment on “The Beast”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article