• pitchingchris (cs)

    Ha Ha, everybody would know its April fools day for sure. First ?

  • JimM (unregistered)

    priceless. And also, scarily familiar from some of the RAD / Agile evangelism that's out there.

    You know, I might even learn to be a fan of FAD - it makes a lot of sense! You're coding for the customer, so you do what you can to keep the customer happy. No-one expects software to work properly anymore, so why waste time trying to write software that does work? Write software that looks / acts how the customers expect, than patch functionality later! It makes sense!! BRILLANT!!!

  • y0y (cs)

    Someone is totally going to be at lunch with their coworkers today evangelizing about this awesome new approach they read about known as FAD. "Maybe we should give it a try? Sounds like a no bullshit, down to earth approach.. and there are no marketing buzzwords like 'scrum'. What is that anyway? Sounds like a medical term for goat genitals."

    Seriously. :l

    At any rate, well done!

  • rc_pinchey (cs) in reply to pitchingchris

    I for one am appalled at the new direction the site has taken, evangelising inappropriate-sounding software methodologies and adding lolcats. Everything is the last straw, I've had enough, I'm deleting my bookmark and terminating my RSS feed and drilling my hard-disk and feeding my testicles to a shark. I hope you're happy.

  • wtfbbqlol (unregistered)

    The Real WTH is that this still hits close to home. April Fools indeed.

  • phelyan (cs)

    Yup, far too close for comfort.

    Might send that around on the internal list, actually...

  • your mom (unregistered) in reply to pitchingchris

    Must be April Fools everyday where I work...

  • dkf (unregistered) in reply to rc_pinchey
    rc_pinchey:
    I'm deleting my bookmark and terminating my RSS feed and drilling my hard-disk and feeding my testicles to a shark. I hope you're happy.
    I'm happy, but then I'm not the shark.
  • AbbydonKrafts (cs)

    You think that's funny, but that's basically how it works at my job.

  • Anonymous (unregistered)

    I gotta say, this would probably beat 90% of the software environments I've worked in.

  • anynomous catward (unregistered)

    feels like what I am doing every day.. shit my workplace is a just joke

  • BlueKnot (cs)

    Ooooh... all this and epiphanies too!

  • akatherder (cs)

    RAD was just a fad. Scrum was just a fad. FAD is the new paradigm.

  • Trevel (unregistered) in reply to BlueKnot

    Finally! A sensible design methodology. The certification will look great next to my Works On My Machine badge.

  • LTD Desktop Support Tech (unregistered)

    Alex, you sir, are a genius. You have given me the ultimate response to every support call and trouble ticket I receive today:

    LEARN TO DEAL!!

    Printer not working........Learn to deal. Application crashing.......Learn to deal. Network down...............Learn to deal.

    Employees displeased with new tech support paradigm....

    LEARN TO DEAL BITCHES!!!! YOU'RE IN MY WORLD NOW!!!!

    MWUAAAAHAHAHA!!!

  • shadowman (cs)
    Alex P.:
    Unlike the stodgy libraries of yesteryear, H/YPE is not a “compiled” library. It’s a set of cross-language codefiles that can be copied to any application, and is designed to “live” with that application for life. Don’t like that 48 plus 92 is not 4892? No problem! Just edit MathHelper.

    And now that I'm thinking about it I know a desktop search tool that would be perfect for this library!

  • Bob (unregistered)

    Sounds great, where can I buy the book?

  • Eric (unregistered)

    FAD isn't new.

    It's clearly is the dominant programming paradigm in the world today.

  • shane (unregistered) in reply to Trevel
    Trevel:
    Finally! A sensible design methodology. The certification will look great next to my Works On My Machine badge.

    And right under that "Test? Well... It compiled without errors." plaque...

  • lowe (cs) in reply to Bob

    No book! Learn to DEAL!

  • DaveAronson (cs)

    Hey Alex! I recently tried to get a job at a FAD-using company, so I could get the experience, so I could take the exam for the cert. But they wouldn't hire me 'cuz I didn't have the cert yet! Will the FAD University of Certificate Keepers and Educational Doctrinaires accept open-source contributions done using FAD?

  • snoofle (cs)

    God, I love this site! Kudos, Alex!

    RAD
    FAD
    SAD
    
    ... the hidden meaning!
    
  • Erik (unregistered)

    Alex,

    I would like to work with you on creating the For Dummies book for this ground-breaking new paradigm. I also think we can schedule several lucrative seminars at various Computer Science programs at Universities all around the country. You are sitting on a gold mine here.

    Personally, I intend to switch our department over to FAD immediately. It will certainly be a big improvement over having that sweaty ape Jenkins hovering over me all the time during our Extreme Programming sessions.

  • Kivi (unregistered)

    The real worse than hailure is that designing the interface first is included in this list. It's actually a pretty good idea: after all, as far as the users are concerned, the interface is the software. The important thing is to base the design on observed user needs and characteristics.

  • Craig (unregistered) in reply to Kivi

    If this is meant to be a parody on Agile as some have suggested, it illustrates that they don't really have any idea of what Agile is about.

    Other than that, good stuff.

  • savar (cs) in reply to JimM
    JimM:
    priceless. And also, scarily familiar from some of the RAD / Agile evangelism that's out there.

    The really scary part is that a person could make a boatload of money selling FAD consulting services, because the central tenet actually is true: clients care about looks, not functionality.

  • elias (cs)

    Looking forward to the Buenos Aires meeting; I already have the tickets and hotel booked!

    Also, for the next site-name change I nominate "The Daily WTF"--for "Worse Than FAD."

  • hc (unregistered) in reply to JimM
    priceless. And also, scarily familiar from some of the RAD / Agile evangelism that's out there.

    You know, I might even learn to be a fan of FAD - it makes a lot of sense! You're coding for the customer, so you do what you can to keep the customer happy. No-one expects software to work properly anymore, so why waste time trying to write software that does work? Write software that looks / acts how the customers expect, than patch functionality later! It makes sense!! BRILLANT!!!

    Yes, it's very similar to agile development...

    No wait, agile actually promotes sound design. It's just you being stupid.

  • Andy Goth (cs)

    Does HYPE.VHelper.HTML have a Blink function? 'Cuz users love blink! Make sure it works across all browsers, emulating it with Javascript, Java, Flash, and even auto-reloading the page every second. You know, whatever it takes.

  • andrewbadera (cs)

    So in other words FAD is TPP? Typical PHP Programmer?

  • Ben (unregistered)

    God, you wish you were funny.

  • Martin (unregistered)

    Actually I think the whole "design user interface first"-concept is a very good idea. The user will be experiencing the work processes in the application and find out whether it matches his or her requirements.

    Obviously you should develop a solid back-end - with a maintainable structure - after the user has confirmed that the application is, indeed, what they need. This is the step where most developers fail.

  • Havok (unregistered) in reply to Eric
    Eric:
    FAD isn't new.

    It's clearly is the dominant programming paradigm in the world today.

    hahah i totally agree.

    Jeez, I entered this job as programmer 1 year ago, and they DO work like this (except for the "deal with it". We fix things)

    However I was good enough to change things and now im working in an OOP style ^^. Thank god I was allowed to apply massive programming changes.

  • Matt J (unregistered)

    Interface first is actually a good idea. The interface is the program for the user, so build the code around it.

  • JimM (unregistered) in reply to hc
    hc:
    priceless. And also, scarily familiar from some of the RAD / Agile evangelism that's out there.

    You know, I might even learn to be a fan of FAD - it makes a lot of sense! You're coding for the customer, so you do what you can to keep the customer happy. No-one expects software to work properly anymore, so why waste time trying to write software that does work? Write software that looks / acts how the customers expect, than patch functionality later! It makes sense!! BRILLANT!!!

    Yes, it's very similar to agile development...

    No wait, agile actually promotes sound design. It's just you being stupid.

    Yes, I wish I was smart enough to post the same comment twice AND mess up the quoting second time around...

    For those who missed the point(TM), I was having a stab at paradigm evangelism in general, not RAD or Agile development in particular (they're just the examples I personally have heard most evangelism of). Agile is (essentially) just another buzz paradigm. Your software is as good as your code, not your development paradigm. If you're a bad coder, you will develop as badly in an agile environment as in a FAD one.

  • JimM (unregistered) in reply to Kivi
    Kivi:
    The real worse than hailure is that designing the interface first is included in this list. It's actually a pretty good idea: after all, as far as the users are concerned, the interface is the software. The important thing is to base the design on observed user needs and characteristics.
    I'm inclined to agree. The most common thing you hear from users is "Why doesn't it do this/that/the other". That's not always a front-end / UI issue, but putting the users at the heart of software development is a much better idea than having a business analyst or project champion try to work things out on their own...
  • Rank Amateur (cs) in reply to Kivi
    Kivi:
    The real worse than hailure is that designing the interface first is included in this list. It's actually a pretty good idea: after all, as far as the users are concerned, the interface is the software. The important thing is to base the design on observed user needs and characteristics.
    I agree. There’s a serious danger that giving a UI to users might trigger meaningful communication on requirements and usability, which can only delay project completion. The only way I can see FAD working is if it also employees Front Ahead Deployments. Developers must ignore everything users say and do. Instead, developers should drown them out with a monologue of great new features coming in the next release. --Rank
  • gutch (cs)

    Actually you're too late Alex - FAD has already been relegated to the museum.

    Grand Theft Auto 3 was designed by whiteboard according to the FAD method. That whiteboard is now exhibited as a historical piece at the Australian Centre for the Moving Image.

    Word is that the industry is looking now for the new FAD.

  • JimM (unregistered)
    hc:
    No wait, agile actually promotes sound design. It's just you being stupid.
    p.s. From Wikipedia's Behaviour Driven Development page
    wikipedia:
    Behavior Driven Development (or BDD) is an Agile software development technique
    and
    wikipedia:
    The first piece of production code that BDD developers implement is the UI.
    No, FAD is nothing like agile development techniques...
  • Porpus (unregistered)

    You all missed the boat on this one. Yes, there are coders who take this kind of "just make it work" approach to extremes. But overcompensation (i.e. over-architecting) is far more common. It's also far more fun to mock the over-architects (who really, really take themselves seriously) than it is to mock the under-architects (who really, really want to get out the door at 5PM and don't care if Rockford Lhotka is impressed).

    I mean, I've got a lot more real successes on my resume than our "architect" here. There's a happy medium to be found and I think Daily WTF as a community is wrong about which way the pendulum needs to swing.

  • Congo (unregistered)

    I'm sorry, but I don't see the humor in this.

  • Anon (unregistered)

    That sounds worryingly familiar.

  • BobB (unregistered)

    Great! They can use my Forward Action Recursive Templates on the backend! (double score)

  • Anonymously Yours (unregistered)

    I love this. The only thing missing is a condemnation of using comments anywhere in the code. All code should be self-documenting, using an ever-shifting, undocumented variable naming system that is inconsistent between developers, projects, and individual sections of code.

    Comments are for kids in college. scoff Don't even get me started on shop standards. They just slow people down when they should be Learning To Deal instead.

  • Tony (unregistered)

    I am sold! where do i sign up?

  • Edward Royce (unregistered)

    Hmmmm.

    Front Ahead Design (FAD) is ok.

    But I'm more comfortable with Never Ahead Design System (NADS).

    The beauty of NADS is that you're never expected to "catch up". You're always going to be behind the curve so it's not a big deal.

    And kick-starting a project in the NADS is something to behold. Preferably from a distance.

  • notme (unregistered)

    You know, the beginning of this actually makes a lot of sense. It had me fooled until about point V of the manifesto.

    Designing the front-end first is actually a pretty nifty idea in many cases. It reminds you of what is actually relevant and keeps you from wasting too much time on isignificant details. It can also keep you from designing your middle-ware/backend in a way that just won't solve the problem, or can solve it but not in a well-performing or sound way, or is just too generic and thus too far detached from the actual problem domain. Not too mention the HCI advantages.

    Point II - well, the real world forces that on you anyway.

    Point III - This is where it starts getting strange to me. There's still some truth to it, though. Many people over-estimate the complexity of their problem. They then throw every design pattern they know of at the problem and end up with a huge bundle of software that only goes to reinforce their earlier believe that they'd need a big and complex design. Had they gone with the down-to-earth no-bullshit approach, they may have ended up with something a tenth of the size. It may have a few WTFs in there, but it's still easier to read, handle and maintain, simply on account of its size.

    OTOH, there's also situations where the problem /is/ /that/ complex, and the simplistic approach just won't cut it. But wisdom is not evangelizing one of these approaches over the other, it's knowing which one you should go with for which problem.

    Point IV - Diagrams and such are a means of communications between developers. Sometimes you can just throw them away after you made your point. Sometimes they accumulate over time and don't get updated ever, forming an enormous mountain of information that makes it really hard to find those rare few gems that are relevant, up-to-date and answer questions that couldn't be as easily answered by looking at the source and/or using common sense.

    Personally, I'm partial to documenting only big picture issues that are unlikely to change any time soon, and otherwise relying on well-structured source code with talking function-/class-/variable names and using comments to document all the "why"s and all the code snippets that aren't obvious at first glance anyway to someone who knows the language well. Also, everything that resembles a communication protocol (even if it's in files) between bigger components of the software absolutely must be documented in detail. Same goes for database layouts and file formats for anything that stores important data.

    The rest of the article is just plain April 1st material. Point VI is - IMO - in direct contradiction with Point II. (If it doesn't work, you have not solved the problem!) Point VII - Recipe for big-time desaster.

    The HYPE framework - a copy-paste library? The mind boggles. I've done the copy-paste thing a number of times in the past (because it was quicker than making a real library) and it's always come back to bite me in the ass. Usually in terms of discovering a bug somewhere and having to go through all the code where I copied the stuff and fix it everywhere individually. It's even worse when it's had individual changes in the other places, because you have to wrap your mind around the old code again, to make sure you don't accidentally break anything with your fix. Not to mention that all the advertised features are either bullcrap or have been solved in a proper way a long time ago.

  • Spectre (cs)

    How deep you fell, copying content from somebody else's blog. Shame, shame.

  • Edward Royce (unregistered) in reply to Porpus
    Porpus:
    ... There's a happy medium to be found and I think Daily WTF as a community is wrong about which way the pendulum needs to swing.

    Hmmmm.

    Are you suggesting that you want our pendulum to swing both ways?

  • Tony (unregistered)

    As the sign above my monitor says...

    "Tell me what you need and I will tell you how to get along with out it" No my quote but who ever said it is the smartest man alive.

Leave a comment on “Front-Ahead Design”

Log In or post as a guest

Replying to comment #:

« Return to Article