Research and Destroy

If you’re not familiar with FAD, then you’ve been missing out. Essentially, FAD is a fundamental paradigm shift over the “traditional” and “neo” ways of building software. Not only does it surpass every other software development methodology out there, it solves every problem there is to building software. And then some.

The FAD Manifesto

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 it’s 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.

VI. Learn To Deal
Many other methodologies focus on delivering “quality” (as in “bug free”) software. And guess what: they fail. Miserably. No matter how hard you try, software will have bugs. In FAD, we just learn to deal with it, and we encourage the client to do the same. So what if the application crashes when you click that button that way? Don’t click the button that way, and learn to deal!

VII. Be Environmentally Conservative
In the real world, there’s only one environment: it’s called The Real World. So why do some methodologies invent these counter-intuitive, bizarro environments called “QA” and “UAT”? Do architecture firms construct an entire house before building an addition on yours, just so they can “test” their building skills? Of course not, and neither should software developers. In FAD, there’s only one software environment: Production. Anything else is pollution.

FAD Application Design

NOTE: First and foremost, understand that the FADAD is merely the preferred method of building applications. Because in FAD, we do what it takes, a lesser or more in depth approach can be used as needed.

Many of the tenets of Front Ahead Design are based on the failings of other methodologies. FADAD is no different, and draws some of its key facets from the archaic Model-View-Controller architecture. In MVC, there are three different components: the Model (the data), the View (the UI), and the Control (everything else).

If you think about it, two of MVC’s components are nothing but dead weight. All anyone – including the client – really cares about when all things are said and done is the View. Therefore, in FADAD, our guiding architecture model is simply called “V”:

The H/YPE Framework: The FAD Developer’s Best Friend

If there’s one thing that’s frustrated just about every developer out there, it’s “untouchable” library code that almost does what you need it to, but not quite. For FAD developers who chose to use the H/YPE framework, this is not a problem.

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. Here’s a small subset of what comes in H/YPE:

• HYPE.StringHelper – all sorts of functions like IsEqual, AreEqual, Add, Subtract, Join, DoubleJoin, Encrypt, and Decrypt
• HYPE.VHelper.HTML – the ultimate HTML library including functions like WrapInCENTER, UnHTML, ToHTML, and ScriptBlock
• HYPE.Audio – everything you’d ever want to add audio, including Beep and BeepMore

But Wait, There’s More: Certification!

No, I don’t mean to sound like our good friend Ron Popeil, but before wrapping things up here, I wanted to tell you about the latest excitement in the world of Front-Ahead Design: certification!

Just last week at the International FAD Conference in Azerbaijan, I joined several other FAD leaders to formally announce the first official Front-Ahead Design certification program: the Fadstronaut certificate. Why Fadstronaut? Because we felt that the astronaut was the best analogy for the challenges and difficulties that FAD software developers face each day.

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!

I hope that gives you all a good idea of what FAD is all about. Believe me, there’s a whole world more of FAD out there. That said, I hope to see some of you soon at the Worldwide FAD Meeting in Buenos Aires next month!

http://thedailywtf.com/Articles/FrontAhead-Design.aspx

Yes, it’s a little late, but so what?

About two weeks I visited a quite interesting talk by Dr. Neil Gafter, developer of Google Calendar, whom, in his spare time, proposes new language features for the Java Programming Language and Sun’s javac-Java compiler. The latest proposes BGGA closures, in conjunction with other nice features like control abstraction, function types and lots of other pretty useful things,is under heavy discussion.

At first I was unsure what to think about closures, lots of people compained about the syntax, and that noone ever will understand the code when here are some function types in it. But, honestly, can it get any more confusing than with generics? NEVER!!. During the talk I recognized the pattern, which clearly is derived from the code blocks I used to love in Smalltalk. Clearly there are some slight differences taking into account that Java is, contrary to Smalltalk, a strongly typed language.

Further than that, it gets really nice when using closures in conjunction with control abstraction: Often used example, which actually doesn’t make sense, as Java5 has a foreach loop built in, but let’s just say someone wants to implement a method like foreach, taking as parameter any type of Collection<T>, as well as a block of code, which itself takes as parameter one item of T. This method then can be imported statically by any class which has need of this particular foreach loop. This abstract functionality is, right now, hard-wired in the java compiler to the Java Collections framework from the runtime environment. *hick* Yes, exactly the way around it should NOT be.

Closures in conjunction with control abstraction have the power to enable APIs to implement their own control statements like, for example, a foreach-loop for Collections or Maps, performance logging, cleanup work, whatever you can imagine. Despite my reservations in the beginning, I can’t wait to see the BGGA proposal into Java7 or Java8. Hopefully we will see it!