Software Factories a reverse engineering

Ten snobistycznie brzmiący tytuł dobrze podsumowuje problem, który poruszony został na ostatnim spotkaniu warszawskiej grupy .NET. Jedna z sesji dotyczyła przeglądu idei software factories (SF) jako przydatnego (?), a na pewno ciekawego narzędzia usprawniającego proces produkcji oprogramowania. Występujący przy słowie "przydatny" znak zapytania sygnalizować ma mój lekki dystans do tematu, przejawiany z resztą chyba przez większość uczestników spotkania. Z mojego punktu widzenia tego typu rozwiązania skierowane są potencjalnie do dwóch segmentów rynku:

• Dużych producentów aplikacji, gdzie standaryzacja działań jest elementem krytycznym. Wśród kryteriów, które należy wziąć pod uwagę wskazać można wielkość zespołu, wymagania klienta, specyfikę rynku, względy ekonomiczne itd.
• Dostawców gotowych SF, wykorzystujących specjalistyczną wiedzę dziedzinową - do użytku przez innych producentów. To pole może być stanowić łakomy kąsek dla firm doradczych i doskonale pasuje do koncepcji S+S.

Oznacza to niestety, że budowa SF od zera w Polsce jest mało prawdopodobna, ich koszt bowiem nie uzasadnia potencjalnych benefitów (co nie oznacza bynajmniej, że nie ma rynku dla konsumentów gotowych fabryk). Wracając jednak do meritum, podczas dyskusji padło interesujące pytanie: czy możliwe będzie (automatycznie) zbudowanie SF w oparciu o gotowy produkt? Skoro doczekaliśmy się już czasów kiedy granica pomiędzy modelem a kodem została (powiedzmy) zatarta, może następnym etapem będzie przygotowanie narzędzi uczących się w oparciu o rezultat (niekoniecznie) swojego działania?

Spontanicznie zaprotestowałem, używając jako analogii sytuacji, w której posiadanie samochodu nie pozwala nam w realny sposób zbudować fabryki, z której do nas trafił. Rozwijając nieco tę myśl, uważam, że dzieje się tak przynajmniej z kilku różnych powodów:

• Produkt, niezależnie od tego czy mówimy o świecie realnym czy wirtualnym, zawsze "skażony" będzie niedoskonałością. To odejście od ideału (związane z udziałem czynnika ludzkiego) w skuteczny sposób zaburza szansę odtworzenia procesu kreacji. W przypadku samochodu może być to drobne wgniecenie w karoserii, które pojawiło się w czasie transportu lub minimalnie gorsze od zakładanych parametry użytych surowców. Potencjalnym obejściem tego problemu mogłaby być próba budowy fabryki z użyciem uśrednionych danych z kilku egzemplarzy produktu. Ale czy takie uśrednienie zawsze da właściwe rezultaty?
• Hipotetycznie rzecz biorąc istnieć może dowolnie wiele fabryk, których efektem działania będzie ten sam produkt. Która z nich ma być tą właściwą? Jeśli uda się znaleźć i zalgorytmizować odpowiedź na te pytanie, zyskamy coś więcej niż możliwość reverse engineeringu - szansę na automatyczną optymalizację i dostrajanie się SF. To dopiero wyzwanie!
• Przechodząc wreszcie od abstrakcji do konkretów - SF, przynajmniej w moim rozumieniu, to nie tylko szablony i narzędzia, ale przede wszystkim doświadczenie i specjalistyczna wiedza, dostępne jedynie między wierszami kodu. Coś będącego poza zasięgiem wszelkich automatów...