• Gygax (unregistered)

    Where's the wooden table in the process?

  • DropDeadThread (unregistered)
    1. User presses save button repeatedly, wondering why the hell it's taking so long to process a simple request, taking us back to step 1.
  • Brian (unregistered)

    Sadly, I have to say that I've created one of these.

  • (cs)

    What, no punch cards step? No emailed Word Documents with embedded Excel spreadsheets? Not even so much as a print-to-scan-to-OCR?

    Sorry, but this just isn't even halfway convoluted enough. Must try harder.

  • (cs)

    The biggest problem with systems like this is programmers who think they need all of this bullshit. I can't tell you how many experienced developers I've met who would argue until blue in the fact that you MUST write your own abstraction/mapper layer for ADO.NET, because using the built-in tools is garbage. Or that you MUST abstract everything out into Factories and use half a dozen interfaces, and have AbstractBizObjects inheriting from AbstractCommonObjects, because "professional programmers do it this way."

    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

  • JonC (unregistered)

    Some architect somewhere most likely read a lot of books and decided that the best application must incorporate all the concepts and design patterns from all of the books.

  • Tei (unregistered)

    The Dailty WTF is this Site.

    CAPTCHA: I whas just kidding. The site is enhancing, and is better with all changed. Thanks Alex by the hard work.

  • NiceWTF (unregistered) in reply to Gygax
    Gygax:
    Where's the wooden table in the process?

    I think we can consider XML to be the "wooden table" of 2007 (and 2006, and 2005 for that matter).

    They can be nice and stylish...

    Wooden tables, that is.

  • (cs)

    I think I've spotted the wtf. In step 8 they use reflection to get the right factory. Then in step 10 they look up the object's type using a case statement. But they could have just used the reflection output to get the object type. That way they wouldn't have to add to the case statement every time they added a new type. Duh. Think of the maintenance nightmare.

    Insufficient use of reflection. It betrays weakness.

  • Sherbet (unregistered)

    I've seen systems of this sort at a lot of school districts. They contract a tech guy for 'general networking' and ask him to churn out a system to track maintenance requests or something and he copies 'n' pastes until some kludgy process is deemed 'close enough'. And this is without even dunking them in .NET or web services!

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

  • (cs)

    And to think that sometimes I feel bad for using Reflection to save a few lines because the lack of clear verbosity might confuse someone.

  • Grant (unregistered)

    Oh, crap, I think I worked on this system! The guy who wrote it is actually named Mike!

    The captcha should have been: Enterprisey!

  • (cs) in reply to Brian
    Brian:
    Sadly, I have to say that I've created one of these.
    Sadly, I have to work with one of these after being outvoted by the group who wanted entity factories (I argued for using ADO.Net). All but one of that group are no longer here, but the legacy code remains.

    Well, at least it's enterprisey.

  • sxpert (unregistered) in reply to ObiWayneKenobi

    add to this the managers who somehow heard the words "project management" and "UML" and mutter them about 20 times per meeting thinking that these things are useful for a 1 month project that require at most a couple thousand lines of pure C

  • Villa (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    The biggest problem with systems like this is programmers who think they need all of this bullshit. I can't tell you how many experienced developers I've met who would argue until blue in the fact that you MUST write your own abstraction/mapper layer for ADO.NET, because using the built-in tools is garbage. Or that you MUST abstract everything out into Factories and use half a dozen interfaces, and have AbstractBizObjects inheriting from AbstractCommonObjects, because "professional programmers do it this way."

    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

    You had me up till the overly dramatic "blue comment please" ending.

  • Aleks (unregistered) in reply to ObiWayneKenobi

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

  • nobody (unregistered) in reply to ObiWayneKenobi

    Exactly. This megalithic project was resume fodder for the consultants/developers that built it.

  • (cs)

    Only 18 more steps and their system could do anything!

  • (cs)

    Object/Relational Mapping frameworks or Data Access Objects are often a good thing. The problems here seem to be:

  • (cs)

    You had me at "AJAX".

  • (cs) 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...

    See, having been a member of many a large software project, (1m+ lines of code, multiple integration points, multiple teams)... I've come to the conclusion to keep it as simple as is possible for the given problem and environment. Never try and second guess what future scale and requirements will be. One a set of code needs to do extra work, add in your new logic and then refactor it to make it maintainable, and meet your scaling requirements.

    If from the outset you know the feature to hand is going to have to scale, and have multiple calling apps, and have multiple end points, with some complex state logic, then sure from the outset go with some funky configurable messaging system.

  • N (unregistered) in reply to Aleks

    I've also seen programmers create uber complex messes that take forever for anyone else to work on, mainly because it's such a convoluted mess that you have to almost examine the whole project line by line, as well as programmers who've created giant apps and then run away.

    I don't think that what he was saying was "make it as simple as possible" -- but rather, "don't make it complex because you think you need to".

    That tightrope between being simple yet flexible is the one you need to walk IMO.

    I find it funny, though, that in your statement about not liking blanket statements, you made a few of them yourself.

  • Tei (unregistered)

    Whos the moron that write his opinion on the body of the article? I have fixed the wikipedia article, removing teh guy opinion.

  • Aleks (unregistered) in reply to Grovesy
    Grovesy:
    I've come to the conclusion to keep it as simple as is possible for the given problem and environment. Never try and second guess what future scale and requirements will be.
    Exactly. But not simpler than that :).
    Grovesy:
    If from the outset you know the feature to hand is going to have to scale, and have multiple calling apps, and have multiple end points, with some complex state logic, then sure from the outset go with some funky configurable messaging system.
    Correct. You should not guess and/or make assumptions. In case I did not phrase my opinion properly: I am not proposing complex development from the beginning. That should be avoided. However, oversimplification can have terrible results as well. No assumptions/guesses is the key.
  • Jon (unregistered)

    .... Kiss..... Unchecked... Keep it simple stupid!

  • Josh (unregistered) in reply to ObiWayneKenobi

    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!

  • Boo B. Feeler (unregistered)

    Oh, if these people only knew the POWER of the letter R. I once saw the letter R transform a horrible hiddeous Beast into a lovely luscious Breast. I keep an R on payroll just for such occasions.

  • HackerByDay (unregistered)

    But does it send email?

  • Jax (unregistered)

    Yeah the whole IFactory business sounds like someone has read a book with the Factory pattern and has run with it until they've plummeted off a cliff. I've recently removed most of the factory objects from the current source I'm working on as they did nothing that a constructor wouldn't be able to do.

    Sure, apply the pattern if external objects need to register the object or such like but just blithely applying patterns like that is the road to creating such an unmaintainable beast.

  • Fister (unregistered)

    I thought steps 1 and 2 were reasonable. However, at the point where they use a switch statement in 10 after having used reflection in 8, you know they're in the woods :-)

    "Long Term Plans" are highly overrated. In three cases out of four, you ain't gonna need it, and in the fourth case, what you end up needing actually turns out to be different than what you built up front. It's really not hard:

    1. Look at highest-priority requirement from leadership.
    2. Build the simplest thing that actually works.
    3. Make sure it tests out alright, using automated test cases.
    4. Clean up that solution BEFORE you call it done.
    5. Repeat.

    You save a lot of time by not implementing things you don't need right now. That saved time should be banked, and used when the actually required hard change requirement comes down from leadership.

  • Anonymous Simplifier (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...

    There are right ways and wrong ways to future-proof your design. Absent a specific future roadmap, guessing how your app might be used years from now and abstracting everything you can think of is definitely the wrong way.

    Generally, writing things as simply as possible while still maintaining enough modularity that you can add functionality piecemeal is the way to go.

  • Foo (unregistered) in reply to Aleks

    Yes, one should in general write code that is generalized, however one also needs always to focus on code that WORKS first. Complex systems are evolved from simpler ones, they can never be created from scratch (a.k.a. the "Second System Syndrome").

  • Mizchief (unregistered)

    These types of system are often produced by companies that have well educated developers, but poor planning and requirements.

    I'm in a similar position where I work now. During the entrie design process we had no requirements or general direction from the business guys, so what happend was us having to solve a lot of "What if" questions.

    What if they want to sell this to a enterprise company that may need custom functionality for this module? What if the client needs more fields that we can imagine at this phase? What if they want to sell this in 3 diffrent languages? What if they actually hire the 10 new developers they have been saying for years? How do we divide the work so eveyone has something to do without getting in other dev's way?

    What happed was that a small group of 5 devs created a highly extensible application that actually has a good framework, but only a slim set of actual usable features. So now we are forced to target only small businesses, where if we knew we only wanted to target small business we could have had a much more feature-rich app in half the time.

  • (cs)

    I guess I missed the part where the ax falls to cut the string to light the match to light the candle to light the fuse of the firecracker to wake up the dog to scare the cat to chase the mouse into the trap.

  • Terrier (unregistered) in reply to Aleks

    "Worse is better" anything else is just bull. Possibilities you cannot see? Dragons hidden in a bush? Patterns? How about the "actually works" pattern?

  • BartMan (unregistered)
    1. It is not truly an enterprise WTF until it does email
    2. It explains a lot of the WTF job descriptions that require expert knowledge of every freaking technology that could ever be learned in a "Learn X in 24 hours" book
    3. Stream of consciousness thought was "They stab it with their steely knives but they just can't kill the beast"
  • (cs) in reply to Aleks

    I'm inclined to give ObiWayneKenobi the benefit of the doubt and assume he just didn't state his true meaning as elegantly as he could have.

    What I believe he was trying to say, and what I know I'm saying, is that an application should be as simple as it possibly can be, but no simpler.

    To your point Aleks, the system described, for all we know, actually is as simple as the process can be. I think we'd all agree we doubt it from what we see here, but you're right, there could be factors we're not aware of that makes our impression invalid.

    When I architect applications, I'm constantly thinking to myself "can I make this any simpler?", and I think that's the approach you have to take if you want the thing to be maintainable down the road. But, you can't simplify at the expense of extensibility: you have to assume that the application will be around for years, long after you're gone, and will morph multiple times over that timespan. Making it too simple will impede everyone's ability to extend and grow the application, but so will making it too complex in the first place. There's definitely a balance to strive for, and it's not easy.

    I work in the Java world, my .Net experience is limited, but I know we Java folks seem to love our abstractions! We loves us some OOP! Factories, singletons, huge class hierarchies, patterns up the wazoo, it's all par for the course. And, to be sure, there's good reasons for all of it. But I can't count how many times I've seen people just going way too far with it all when they didn't really have to, and you wind up with code that is next to impossible to comprehend (I love it when you have a JVM with 12Gb of memory available, and yet you have developers that make every class a singletone and justify it by saying it's more memory-efficient... sure, it is, but a couple of static methods on a utility class is nearly as efficient, certainly the different doesn't matter in that environment, and is, to some extent at least, simpler).

    Remember too that being able to maintain a system also means being able to get new people up to speed and useful in an acceptable amount of time on it, and unnecessary complexity is your enemy in this regard. But it's that "unnecessary" qualifier that's important there: some degree of complexity is necessary, it's your job to figure out what the right amount is and don't go much above or below that line.

  • SC (unregistered)

    Hmm.. they've over-engineered their solution, but even then, they're on a way better track than most developers.

    ...if it's properly documented and it works, that is.

  • Aleks (unregistered) in reply to SC
    Anonymous Simplifier:
    Generally, writing things as simply as possible while still maintaining enough modularity that you can add functionality piecemeal is the way to go.

    Reiterating: not assuming anything is the way to go. Things should be done as simple as possible (I strive for this much more than you assume) but you should not go simpler than that (you are making assumption...)

    fzammetti:
    Remember too that being able to maintain a system also means being able to get new people up to speed and useful in an acceptable amount of time on it, and unnecessary complexity is your enemy in this regard. But it's that "unnecessary" qualifier that's important there: some degree of complexity *is* necessary, it's your job to figure out what the right amount is and don't go much above or below that line.

    Nicely stated. Agreed.

  • (cs)

    is "AJAX/JavaScript framework" supposed to mean than it contains A LOT of javascript ?

  • (cs) in reply to Aleks
    Aleks:
    Again: I am not defending the company stated in the article, but argue against blanket statements made by those like ObiWayneKenobi...

    I actually agree with you to a point. In my experience though, it's usually a lot more effort to rewrite what already exists, and it makes it harder for new people to understand since you chose to abstract away everything for no good reason.

    I'm not saying its always bad to write your own mappers, but it's bad to somehow think its "more professional" than not doing it, and that "using Typed Datasets for a DAL is for 'Morts'". Basically, I'm saying elitism is bad.

    What I've found is a lot of software developers think that the quality of their profession is in the code. IMO this is wrong. The quality of a software developer is in how they tackle the business problem. Now, that doesn't mean to hack together shit and pass it off as a program, but on the other side of the coin it (IMO) doesn't mean spend months on a "perfect architecture". We've all seen, through this site, what usually happens when developers try to make a system the be-all, end-all of ERP/CRM/Web/Whatever. The results usually aren't pretty.

    Personally, when I write code I try for a mix. I won't hack together garbage, but I also won't spend an inordinate amount of time writing custom mapper classes or abstract object hierarchies or "Enterprise Rules Engines" if it's not worth it. Why send an ox-cleaver to kill a chicken?

  • Phil (unregistered)

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

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I can't tell you how many experienced developers I've met who would argue until blue in the fact that you MUST write your own abstraction/mapper layer for ADO.NET, because using the built-in tools is garbage. Or that you MUST abstract everything out into Factories and use half a dozen interfaces, and have AbstractBizObjects inheriting from AbstractCommonObjects, because "professional programmers do it this way."
    To be fair, knowing when to abstract out and when to KISS can be a real tricky thing. I tend to abstract out until I have a class with core logic, with all the tedious support processing going on in the superclass(es).

    Abstracting out the logic itself is the final drop though, that's when enterprise-y kicks in, full force, and sense is kicked out.

  • (cs) in reply to ObiWayneKenobi
    fzammetti:
    I'm inclined to give ObiWayneKenobi the benefit of the doubt and assume he just didn't state his true meaning as elegantly as he could have.
    ObiWayneKenobi:
    I actually agree with you to a point.
    Aleks:
    Nicely stated. Agreed.
    Hmmm... well-argued and repectful posts, reasoned counter-points based on intent rather than literal interpretation, all prodided with a healthy dose of decorum, and a recognized lack of base name-calling... you three *do* realize you're on The Daily WTF message board, correct?

    /my hat's off to you all for providing valuable commentary and insight into this matter

  • (cs) in reply to Foo
    Foo:
    Yes, one should in general write code that is generalized, however one also needs always to focus on code that WORKS first. Complex systems are evolved from simpler ones, they can never be created from scratch (a.k.a. the "Second System Syndrome").

    You are confused about the definition of Second System Syndrome. It says nothing about how complex a first system can be.

  • (cs) in reply to gabba
    gabba:
    But they could have just used the reflection output to get the object type. That way they wouldn't have to add to the case statement every time they added a new type.
    Or they could have used method dispatch, which is much faster. Just put whatever action that depends on the object's type into a template method that the object implements. If they just need the type as a string, that's even easier. In Java, just call object.getClass().getName(), done.
  • joek (unregistered) 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...

    I think what the main issue with this WTF is not whether a system is "simple" or "complex" but rather, has the complexity you've built in to your system actually benefited your company/customer any? And you would measure that benefit in terms of performance, scalability, and maintainability etc.

    Clearly, the system is not maintainable if making a simple change like adding a field to a very simple entry page causes your developers to seek employment elsewhere.

  • (cs)

    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?

  • (cs) in reply to caffeinatedbacon
    caffeinatedbacon:
    you three *do* realize you're on The Daily WTF message board, correct?

    /my hat's off to you all for providing valuable commentary and insight into this matter

    Yeah. If you don't knock it off, you're going to give this place a good name.

Leave a comment on “The Beast”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article