Front-Ahead Design

  • pitchingchris 2008-04-01 10:04
    Ha Ha, everybody would know its April fools day for sure. First ?
  • JimM 2008-04-01 10:08
    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 2008-04-01 10:15
    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 2008-04-01 10:15
    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 2008-04-01 10:18
    The Real WTH is that this still hits close to home. April Fools indeed.
  • phelyan 2008-04-01 10:21
    Yup, far too close for comfort.

    Might send that around on the internal list, actually...
  • your mom 2008-04-01 10:22
    Must be April Fools everyday where I work...
  • dkf 2008-04-01 10:24
    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 2008-04-01 10:26
    You think that's funny, but that's basically how it works at my job.
  • Anonymous 2008-04-01 10:28
    I gotta say, this would probably beat 90% of the software environments I've worked in.
  • anynomous catward 2008-04-01 10:28
    feels like what I am doing every day.. shit my workplace is a just joke
  • BlueKnot 2008-04-01 10:33
    Ooooh... all this and epiphanies too!
  • akatherder 2008-04-01 10:36
    RAD was just a fad. Scrum was just a fad. FAD is the new paradigm.
  • Trevel 2008-04-01 10:36
    Finally! A sensible design methodology. The certification will look great next to my Works On My Machine badge.
  • LTD Desktop Support Tech 2008-04-01 10:38
    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 2008-04-01 10:47
    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 2008-04-01 10:47
    Sounds great, where can I buy the book?
  • Eric 2008-04-01 10:48
    FAD isn't new.

    It's clearly is the dominant programming paradigm in the world today.
  • shane 2008-04-01 10:49
    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 2008-04-01 10:50
    No book!
    Learn to DEAL!
  • DaveAronson 2008-04-01 10:50
    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 2008-04-01 10:53
    God, I love this site! Kudos, Alex!


    RAD
    FAD
    SAD

    ... the hidden meaning!
  • Erik 2008-04-01 10:57
    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 2008-04-01 11:04
    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 2008-04-01 11:09
    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 2008-04-01 11:09
    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 2008-04-01 11:14
    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 2008-04-01 11:16
    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 2008-04-01 11:20
    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 2008-04-01 11:24
    So in other words FAD is TPP? Typical PHP Programmer?
  • Ben 2008-04-01 11:25
    God, you wish you were funny.
  • Martin 2008-04-01 11:30
    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 2008-04-01 11:42
    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 2008-04-01 11:42
    Interface first is actually a good idea. The interface is the program for the user, so build the code around it.
  • JimM 2008-04-01 11:42
    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 2008-04-01 11:47
    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 2008-04-01 11:49
    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 2008-04-01 11:52
    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 2008-04-01 11:54
    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 2008-04-01 11:57
    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 2008-04-01 11:59
    I'm sorry, but I don't see the humor in this.
  • Anon 2008-04-01 12:02
    That sounds worryingly familiar.
  • BobB 2008-04-01 12:07
    Great! They can use my Forward Action Recursive Templates on the backend! (double score)
  • Anonymously Yours 2008-04-01 12:13
    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 2008-04-01 12:16
    I am sold! where do i sign up?
  • Edward Royce 2008-04-01 12:19
    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 2008-04-01 12:19
    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 2008-04-01 12:20
    How deep you fell, copying content from somebody else's blog. Shame, shame.
  • Edward Royce 2008-04-01 12:21
    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 2008-04-01 12:22
    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.
  • LordOfThePigs 2008-04-01 12:28
    Err... Except that would be his own blog...
  • Rank Amateur 2008-04-01 12:30
    “Patchwork” might be misinterpreted. The Manifesto needs another bullet:
    VIII The Past is Past
    Test results, bug reports, change requests, and complaints from the field are only relevant for the previous build. Developers need to focus on the next release. Clients are small-minded, stuck in how things have been, while developers create what will become. Fixing the old can only make it adequate. Greatness comes from making the New. Front Ahead means not looking back.
    --Rank
  • Steve H. 2008-04-01 12:31
    Spectre:
    How deep you fell, copying content from somebody else's blog. Shame, shame.

    I can't tell if you're joking or are dead serious.
  • TakeASeatOverThere 2008-04-01 12:34
    This reads like Joel on Software.
  • Man 987876980 2008-04-01 12:40
    FAD sounds better than XP. At least FAD involves SOME design before you start hacking it as you go along.
  • Da' Man 2008-04-01 12:41
    Sure, my ex-boss was a great proponent of FAD.

    Still, I'm glad hear that he gave up on "this Internet business" and resorted to go back to what he knows (which is Design, incidentally).
  • Man 987876980 2008-04-01 12:41
    Many OSS projects could benefit from a FAD consultant as well.
  • Alin 2008-04-01 12:49
    Edward Royce:
    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.


    Hilarious!
  • morry 2008-04-01 12:49
    Meh. It'll pass. Just like disco, pipe smoking and responsible government, it will fade over time into obscurity. Only to be mentioned in passing by history books and Wikipedia. There's a term for things like that, if only I could think of it...
  • codemoose 2008-04-01 13:02
    Dammit Alex, you barstard. You got me. I got almost to the end before I remembered the date.

    Totally had me going on the Daily WTH thing, too.

    Hats off to you.
  • hc 2008-04-01 13:09
    JimM:
    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).

    I don't get it. So you tell us that "evangelism" is, even when promoting good things?

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

    This is where I don't agree. You see, the presumption of agile is, that you are a good developer, but your productivity and quality of work suffers from miscommunication, excessive bureaucracy, ineffective work with user requirements, ineffective testing, etc. That is generally what bring people to agile.
  • hc 2008-04-01 13:10
    I love not being able to edit my posts.

    The first sentence should read
    So you tell us that "evangelism" is bad, even when promoting good things?
  • The Undroid 2008-04-01 13:16
    Some of it reminds me of the old P.J. Plauger columns "Tomes for our Times": _Algorithms - Data Structures = Assembly Language_, _Programming Art's Computer_, etc.
  • G 2008-04-01 13:18
    Very funny, April 1st and all ... But someone care to explain the Buenos Aires thing? Did not get it 0_o
  • real_aardvark 2008-04-01 13:18
    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.

    You are a sad, sad, sad, homunculus.
    "Sound design?" Definitely not part of the XP prospectus (vide Chrysler et al), and not intrinsic to Agile (whatever the ... help me here, please, Alex, is that Hell, or Heck, or Hhhhhrrrwoorrfgghhtt?)

    What I get from listening to XP, agile, scrum etc proponents is an eery feeling that they don't know what they're doing, but that nonetheless they don't like writing it down, asking questions, or, even worse, using basic communication techniques to explain that it can't be done within the traditional triangle (cheap-fast-correct).

    If you've got 3x5 powerpoint slides to contradict my position, I'd love to see them.

    "Mandatory Fun Day" graphics are good for a start. You can develop them into a Charlie Chaplin film afterwards. Eventually, 3-D color will emerge.
  • Bill 2008-04-01 13:23
    This is hardly a complete description of the FAD phenomenon. You didn't even mention the new Front-Ahead Interface Language, an extremely powerful modeling/prototyping/implementation language, especially when used with the Front-Ahead Scripting Template library. If your project is at Death's door, FAIL/FAST will pull it through!
  • Demaestro 2008-04-01 13:23
    Sounds like a more formal version of "extreme programming methodology" or XP
  • Spectre 2008-04-01 13:24
    hc:
    I love not being able to edit my posts.

    The first sentence should read
    So you tell us that "evangelism" is bad, even when promoting good things?


    Do you disagree?
  • real_aardvark 2008-04-01 13:26
    Ben:
    God, you wish you were funny.
    You obviously haven't read the Book of Job, have you?

    Here's a clue: try being funny yourself. It's not as easy as you'd think. The benefits are babes, drugs, and suicide.

    Well, two out of three ain't bad.
  • dpm 2008-04-01 13:31
    hc:
    I love not being able to edit my posts.

    I love people who are unfamiliar with the concept of "proofreading".
  • Raedwald 2008-04-01 13:35
    What's interesting about some of the WTFs we've seen here is both how doing what it takes and not doing what it takes can contribute to problems. How the clueless have blundered ahead. And how the timid have failed to challenge a dysfunctional status quo.
  • ollo 2008-04-01 13:43
    FAD = First April Day
  • Stewie 2008-04-01 13:55
    Yes... Ha Ha... very original, not only did you do an April fool's joke like all the other websites, you also did two in a row. That's kind of old now. I think the moment passed after the first post.

    Any real articles for the day?
  • ruijoel 2008-04-01 13:57
    Hey! I work like that a lot, but without the whole "light" code thing. If I fail my project, it'll be because I have written a comprehensive framework with several layers of facades, interfaces, factories and implementations just to read some keys from the keyboard.

    Now, on a more serious note, every entreprise uses this methodology with very sound results :

    VBA anyone?

    Ok, calling it software development would be a stretch, but VBA development is so much like FAD. It has it all - copy/paste libraries, one layer of code, light code, just what it takes to do what you want, and all that. Yes, when lambda users do the code, it can get ugly.
  • Yoji 2008-04-01 14:05
    This article makes me so depressed. I live with FAD design every day.

    /cries in the corner.
  • The Truth 2008-04-01 14:07
    ANYONE WHO DOESN'T USE RATIONAL ROSE FOR EVERYTHING IS UNPROFESSIONAL I USED IT EVEN TO WRITE THIS SO EAT MY SHORTS
  • Izzy 2008-04-01 14:14
    I've worked on a software project like that.
  • SomeCoder 2008-04-01 14:18
    real_aardvark:
    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.

    You are a sad, sad, sad, homunculus.
    "Sound design?" Definitely not part of the XP prospectus (vide Chrysler et al), and not intrinsic to Agile (whatever the ... help me here, please, Alex, is that Hell, or Heck, or Hhhhhrrrwoorrfgghhtt?)

    What I get from listening to XP, agile, scrum etc proponents is an eery feeling that they don't know what they're doing, but that nonetheless they don't like writing it down, asking questions, or, even worse, using basic communication techniques to explain that it can't be done within the traditional triangle (cheap-fast-correct).

    If you've got 3x5 powerpoint slides to contradict my position, I'd love to see them.

    "Mandatory Fun Day" graphics are good for a start. You can develop them into a Charlie Chaplin film afterwards. Eventually, 3-D color will emerge.



    This is true. Agile development doesn't care about sound design, or really, design at all. They want it done. Their ideology is to get something working in the iteration. They don't care how, it just needs to be working.

    Not all practitioners of Agile do this. Some do care about design but the real meat and potatoes of Agile is to get something out of the door in this iteration and to hell with everything else.
  • Chris 2008-04-01 14:20
    I think people are confusing "build the interface first" and "design the interface first". Certainly in many situations the interface is a big concern to the client and knowing how the employees will use the software is key. BUILDING the interface before anything else, however, is ridiculous. "Deliver a working front-end first" is what the article said, and that would be quite a feat without a backend!
  • Matt 2008-04-01 14:21
    wonderfull, Alex you're just a genious!!!

    really great, really hecking hilarious!

    for sure the best article i read TODAY :-)
  • iMalc 2008-04-01 14:24
    I love the way the story goes pregressively furthur and furthur downhill!
  • Mrx 2008-04-01 14:29
    I again love people who are wasting their personal time on proofreading.
  • Ken B 2008-04-01 14:36
    The Truth:
    ANYONE WHO DOESN'T USE RATIONAL ROSE FOR EVERYTHING IS UNPROFESSIONAL I USED IT EVEN TO WRITE THIS SO EAT MY SHORTS
    Well, I don't know what the color "rational rose" looks like, but unless it looks very much like black, I think you posted incorrectly.
  • Woohoo 2008-04-01 14:47
    He he.

    Incidentally, in german the word "fad" means dull, bland, uninspired, undistinctive, undynamic ...

    Sounds like the definitive adjective for this great new methodology! ;o)
  • coder 2008-04-01 14:51
    Some good points, but many indications of a lazy developer.
  • Mrx 2008-04-01 14:56
    Porpus:
    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).


    Wise words! Have to copy-paste them somewhere for safe keeping. :)

    Also noticed this ironic side of architecting and oop design. Can't stand hearing people talk endlessly about problems instead of trying to write program that solves them. I for one use C++-statements to "think" and "design" my ideas. It's amaising how much understanding of a problem trial-and-error-prototyping gives.


  • I'm anonymous too 2008-04-01 14:57
    Difficult to tell if that reply is sarcastic or not. Disagree with it regarding comments.

    Code should be self-documenting, but if you've written all code without feeling the need for any comments necessary - congratulations...
  • this webcomic is a wtf 2008-04-01 14:59
    Anonymously Yours:
    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.


    <REAL PROGRAMMER> if it was hard to write, it should be hard to read </REAL PROGRAMMER>
  • Heck 2008-04-01 15:04
    Spectre:
    How deep you fell, copying content from somebody else's blog. Shame, shame.

    That'd be his own blog.

    I guess this is just in case thedailywth was too subtle for anyone. Check your calendars, people!
  • Mel 2008-04-01 15:10
    Alex:
    The customer could care less what’s behind the scenes, so long as it looks good and does what it’s supposed to.

    So, why does the customer care so much about what's behind the scenes? Oh, right, you mean they "couldn't care less". As in, they are at the bottom of their caring ability. As opposed to actually being able to care less.
  • Izzy 2008-04-01 15:17
    I worked on a software project like that for a now defunct computer manufacturer. This was maybe 30 years ago but some mismanagement techniques are timeless. The project integrated--tried to integrate--three different and incompatible database languages: DL/1, DB2, and ADR's DATACOM. There was a huge COBOL vendor purchased inventory system, maintained by an on-site consultant, and lots of local code. It never worked quite right, it crashed at least weekly and we were using it live. Needless to say, the scope of the project morphed like butter on a hot stove.

    Before the software project, some 5 to 10% of our shipments were DOA on arrival. The sales department was playing fast and loose with SEC regulations (yeah, the government) by not closing out a month's shipments until maybe the 15th of the next month. The software was supposed to FIX our management problems by giving us better control over the process. The software purchase must have been a board level decision, since every department directly involved in manufacturing fought tooth and nail to hold on to their way of doing things.

    Key people, like senior database folk, bailed out and I got assigned to "pick up the slack." One day I'd just had too much of it, so I walked out back, jumped off the loading dock and went home. Oh, I had to call in sick for a while and negotiate a termination, but I was done with that job.

    Please tell me when the next Fadstronaut certification exam is being held.
  • ping floyd 2008-04-01 15:18
    All I have to say is that the diagram embedded in the article goes against your paradigm. I think you should have drawn it on a napkin and took a picture on a wooden table.
  • HK-47 2008-04-01 15:23
    The name is lacking something. It needs more letters, of course. A positive affirmation is added.
    FYAD: Front (YES!) Ahead Design
    Now we're getting somewhere. How about:
    FYADIAF: FYAD In All Functions
  • hc 2008-04-01 15:29
    real_aardvark:
    You are a sad, sad, sad, homunculus.
    "Sound design?" Definitely not part of the XP prospectus (vide Chrysler et al), and not intrinsic to Agile (whatever the ... help me here, please, Alex, is that Hell, or Heck, or Hhhhhrrrwoorrfgghhtt?)

    Please, just do some research. For example Agile manifesto states that continuous attention to technical excellence and good design enhances agility.

    SomeCoder:
    This is true. Agile development doesn't care about sound design, or really, design at all. They want it done. Their ideology is to get something working in the iteration. They don't care how, it just needs to be working.

    Not all practitioners of Agile do this. Some do care about design but the real meat and potatoes of Agile is to get something out of the door in this iteration and to hell with everything else.

    You are right that delivering is the one and only goal - as with any other methodology. Things like proper design, coding style, testing, etc. are just means to an end. Implying that agile means no design and free-for-all hacking of code is of course wrong. The stated goal of agile is to deliver at fast and constant pace. You cannot deliver software at constant pace without proper design and architecture.
  • ParkinT 2008-04-01 15:34
    ...and you’ve earned the designation Certified Fadstronaut!

    Looks, to me, like another sticker give-away opportunity!

    This all makes good sense! I nearly soiled my Leisure Suit from the excitement generated while I read this!
  • fersis 2008-04-01 15:41
    yeah, i live on Buenos Aires! so i can go to the FAD meeting!

    oh ,and we need more lol catz.
    (Maybe the official banner of FAD could be a lol cat, like 'can i haz teh FAD?')

    cheers and thanks for the april 1 fun.
    It made me smile.
  • JimM 2008-04-01 15:42
    LoadsOfPeople:
    hc:
    blah blah blah...
    You're just wrong
    Awww, look. I got my very own troll, and now everyone else is jumping on them ;^( Please guys, don't feed the troll.
    p.s. Yes, evangelism is bad, regardless of what you are promoting. But when what you are claiming is plain wrong (i.e. agile design means you always get a good software product), it's worse...
  • JimM 2008-04-01 15:54
    hc:
    JimM:
    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.

    This is where I don't agree.

    You don't agree that a bad programmer will always write bad code? Someone should've told Paula Bean's employers...
  • v.dog 2008-04-01 16:00
    I've loved FAD every since we implemented it at my workplace, everything is so much easier.

    There's just one caveat; it is becoming a constant struggle to get the boss to stop seeing my forearms as disposable.
  • code pioneer 2008-04-01 16:01
    I LOVE PHP TOO
  • Fraggle My Rock 2008-04-01 16:11
    And I for one welcome our new FAD overlords!
  • F 2008-04-01 16:19
    The BIGEST WTFs I've ever seen come from US, no Buenos Aires. So sad to bring prejudice to simple jokes that could very well be without. Shame on you.
  • John 2008-04-01 16:30
    In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work.


    Um excuse me, but my forearms are not disposable.
  • bedrock 2008-04-01 16:32
    maybe good for small projects, but not for enterprise level applications...
  • Ken B 2008-04-01 16:38
    John:
    In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work.
    Um excuse me, but my forearms are not disposable.
    Perhaps not the entire forearm, but certainly the top few layers of skin can be disposed of every few hours.
  • StupidPeopleTrick 2008-04-01 16:44
    Umm.... WPF?

    - SPT
  • Fraggle My Rock 2008-04-01 16:57
    John:
    In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work.


    Um excuse me, but my forearms are not disposable.


    Nonsense. They grow back after a couple of hours.
  • vt_mruhlin 2008-04-01 17:05
    Anonymously Yours:
    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.


    I thought the "no comments" part was implicit from the fact that we only care what the user sees. Open Source might currently be FAD compatible, but once the next iteration of Microsoft FAD comes out, you'll never have to worry about comments again.

    /I totally can't wait to get my MBA (Meeting in Buenos Aires" diploma for simply attending!
  • bedrock 2008-04-01 17:07
    HAPPY APRIL FOOLS DAY!
  • Edward Royce 2008-04-01 17:12
    SomeCoder:
    ...
    This is true. Agile development doesn't care about sound design, or really, design at all. They want it done. Their ideology is to get something working in the iteration. They don't care how, it just needs to be working.
    ...


    Hmmmm.

    I always thought the purpose behind Agile development was the lethal combination of short software lifecycles and the high rate of developer turnover.

    I.e. code something now because it'll be worthless in 3 years and WTH, you'll be in another job in a couple years anyways.
  • Dismayed with software 'development' 2008-04-01 17:28
    I like this FAD. And it is just that, a fad, soon to add an e and fade.

    If one designs an application to last for 5-7 years (thank you Detroit for that), then the same application will have to be written from the ground up every 5-7 years. Do you really want to solve the same problems in 5-7 years?

    What this really shows is that the original spec (oops, 4 letter word) was incomplete and did not describe the entire system with enough detail.

    What one would expect from a UI with such methods is a nice blank page. All else will be provided with bugs. IE. "I don't see a page title". "The page title is wrong". "We need to change the page title". "Add a login section". "The password needs to accept input". "Change the page title". "Move the login to the left side". Soon what would have been a nice spec document is scattered all over the place. Is it a bug now if the next 'fix' moves the login back to the right side of the page?
  • Dismayed with software 'development' 2008-04-01 17:29
    Yeah, this would be funny except this is way too close to reality.
  • ammoQ 2008-04-01 17:30
    Ironically, companies (roughly) doing FAD (we all know they already exist) have a strong tendency to survive. I've experienced that several times throughout my career. FAD companies deliver "results" quickly, which makes the customer happy (at least in the beginning) and gets the developers some money. They don't invest in expensive tools, test environments etc. If something doesn't work - which inevitably regulary happens - they get more money for so-called change requests and maintenance contracts. And since there is no proper design to defend, no change request is impossible to implement. It requires an ugly patch - so do it. The windows are already broken, who cares. If the system becomes completely unmaintable after a few years, the customers just give them more money to make a new, "better" system.

    On the other hand, companies trying to "do it right" take a long time till they delivery anything at all that a customer understands. They annoy the customer by asking him to proof-read specifications etc. that are either boring or incomprehensible or both. During that relatively long design/implementation phase, the whole project is very vulnerable to be cancelled completely. Especially if the customers are used to the FAD-like quick shots. When they finally deliver, the system works mostly correctly according to the specs, but the customer is not very satisfied because the requirements have changed and/or were not completely incorporated in the specification. Because the system is multi-layered and a rigorous QA is in place, changes are difficult, expensive and take a lot of time. The launch is further delayed and the project is still very vulnerable. Then, with some luck and patience, the system really goes into production and, besides some inevitable performance problems and interface hickups, works.
    Maintenance contracts are mandatory, though the customer is never sure what he pays for because the system seems to work without maintenance. Since the system was so expensive in the first place, it is used for many years. At the end, it's just expensive (maintenance) and completely outdate, UI-wise. A salesperson from a FAD company is about to acquire the replacement project for his company, and the "do it right" company can either cut prices (therefore losing profit and/or quality of work) or downsize.
  • Smidgens the Underpaid 2008-04-01 17:42
    Anonymously Yours:
    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.


    Funny you should say that. I always preached for good commenting. My co-workers always said "code should be self-documenting" and then they opened up 1-year old code after one person left and asked "Wait what does this entire giant component do and why does it do it?" took a while to answer.

    Variable naming we never had a problem with. If you name a variable in such a way that the reader has no idea how you came up with it, you are actually taken out back and beaten with a stick until you figured out why you were beaten with a stick.
  • mister 2008-04-01 18:06
    The biggest joke of the day is the absence of the joke-less comic
  • Ametheus 2008-04-01 18:59
    Dude, I'm totally eligible for the Fadstronaut certification exam.
  • Pianohacker 2008-04-01 19:05
    There was one really terrifying moment while reading this article this morning (before I woke up and noticed the date) where I thought you were actually serious. Don't do that to me, man.

    Other than that, this was really funny. "Learn to Deal" reminds me of the "Works on MY machine" badges.
  • Ajk 2008-04-01 19:45
    JimM:
    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...


    Well there is a difference from doing a prototype so that the users can play around with an interface than to actually use the prototype to determine the server side architecture.
  • dkf 2008-04-01 20:41
    Ajk:
    Well there is a difference from doing a prototype so that the users can play around with an interface than to actually use the prototype to determine the server side architecture.
    Are you sure about that? That flies flat in the face of YAGNI...
  • NB 2008-04-01 21:11
    "Becoming a Certified Fadstronaut is easy, but not too easy. All you need is one year (1,000 hours) of verifiable FAD development experience, and you’ll be eligible to sit for the Fadstronaut certification exam. Score in the 50th percentile, and you’ve earned the designation Certified Fadstronaut!"

    HEY! I want the Fadstronaut Certificate BEFORE I take the exam DAMMIT!

  • Jay Watson 2008-04-01 22:00
    I think that this is a very appropriate time to say WTF? with regards to the original article!
  • m 2008-04-01 23:11
    Does IBM know you're publishing their secret development process?
  • Jay Watson 2008-04-01 23:40
    I'm glad they don't design and build airliners with this "don't give a ***k what it looks like on the inside" school of thought.

    "All four engines have stopped turning, the cabin's de-pressurising and the coffee machines have run dry Captain"

    "Learn to deal you mo-fo...That's why they made you my first officer!!"
  • FrAgile 2008-04-02 00:52
    I've lived through eras of what was essentially FAD, followed by RUP, then Agile. To be honest, the first methodology (at least in my company) has been just as effective as the other two, and orders of magnitude cheaper and faster.

    You might think that quality would increase as more rigorous development paradigms (and rigorous developers) were introduced, but it doesn't seem to have much impact in real life. You might think that my organization has not been implementing new development methodologies effectively, but we are seen in the wider world as a textbook case of sound Agile development.

    I honestly don't care about the architecture of your application, as long as it more or less does what I asked for, and arrives in a couple of months of when I expected it. Good documentation and a sound MVC architecture are not things I am willing to pay for, as they don't provide me with any benefit. You'll just take longer to make any changes, even if the changes themselves are less risky. Things will change in 3 or 4 years, so I'd expect to rebuild the app, no matter what, which is why my accounting schedule will amortize it over this period.

    The "iron triangle" mantra of "choose any two of faster-cheaper-better" is a nonsense -- choose umm, zero. New development methodologies have only managed to implement slower-spendier-mediocre-er.
  • Sahi 2008-04-02 02:43
    *LOL* I was almost halfway before it dawned on me to check when the article was written...
  • Estigy 2008-04-02 02:51
    Hm, if this is what the site name change brought us, I'm not too happy about it. Very much text, only funny towards the end. All up to point "The FAD manifesto - section V." I was not sure if this was to be meant seriously or if I was just missing some joke...
  • Fraggle My Rock 2008-04-02 03:55
    FrAgile:
    Good documentation and a sound MVC architecture are not things I am willing to pay for, as they don't provide me with any benefit. You'll just take longer to make any changes, even if the changes themselves are less risky. Things will change in 3 or 4 years, so I'd expect to rebuild the app, no matter what, which is why my accounting schedule will amortize it over this period.


    You're missing the point of good design. If you use MVC or any architectural plan for that matter, you won't have to rebuild the app in 3 to 4 years, you'll only have to update small parts of it at a minimal cost.
  • Quango 2008-04-02 04:06
    All these years I've been a Fadstronaut and never knew it had a name..
  • Fadstronaut 2008-04-02 04:28
    First certified Fadstronaut!

  • NeoMojo 2008-04-02 05:15
    Nice try Alex, but you're not fooling me! Methodology indeed! No one can seriously use that word.
  • Stefan 2008-04-02 05:24
    Great piece of insight! I'll go for certification.
  • Ulrik 2008-04-02 06:16
    Real programmers don't document, if it was hard to
    write it should be hard to understand
  • FrAgile 2008-04-02 07:41
    But I don't want to update small parts of the application. My requirements will have changed sufficiently that the current app will need large changes.

    And anyway, whatever technology was originally used will no longer be fashionable, so that the development team will tell me that it needs to be completely rebuilt from the ground up.
  • JimM 2008-04-02 07:51
    FrAgile:
    But I don't want to update small parts of the application. My requirements will have changed sufficiently that the current app will need large changes.
    Theoretically, the changes should have occurred over the years - the software should've kept up with current requirements sufficiently that only small changes are needed. If your requirements change so dramatically, in such a short space of time, that your current software needs a complete rewrite, then what you're actually saying is that you need a new piece of software...
    FrAgile:
    And anyway, whatever technology was originally used will no longer be fashionable, so that the development team will tell me that it needs to be completely rebuilt from the ground up.
    This is more likely to be your problem. You will have had turn over of staff in the intervening period, and there's a good chance that for new projects the company will have adopted a different technology, bringing in developers with a different skillset. I'd guess that the vast majority of complete rewrites are actually unnecessary, and come about simply because the software provider doesn't have sufficient expertise in their old tecchnologiesany more...
  • KenW 2008-04-02 09:06
    AbbydonKrafts:
    You think that's funny, but that's basically how it works at my job.


    I think Alex brainstormed with my boss before this was written. I fee physically ill every time I have to work on his source code.
  • Anon Y Mouse 2008-04-02 09:13
    I love it! FAD and H/YPE-ish libraries are in use in a couple of Day Labor Staffing companies headquartered in the Northwest that I've had the joy of fighting with in recent years. You really can't enjoy the concept until you've had first-hand experience with it. FAD has been in existence for a very long time, and since 1997, it has been my job to come in to organizations using this approach and convert them from FAD to a more "MODern" approach. Oh! Don't worry. They never actually let you convert anything – it's just a hiring gimmick. No, FAD will often live on and on within any location who has ever been adopted it.

    The two companies I mentioned above, bring out another aspect of FAD which I just can't wait to tell you about, called FATS -- Full Ahead with Terminal Services. The FAD applications, often fat-clients, get so large and disjointed that the only way you can get them to continue running, is to execute the FAD framework via Terminal Services. It's named "Terminal" Services for a reason. The applications are terminally ill, and the use of Terminal Services can keep them alive longer, much like the use of ventilators and pace makers keep the developers breathing after total burn-out.

    For those of you that aren't aware, there is QA and QA2 (squared). Most companies using FAD are using the more advanced form, QA2, which stands for Quality Assurance through Question and Answer. This saves them loads of time and money by foregoing the $100K of project documentation and supplying 5 or more Helpdesk folks with phone lines, computers, medical benefits and stock offerings they don't intend to support or pay out on. You have a problem? Just call! It's that simple. Your answers are no more than a phone call away. Just please don't get upset with them if the answers are in a foreign language or seem to be totally wrong. They are never wrong! The Helpdesk person is answering the question you really meant to ask, because the question you actually asked, had no bearing on what they believe you problem to truly consist of.

    Bringing FATS and QA2 together, you realize the need for STOP-THE-BS. This is a term that relates to how an organization using FAD responds to slow response times. It stands for "Slow Terminals, Operating Poorly-Terminate Helpful Employees-Buy Servers". Whenever a sufficient number of calls come in which indicate that branch offices can no longer do business due to slow system responses and/or timeouts, STOP-THE-BS dictates that you terminate those employees which are helpful in getting the job done, and use the money from the payroll savings to purchase additional servers. Last year's powerhouse server no longer working out for you? No problem, buy this year's top model, perform a bit more FAD-style efforts to integrate it, and then let out a yelp of “IT'S ALIVE!!!” as the performance appears to improve. After all, bigger is better -- including server nurseries. I'd call it a server farm if they were all planted in the same soil, but often these servers are like trees planted in baskets and fed/watered whenever the leaves begin to fall off.

    If you are an investor in such a company, then you need to attend the seminars as well. By doing so, you will understand when those promised returns are diverted to life-support instead. Smile, because your money is still in use and greatly appreciated. The company trips to Las Vegas should make that quite evident.

    The same applies to auditors of such companies. Auditors must realize that FAD systems are much more advanced and secure than other systems in use today. If you need information, you will have to communicate those needs directly to the software developers who have full access to the system databases. (That's often any developer on the premises.) Give them an indication of the numbers you are looking for, and they will massage the data to produce the intended results. Be patient, because your requests will take time, due to the fact that no time exists in their busy schedule to help you. In order to get you your answers, the developers will have to determine which values were rounded using the 5-rule, or the more profitable floor/ceiling-rule. Finally, they will need to pass these values through the proprietary formulas used to determine profit margins, losses, and fees, because the industry standard formulas resulted in numbers which freak out the administration.

    There's just SO MUCH to the FAD approach, that we cannot tell you all about it in a couple of posts. You really should attend the conferences and seminars to learn more!
  • James Peckham 2008-04-02 09:24
    I'll sign this manifesto. I already have applicable experience in all of these.
  • KenW 2008-04-02 09:29
    Estigy:
    Hm, if this is what the site name change brought us, I'm not too happy about it. Very much text, only funny towards the end. All up to point "The FAD manifesto - section V." I was not sure if this was to be meant seriously or if I was just missing some joke...


    You're missing the joke. Perhaps this site is too complex for you.
  • Chris 2008-04-02 09:38
    Is it a sad thing that one of my Computer Science & Engineering professors is basically teaching us part I of FAD? The good news is that nobody I know in the class believes him for a minute.

    And where I currently work we use V and VII on a daily basis for everything from our web site to system administration scripts (granted, we try it on one machine first then push it out to them all if it works) to the actual OS image (currently Solaris 10, upgraded, patched, and hacked to make/keep working since Solaris 8, and similar with the Windows image)?
  • bob 2008-04-02 09:56
    april 1st eh?
  • DaveK 2008-04-02 09:58
    Fraggle My Rock:
    John:
    In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work.


    Um excuse me, but my forearms are not disposable.


    Nonsense. They grow back after a couple of hours.


    You bet they do! I'm typing this with mine cut off right now!
  • DaveK 2008-04-02 10:06
    You know, try how I might, I just can't imagine this guy ever opening a sentence with the words "I enjoy a joke as much as the next man ...", not even if followed by a "but".
    Stewie:
    Yes... Ha Ha... very original, not only did you do an April fool's joke like all the other websites, you also did two in a row.
    Yes, for goodness' sake, when will the madness end? Two jokes? In one day? Surely one joke should be enough for the entire human race for all time?
    Stewie:
    That's kind of old now. I think the moment passed after the first post.
    I guess you don't understand how April Fools' Day works then. The moment passes at twelve noon. Not a minute sooner.
    Stewie:
    Any real articles for the day?
    If you really don't enjoy the human tradition known as "humour", you are entirely free to leave the planet along with the rest of your cold emotionless cyborg buddies. The rest of us quite like it.
  • Porpus 2008-04-02 10:34
    Anonymously Yours:
    I love this. The only thing missing is a condemnation of using comments anywhere in the code.


    I don't always like comments. I can't think of any other line in a program that can be completely incorrect and yet never (directly) trigger an error. For example:

    //Assign square root of 25 to A
    int A=4;

    The comment is not at all helpful. I really think the kind of people who type a bunch of superfluous comments don't care about finishing anything or having a life. They are too in love with programming for its own sake (i.e. typing in a dark room with the door closed) and they have no appreciation for brevity or simplicity.
  • FAD follower 2008-04-02 11:25
    Spectre:
    How deep you fell, copying content from somebody else's blog. Shame, shame.


    Yeah... Alex Papadimoulis should definitely be ashamed that he copied this content
    from Alex Papadimoulis's Blog

  • Bean 2008-04-02 11:44
    While it is true that FAD can save a lot of time during development especially because you don't have as much code to write. But I've found that using self modifying code is even more efficient. Now most of my code writes itself.
  • Fraggle My Rock 2008-04-02 15:31
    FrAgile:
    And anyway, whatever technology was originally used will no longer be fashionable, ...


    Yeah right. Tell that to the 2008 COBOL programmers who are *still* working on code from the 1970's.
  • ZippoLag 2008-04-02 17:35
    whoa, FAD sounds awesome, plus Bs.As. is kinda close to me (what's 1kkm anyway?) so I'll gladly go and meet all the people that like coding and working just like me.

    btw: it's april 2nd now, so yeah, I really meant that,.-
  • max 2008-04-02 17:45
    LOL I wonder if Alex was just running out of WTFs and needed more for the site.

    Captcha: gravis. Whoa retro.
  • Travis 2008-04-02 17:57
    Dude, this is awesome. My workplace has been doing FAD development for years. I could probably take the FAD cert. and pass it with flying colors. In fact I know all the "great" benefits of FAD and so does our management. Actually, management requires FAD development do to their vast software development skills and knowledge. Only those well versed in FAD development gets promoted to management therefore FAD will live forever.

    Oh and the code comments thing by "Anonymously Yours", we got that covered. For example: JCLs are not allowed to be commented because of the amount of space comments take up on the file system. Now that's FAD in action.

    I cannot wait to tell the guys that our development practices are well known and certifiable.
  • real_aardvark 2008-04-02 18:44
    JimM:
    FrAgile:
    But I don't want to update small parts of the application. My requirements will have changed sufficiently that the current app will need large changes.
    Theoretically, the changes should have occurred over the years - the software should've kept up with current requirements sufficiently that only small changes are needed. If your requirements change so dramatically, in such a short space of time, that your current software needs a complete rewrite, then what you're actually saying is that you need a new piece of software...
    FrAgile:
    And anyway, whatever technology was originally used will no longer be fashionable, so that the development team will tell me that it needs to be completely rebuilt from the ground up.
    This is more likely to be your problem. You will have had turn over of staff in the intervening period, and there's a good chance that for new projects the company will have adopted a different technology, bringing in developers with a different skillset. I'd guess that the vast majority of complete rewrites are actually unnecessary, and come about simply because the software provider doesn't have sufficient expertise in their old tecchnologies any more...

    You sorta missed out:
    FrAgile:
    Good documentation and a sound MVC architecture are not things I am willing to pay for.

    Perhaps some kind soul would stump up two bits to FrAgile for doing it right and a cup o Joe. Perhaps he's never had to make a budgetary decision beyond, oh, I dunno, under-tipping a cute waitress or over-tipping the crank-head outside the bar who's "looking after" his car.

    How much FrAgile be prepared to pay for BAD documentation?

    Exactly how cretinous do you have to be until you're banished from the industry because you've failed the Dope test?
  • real_aardvark 2008-04-02 18:50
    Ajk:
    JimM:
    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...


    Well there is a difference from doing a prototype so that the users can play around with an interface than to actually use the prototype to determine the server side architecture.
    Wisest comment so far. Even the concept of doing this reverses my upper and lower intestines.

    I'd recommend prototyping the front-end in something totally useless, like VB4, but I can already see where this would go wrong.
  • Hamstray 2008-04-02 19:00
    FAD is pretty lame, it actually expects you to implement stuff yourself. Why do that when chances are high that someone has already implemented just what you need? Simply rip all the parts from somewhere else and stitch them together into an abomination, that's how it's done right.
  • JB 2008-04-02 19:29
    The project I am working on is seeing its first of many planned massive extensions and new standards, conventions, etc are flying around as we try to get these processes down correctly in advance.

    So I thought it would be great to plug your article to my team in the most glowing language possible (by e-mail; I'm not that good of an actor) I've heard some of my coworkers were starting to worry about my sanity till they were reminded of the date.

    Sadly, I wasn't the least bit surprised when a more senior programmer noted that only a few years ago this WAS the conventional wisdom. He said he had proof but I'd say the proof is pretty much everywhere.
  • Peter 2008-04-02 19:49
    Section 6 sounds like something straight out of a Microsoft handbook.
  • Fraggle My Rock 2008-04-02 22:46
    real_aardvark:

    You sorta missed out:
    FrAgile:
    Good documentation and a sound MVC architecture are not things I am willing to pay for.

    Perhaps some kind soul would stump up two bits to FrAgile for doing it right and a cup o Joe. Perhaps he's never had to make a budgetary decision beyond, oh, I dunno, under-tipping a cute waitress or over-tipping the crank-head outside the bar who's "looking after" his car.

    How much FrAgile be prepared to pay for BAD documentation?

    Exactly how cretinous do you have to be until you're banished from the industry because you've failed the Dope test?


    I don't think anyone could have stated this more clearly. I'd imagine that he's not paying for it and that's why he's having to perform rewrites every 3 to 4 years (assuming he's getting called back to perform said rewrites).

    Problem is, in our line of work there is no dope test (not like those structural engineers). But then again, that's what makes this industry like selling hot dogs downtown: anyone can do it, all you have to do is make it look good and serve it up faster than the next guy.
  • Billy Jean 2008-04-03 02:53
    Wow! So what you're saying is that if I need to addd something to a form I just do it and fix the code to work with the change... like I would have to do in any other method of development until they develoop that self coding language where I would be able to just stare at my screen in a Chuck Norris kinda way and the code magically appears.

    The eyes of a ranger are upon you...

    WTF indeed.
  • Billy Jean 2008-04-03 03:04
    Actually now that I tihnk about it; if I were Chuck norris, there wouldn't be code at all. I'd just stare at the interface and it would work.

    Chuck is Jedi
  • Kuba 2008-04-03 23:56
    Anon Y Mouse:
    I love it! FAD and H/YPE-ish libraries are in use in a couple of Day Labor Staffing companies headquartered in the Northwest that I've had the joy of fighting with in recent years. You really can't enjoy the concept until you've had first-hand experience with it. FAD has been in existence for a very long time, and since 1997, it has been my job to come in to organizations using this approach and convert them from FAD to a more "MODern" approach. Oh! Don't worry. They never actually let you convert anything – it's just a hiring gimmick. No, FAD will often live on and on within any location who has ever been adopted it.
    ....
    Bringing FATS and QA2 together, you realize the need for STOP-THE-BS. This is a term that relates to how an organization using FAD responds to slow response times. It stands for "Slow Terminals, Operating Poorly-Terminate Helpful Employees-Buy Servers".
    ...
    If you are an investor in such a company, then you need to attend the seminars as well. By doing so, you will understand when those promised returns are diverted to life-support instead. Smile, because your money is still in use and greatly appreciated. The company trips to Las Vegas should make that quite evident.


    This is otherwise known as boiling the frog. Anyone sane enough, who comes from outside such an organization, will yell WTF?! and either turn away in disgust, or demand sweeping changes from the middle management all the way down.

    The biggest deal is that most such "enterprise" infrastructure is overbloated and really under-performing. When most developer time is spent resuscitating and fire-quashing, it's time to seriously rethink the strategy.

    I'm pretty sure that the systems those companies use, if someone external came in and did a reverse-engineer to produce documentation (requirements, workflows and so on), it'd be relatively trivial to re-implement existing systems on <10% of the server resources, and using "outdated" Windows 98 machines for clients (read: PII, 64MB RAM). Heck, the replacement system's codebase would probably be about 10% of the size of the abomination it had replaced, too.

    I mean, come on, e.g. Qt is a contemporary framework and transparently supports 98/ME way more than any typical business app will ever need. I have seen a small shipping medical app Qt which works just fine on clean win 98 machines with 64 megs of ram (clean as in no OEM crap installed, just whatever came with Windows itself + updates). It acquires data from the hardware in real time over USB, too.
  • Ulrik 2008-04-04 03:03
    Humour is difficult.

    http://www.codinghorror.com/blog/archives/001091.html
  • FAD should be a recursive acronym. 2008-04-04 07:09
    like, fad-aided development
  • Charles 2008-04-04 11:42
    Good April Fools Day post. I almost fell for it, until I read the post date.
  • code 2008-04-05 14:10
    rubbish!
  • rdrunner 2008-04-07 06:08
    That is a very sound model you posted there...

    But you can also apply it to existing system. All you need to do is to apply some very basic refucturings and you are set.

    FAD requiers every developer to understand and apply most of the basic refuctorings. So you can even tak an existing project and turn it into a FAD project.

    Here is a small ppt that explains the basics of refuctoring to those who dont whave the skill yet...

    http://www.waterfall2006.com/Refuctoring.pdf
  • Peufeu 2008-04-14 06:06
    Actually, designing the user interface first makes sense (only if the program is intended to have users, of course). But you might want to make a feature list first (on a napkin, obviously, remember Longhorn ?).

    I always sit with the users and watch them using their current application, taking notes.

    And if your framework needs you to edit more than 1 file to add a table column and generate all the associated forms, you need another framework.
  • Arturo Tena 2008-04-16 19:23
    Self-document code? Why bothering with something the client WILL NOT SEE. If it is not in the view, it does not matter, right? Just use great variable names as: a, then use b, then c... after z, you can use aa and so.
  • Nicolas 2008-04-18 11:15
    Finally, I understand how are "some" software made !
    WTF ?!
  • Tom 2009-01-20 12:28
    Anonymously Yours:
    I love this. The only thing missing is a condemnation of using comments anywhere in the code.


    You joke, but I actually worked at a shop that said this. "Code should be self-documenting". They didn't even write comments describing API fuctions... you had to guess what the function did based on the function body... and God forbid you didn't know what function you needed. We didn't have an API reference. (Well, we had one, but it hadn't been updated in a decade.)

    In response to that, my new rule is that I never write a program that's not documented thoroughly in the source - ESPECIALLY input values.
  • FADer 2009-01-20 13:10
    unfortunately this is not new approach at all. I bet most software products were developed using "FAD" :)
  • AniAko 2009-01-21 12:05
    Without knowing it, my company has been doing FAD designing for some time now! It's natural, like rain cycles, the gulf stream, erosion, and entropy
  • Anon Coward 2009-01-22 04:37
    Oh is that what you call it, at my company the sales department that has been put in charge of managing us programmers is calling it Agile.
  • Thrillhouse 2009-01-22 13:48
    Wow. This is the bible from which all our code was wrought. There must have been FAD seminars given for free right up to the point I started working here. Amazing!
  • Rage 2009-02-23 21:46
    Im thinking of applying the same methodology to an upcoming project. My problem is, the support overhead ti would require just to train another programmer to learn the code, the learning curve.

  • Audra 2009-06-19 09:43
    Dilbert is recorded as having said that.
  • zxq9 2013-10-14 08:01
    A bit from Lewis Carrol's "Hunting of the Snark" seems to be called to mind with increasing frequency as the years pass and I join different development efforts...

    ###
    He had bought a large map representing the sea,
    Without the least vestige of land:
    And the crew were much pleased when they found it to be
    A map they could all understand.

    "What's the good of Mercator's North Poles and Equators,
    Tropics, Zones, and Meridian Lines?"
    So the Bellman would cry: and the crew would reply
    "They are merely conventional signs!

    "Other maps are such shapes, with their islands and capes!
    But we've got our brave Captain to thank:"
    (So the crew would protest) "that he's bought us the best --
    A perfect and absolute blank!"
    ###

    A sad testament that this is becoming more, and not less, relevant in today's IT market, despite the budget drop. You'd think we'd spend more of the time we have available learning from the past instead of reinventing it.
  • Peter Wolff 2013-12-14 16:04
    zxq9:
    You'd think we'd spend more of the time we have available learning from the past instead of reinventing it.

    Is there anything more we can learn from the past than that humankind never learns from the past?
  • Peter Wolff 2013-12-14 16:05
    And I'm glad that FAD actively encourages sound design:
    "• HYPE.Audio – everything you’d ever want to add audio, including Beep and BeepMore"
    See also The Wikipedia article on sound design

    (Sorry for the double post - both comments in a row were rejected as spam.)