• Fraggle My Rock (unregistered)

    And I for one welcome our new FAD overlords!

  • F (unregistered)

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

    maybe good for small projects, but not for enterprise level applications...

  • Ken B (unregistered) in reply to John
    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 (unregistered) in reply to Anonymously Yours

    Umm.... WPF?

    • SPT
  • Fraggle My Rock (unregistered) in reply to John
    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.

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

    HAPPY APRIL FOOLS DAY!

  • Edward Royce (unregistered) in reply to SomeCoder
    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' (unregistered) in reply to Anonymously Yours

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

    Yeah, this would be funny except this is way too close to reality.

  • (cs)

    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 (unregistered) in reply to Anonymously Yours
    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 (unregistered) in reply to bedrock

    The biggest joke of the day is the absence of the joke-less comic

  • (cs)

    Dude, I'm totally eligible for the Fadstronaut certification exam.

  • Pianohacker (unregistered)

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

    "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 (unregistered) in reply to Anonymously Yours

    I think that this is a very appropriate time to say WTF? with regards to the original article!

  • m (unregistered)

    Does IBM know you're publishing their secret development process?

  • Jay Watson (unregistered) in reply to Anonymously Yours

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

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

    LOL I was almost halfway before it dawned on me to check when the article was written...

  • Estigy (unregistered) in reply to Anonymously Yours

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

    All these years I've been a Fadstronaut and never knew it had a name..

  • Fadstronaut (unregistered)

    First certified Fadstronaut!

    [image]

  • NeoMojo (unregistered)

    Nice try Alex, but you're not fooling me! Methodology indeed! No one can seriously use that word.

  • Stefan (unregistered)

    Great piece of insight! I'll go for certification.

  • Ulrik (unregistered) in reply to Anonymously Yours

    Real programmers don't document, if it was hard to write it should be hard to understand

  • FrAgile (unregistered) in reply to Fraggle My Rock

    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.

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

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

    I'll sign this manifesto. I already have applicable experience in all of these.

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

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

    april 1st eh?

  • (cs) in reply to Fraggle My Rock
    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!

  • (cs) in reply to Stewie

    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 (unregistered) in reply to Anonymously Yours
    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 (unregistered) in reply to Spectre
    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 (unregistered)

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

  • (cs) in reply to pitchingchris

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

    LOL I wonder if Alex was just running out of WTFs and needed more for the site.

    Captcha: gravis. Whoa retro.

  • Travis (unregistered) in reply to Anonymously Yours

    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.

  • (cs) in reply to JimM
    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?

Leave a comment on “Front-Ahead Design”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article