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

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

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

    Section 6 sounds like something straight out of a Microsoft handbook.

  • Fraggle My Rock (unregistered) in reply to real_aardvark
    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 (unregistered) in reply to Anonymously Yours

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

    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 (unregistered) in reply to Anon Y Mouse
    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 (unregistered)

    Humour is difficult.

    http://www.codinghorror.com/blog/archives/001091.html

  • FAD should be a recursive acronym. (unregistered)

    like, fad-aided development

  • Charles (unregistered) in reply to Anonymously Yours

    Good April Fools Day post. I almost fell for it, until I read the post date.

  • code (unregistered)

    rubbish!

  • (cs)

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

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

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

    Finally, I understand how are "some" software made ! WTF ?!

  • Tom (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.

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

    unfortunately this is not new approach at all. I bet most software products were developed using "FAD" :)

  • AniAko (unregistered) in reply to Anonymously Yours

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

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

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

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

    Dilbert is recorded as having said that.

  • zxq9 (unregistered)

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

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

Leave a comment on “Front-Ahead Design”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article