Design & Architecture

Re: DNA, XP, SOA, ESB, ETC Are Dead; FAD is the Future

coder — Wed, 01 Jun 2005 10:34:56 GMT

Οι παραπάνω σκέψεις δεν είναι τωρινές .... έχουν συζητηθεί στo OMG.org εδώ και χρόνια (νομίζω απο το 1999) .... ενώ η ΙΒΜ είχε υλοποίησει παρόμοιες τεχνικές απο τα μέσα του 90!

Re: DNA, XP, SOA, ESB, ETC Are Dead; FAD is the Future

cap — Wed, 25 May 2005 20:06:14 GMT

Πωπω, τώρα το είδα! Το είχα διαβάσει πριν από μερικές μέρες και ....γκουπ γκουπ (ηχος κεφαλιού να κανει γκελ στο γραφείο).

Αυτό που περιγράφει ο Alex Papadimoulis είναι πραγματικά, Ελληνική πρακτική. Ετσι φτιάχνουμε το 95% των εφαρμογών μας (οσο και αν θα θέλαμε να υποστηρίξουμε οτι γίνεται διαφορετικά). Παντως, για να είμαι ειλικρινής, παρόλο που ο όρος FAD απο ο,τι καταλαβαίνω είναι ...επινοημένος από τον Alex, σε ΟΡΙΣΜΕΝΕΣ περιπτώσεις σαν ...μεθοδολογία έχει θετικά αποτελέσματα!

Ειδικά σε εκείνες τις περιπτώσεις οπου ο πελάτης δεν καταλαβαίνει προδιαγραφές, ο project manager δεν καταλαβαίνει τις απαιτήσεις του πελάτη, ο προγραμματιστής δεν έχει χρόνο και το αφεντικό θέλει να πάρει λεφτά...χμ...μυρίζομαι τρίτο επεισόδιο του Ζαχαρία....

Re: DNA, XP, SOA, ESB, ETC Are Dead; FAD is the Future

Παναγιώτης Καναβός — Fri, 06 May 2005 19:17:53 GMT

Μπουά Χά Χά Χά !
Ο τύπος είναι φοβερός!

Ένα άλλο όνομα της μεθόδου είναι "Προγραμματισμός αλά Ελληνικά". Προτείνω επίσης το "Souvlaki Programming". Είναι ο τρόπος με τον οποίο η ελληνική αγορά πληροφορικής έχει καταφέρει να είναι η κορυφαία στον κόσμο.
Έχω να το λέω πάντως, το nHype είναι φοβερό εργαλείο!

Στο σοβαρό τώρα, η σχέση του XP με το FAD είναι ότι και η σχέση του Star Wars με μία ιταλική SciFi ταινία. Κρατάς τη βιτρίνα και πετάς όλη την ουσία.

Και πολύ πρώτο!

DNA, XP, SOA, ESB, ETC Are Dead; FAD is the Future

George J. Capnias — Fri, 06 May 2005 01:51:11 GMT

Αυτό το post to βρήκα στο Blog του Alex Papadimoulis. Δεν ξέρω, μου θύμισε πολύ το XP (Extreem Programming) αλλά δεν είναι τόσο αυστηρό... Λες όντως να είναι το μέλλον; Πάντως πιστεύω ότι αξίζει να το έχει στα υπόψην του κάποιος.

DNA, XP, SOA, ESB, ETC Are Dead; FAD is the Future

I've come across a truly revolutionary software development methodology called Front Ahead Design (FAD). Essentially, it's a fundamental paradigm shift over "traditional" and "neo" ways of building software. Not only does it surpass every software development methodology out there, it solves every problem there is to building software (and then some). But don't take my word for it, here are the Top Five fundamentals ...

I. Front Ahead Design
The essence of FAD is conveyed directly in its name: design your front-end/user-interface first, ahead of everything else. The customer could care less what's behind the scenes, so long as it looks good and does what its supposed to. Deliver a working front-end first and then Do What It Takes to fill in the functionality gaps.

II. Do What It Takes
Other methodologies are great at delivering excuses. How many times have you heard (or have been told) "we can't do that here because it could throw off the whole design?" In FAD, you just do it (that would have been the bullet point, but Nike has it trademarked). To get it done, you Do What It Takes. Your customer will love you.

III. Code Light, Not "Right"
A traditional methodology calls a complex framework with layer after layer of objects. In those ways, adding a simple value to a form can be a monumental task, requiring it to be added to every single layer. Does that sound right? Proponents of the other methodologies will tell you it is, but what about your customer? With FAD, you just Do What It Takes to add the functionality to your interface. No more.

IV. "Throw Away" Diagrams
Think of all the Visio diagrams you've drawn over the years. Sequence diagrams, context diagrams, flow charts, and so on. Was that really productive? Did your customer ever see any of those? Were those diagrams even relevant after the system was finally developed? Didn't think so.

In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work. And there is no formal modeling language to battle with: just Do What It Takes to draw and explain your design to other developers.

V. Life Is Short (a.k.a. Patchwork)
The average software system has a life expectancy of seven years. No matter how "properly" the system is designed from the start, within the first year of its life, maintenance programmers unfamiliar with the complex architecture (and having no help from out-of-date documentation) will turn the system into a complete mess with bug fixes and change requests.

In FAD, this isn't even a concern. We know the short life span of a system and develop every feature (from the interface) as a patch. Maintenance programmers can come in and Do What It Takes to add their patches. In FAD, we don't even try to stop the aging process. We encourage it.

There's quite a few more fundamentals, but that's all I've got time for today. I'm incredibly busy trying to finish a book on the topic (halfway through it!!). Hopefully, it'll make it as the first FAD book. I hear some other big names are in the first FAD book race, too.

I also came across some community sites:
  FADblogs.com - .TEXT blogging site, open for anyone to blog about FAD
  FADisIn.com - general informational site with articles, help, discussion, and tools
  ItsAFAD.com - gallery of successful projects (from small business to enterprise) that have successfully used FAD

They're all under construction, but I'm helping a lot with the FADblogs.com, so let me know if you'd like to be one of the FAD bloggers.

Next article: a comparison of the FAD design tools, including H/YPe and nFAD.

Original Link

Today 13:35 | Alex Papadimoulis

George J.