Andrew McCollum, aki az alapítása óta részt vett a Facebook fejlesztésében a Techcrunchon foglalta össze, hogy mit is jelent számukra az MFABT (move fast and break things) filozófia.
A gondolat központjában - nem meglepő módon - a sebesség áll fő prioritásként. Amíg azonban sokan egyszerűen arra gondolnak, hogy a gyorsan, kapkodósan végzett munka szükségszerűen hibáktól hemzseg majd, a Facebooknál ennél egy kicsit összetettebben gondolkoznak a kérdésről.
"Olyan dolgokat is össze kell törni, amelyek eredetileg működtek" - írja McCollum, aki szerint erre a legjobb példa a Facebook idővonal és profiloldal gyakori változtatása, hegesztése. Ahhoz, hogy túllépjünk a bevett rutinokon szükséges, hogy megpiszkáljuk azokat a dolgokat is, amelyek egyébként működnek - érvel. Még akkor is, ha ezzel a működő dolgok ideiglenesen összetörnek vagy rosszabbul teljesítenek.
"Lehetetlen teljes körűen tesztelni". A Facebook alapító részletesen leírja, hogy milyen viták voltak a vállalatnál a tesztelés és a QA (minőségellenőrzés) szerepéről, jelentőségéről. Bár természetesen a hagyományos irányzat is képviseltette magát - ami szerint az élesítés előtt mindent teljes körűen tesztelni kell, a felhasználók pedig már csak hibátlan kóddal és funkcionalitással találkozhatnak - a cégnél végül nem ez az attitűd kerekedett felül.
Ez utóbbi állásőpontot egyébként a Facebook későbbi technikai főnöke, Adam D'Angelo képviselte, aki hosszas viták árán győzte meg Mark Zuckerberget, és végül be is bizonyította, hogy ez a helyes mentalitás: a Facebookot végső soron a gyors fejlesztések és a folyamatos innováció emelte ki az "átlagos" közösségi oldalak közül.
Amikor van egymilliárd felhasználód, akkor biztos lehetsz benne, hogy a júzerek minden lehető módon megpróbálják majd használni az egyes, új funkciókat - köztük olyan módokon is, amik soha nem jutottak volna eszedbe. Ezzel persze a kód olyan hibái kerülhetnek elő, amelyekre legmerészebb álmaidban sem gondoltál volna - írja.
A Facebook tehát elengedte azt, hogy görcsösen ragaszkodjon az alapos teszteléshez. A cég adatbázisának mérete miatt úgysem tudnak egyetlen gombnyomással új funkciókat telepíteni, így az "organikusan kifejlődött" telepítési folyamatot használják. Először a vállalat belső hálózatára telepítik az új kódot (ami már önmagában elég sok felhasználót jelent), majd ha ezen a "teszten" átment, akkor fokozatosan mind több felhasználóhoz juttatják el az új funkciókat.
Andrew McCollum szerint a történet az átlagos vagy kisméretű cégek számára is tanulságokat rejt: eszerint minél kevésbé formalizált és bürokratikus egy-egy fejlesztés élesítésének a folyamata, annál több dolog fog eltörni az élesítés után - viszont cserébe annál gyorsabb lehet a fejlesztés tempója.
Ő pedig - a saját példájából kiindulva - úgy gondolja, hogy ez így nem is egy rossz kompromisszum.