Effective software delivery. White paper. May 2009

Krzywe i koszty… architektury

Dwa tygo­dnie temu, na kon­fe­ren­cji o jako­ści sys­te­mów IT, pre­zen­to­wa­łem mię­dzy inny­mi dwa poniż­sze wykresy:

Koszty rozwoju


Pierwszy wykres jest bar­dzo popu­lar­ny w lite­ra­tu­rze przed­mio­tu, tu jeden z wie­lu przy­kła­dów. Powołam się na nie­go później.

Effective software delivery. White paper. May 2009

Drugi jest wyni­kiem moich stu­diów lite­ra­tu­ry , wła­snych badan i doświad­cze­nia i wła­śnie o nim nie­co wię­cej. Wyjaśnię jak powstał.

W zasa­dzie wystar­czy uznać, że jeże­li speł­nie­nie zasa­dy „[[open clo­sed prin­ci­ple in object orien­ted softwa­re]]” (archi­tek­tu­ra sys­te­mu jest otwar­ta na roz­sze­rze­nia i zamknię­ta na zmia­ny) jest moż­li­we, to kod tak zbu­do­wa­nej apli­ka­cji rośnie” linio­wo, a koszt roz­wo­ju podob­nie. Początkowy koszt, to koszt opra­co­wa­nia szkie­le­tu (zwa­ne­go [[core doma­in]]). To wła­śnie – w apli­ka­cjach kon­stru­owa­nych zgod­nie z [[zasa­da­mi SOLID]] – powo­du­je, że koszt począt­ko­wy jest rela­tyw­nie wyż­szy niż koszt archi­tek­tu­ry budo­wa­nej ad-hoc” (ozna­czo­nej ???).

Nie mam ambi­cji two­rze­nia przy­kła­du brzyd­kiej archi­tek­tu­ry”, chy­ba już nie umiem 😉 dla­te­go poni­żej tyl­ko struk­tu­ra apli­ka­cji (archi­tek­tu­ra kom­po­nen­tu Model/MVC) w obiek­to­wym para­dyg­ma­cie (apli­ka­cja to współ­pra­cu­ją­ce obiek­ty) zgod­na z SOLID:

Obiektowy model dziedziny Zasada SOLID
Przykład archi­tek­tu­ry na bazie wzor­ca BCE (BCCE)

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. Kilka cech tej architektury:

  1. każ­dy przy­pa­dek uży­cia ma dedy­ko­wa­ną kla­sę (ta połą­czo­na z akto­rem) odpo­wie­dzial­ną za jego inter­fejs i sce­na­riusz (ale nie logi­kę biznesową!),
  2. sce­na­riusz przy­pad­ku uży­cia to recep­ta” na to, kie­dy i cze­go wewnątrz apli­ka­cji nale­ży użyć do reali­za­cji celu użytkownika,
  3. to co potra­fi” apli­ka­cja to usłu­gi wewnętrz­ne (logi­ka biznesowa),
  4. to co apli­ka­cja musi wie­dzieć” zapa­mię­ta­ło się (jest prze­cho­wy­wa­ne) w repozytoriach,
  5. żad­ne infor­ma­cje nie są, logicz­nie ani w szcze­gól­no­ści fizycz­nie, współ­dzie­lo­ne: każ­de repo­zy­to­rium, powy­żej są trzy, jest w 100% her­me­ty­zo­wa­ne (imple­men­ta­cja repo­zy­to­riów to abso­lut­nie! nie jest jed­na współ­dzie­lo­na rela­cyj­na baza danych i mapo­wa­nie ORM!).

Widać (mam nadzie­ję na tym dość pro­stym sche­ma­cie), że każ­dy przy­pa­dek uży­cia to odręb­ny ser­wis”, prak­tycz­nie nie­za­leż­na usłu­ga (u Fowlera nazy­wa­ne mikro­ser­wi­sa­mi). Są od sie­bie cał­ko­wi­cie odse­pa­ro­wa­ne, co naj­wy­żej korzy­sta­ją z tych samych spe­cja­li­zo­wa­nych usług wewnętrz­nych (np. z gene­ra­to­ra pli­ków PDF będzie korzy­sta­ła każ­da usłu­ga ope­ru­ją­ca na doku­men­tach do dru­ku). Dodanie kolej­ne­go przy­pad­ku uży­cia w ogó­le nie wpły­wa na resz­tę apli­ka­cji (zale­ta her­me­ty­za­cji), ewen­tu­al­ne redun­dan­cje są raczej zba­wie­niem niż wadą, gdyż każ­da usłu­ga ma swój kon­tekst i wła­sny cykl życia, i jakie­kol­wiek współ­dzie­le­nie tre­ści (nie mylić z wyko­rzy­sta­niem tych samych) raczej zmu­si do (zgni­łe­go) kompromisu.

Współdzielenie danych naj­czę­ściej przy­no­si szko­dy, np. współ­dzie­le­nie listy pro­duk­tów pomię­dzy zamó­wie­niem i fak­tu­rą powo­du­je zależ­ność unie­moż­li­wia­ją­cą wysta­wie­nie fak­tu­ry na pro­duk­ty inne (w innej ilo­ści) niż na tym zamó­wie­nia (nie takie rzad­kie zja­wi­sko w dostęp­nych na ryn­ku sys­te­mach ERP). Utworzenie fak­tu­ry poprzez sko­pio­wa­nie (wyko­rzy­sta­nie) zawar­to­ści Zamówienia, pozwa­la na jej (fak­tu­ry) dowol­ną mody­fi­ka­cję bez potrze­by zmia­ny Zamówienia (żąda­nia powtór­ne­go jego przy­sła­nia lub o zgro­zo, wewnętrz­nej korek­ty!). Współdzielenie danych firm pomię­dzy np. fak­tu­ra­mi i reje­strem kon­tra­hen­tów, skut­ku­je pro­ble­mem gdy aktu­ali­za­cja adre­su kon­tra­hen­ta prze­no­si się na histo­rycz­ne fak­tu­ry. Owszem może nam się przy­tra­fić koszt nowej usłu­gi wewnętrz­nej, ale zro­bi­my to bez jakiej­kol­wiek inge­ren­cji w dotych­cza­so­wą logi­kę (i kod).

Aplikacje, któ­rych archi­tek­tu­ra wewnętrz­na bazu­je na współ­dzie­lo­nych danych, rela­cyj­nej jed­nej bazie danych (jeden spój­ny sys­tem tablic rela­cyj­nej bazy danych pod” apli­ka­cją), gęstej sie­ci wewnętrz­nych zależ­no­ści, wyma­ga­ją – dla doda­nia nowej usłu­gi lub zmia­ny ist­nie­ją­cej – pra­wie zawsze czę­ścio­we­go lub cał­ko­wi­te­go re-fak­to­rin­gu, a w skraj­nych przy­pad­kach nawet migra­cji danych do nowej ich struk­tu­ry. W efek­cie, to co użyt­kow­nik postrze­ga jako roz­sze­rze­nie, dla dewe­lo­pe­ra sta­no­wi pra­co­chłon­ny refak­to­ring, tym bar­dziej pra­co­chłon­ny im więk­sza ta apli­ka­cja. Z tego powo­du kosz­ty wpro­wa­dza­nia zmian do tak stwo­rzo­nej apli­ka­cji są tym więk­sze im więk­sza i zło­żo­na jest ta apli­ka­cja (czer­wo­na linia na wykre­sie kosz­tu roz­sze­rze­nia funkcjonalności).

Pisanie opro­gra­mo­wa­nia ad-hoc, bez prze­my­śla­nej logi­ki i archi­tek­tu­ry cało­ści, pro­wa­dzi do powsta­wa­nia tak zwa­ne­go „[[dłu­gu archi­tek­to­nicz­ne­go]]” (ana­lo­gicz­nie do [[dług tech­no­lo­gicz­ny]]). To dla­te­go bar­dzo czę­sto źle poj­mo­wa­ne agi­le” pozwa­la bar­dzo szyb­ko uzy­skać pierw­sze efek­ty, nie­ste­ty oku­pio­ne bar­dzo kosz­tow­nym póź­niej­szym utrzy­ma­niem i roz­wo­jem takiej apli­ka­cji. Chyba, że pro­dukt taki potrak­to­wa­ny zosta­nie jako efe­me­ry­da albo jako pro­to­typ odrzucany.

Niestety wie­le sys­te­mów ERP i i nie tyl­ko, powsta­ło w latach 90’tych, mają one nie­ste­ty scen­tra­li­zo­wa­ną archi­tek­tu­rę struk­tu­ral­ną (jed­na baza danych i nad nią” funk­cje prze­twa­rza­ją­ce te dane). Efekty tego widać przy wdro­że­niach, w któ­rych dopusz­czo­no tak zwa­ną kasto­mi­za­cje sys­te­mu, czy­li wła­śnie wpro­wa­dza­nie, nie raz bar­dzo wie­lu, zmian. To bar­dzo kosz­tow­ne pro­jek­ty o prak­tycz­nie nie­prze­wi­dy­wal­nym budże­cie. Niestety współ­dzie­le­nie danych wewnątrz takie­go sys­te­mu jest jego poważ­ną wadą a nie – jak to zachwa­la­ją ich dostaw­cy – zaletą…

zmiany vs. stagnacja

Czym jest dług technologiczny?

Dług tech­no­lo­gicz­ny to coś o czym mało się pisze i mówi, a pra­wie każ­dy się z nim bory­ka. W dużym uprosz­cze­niu to jak zmy­wa­nie naczyń: jeże­li robi­my to regu­lar­nie po każ­dym posił­ku, to zaj­mu­je to góra kil­ka­na­ście minut a do wyko­na­nia wystar­czy ście­recz­ka. Jeżeli jed­nak uzna­my, że zmy­je­my naczy­nia dopie­ro jak stat­ki” w zle­wo­zmy­wa­ku zasło­nią okno kuch­ni :), to nie tyl­ko jed­no­ra­zo­wo stra­ci­my znacz­nie wię­cej cza­su, ale dodat­ko­wo zafun­du­je­my sobie wal­kę z zaschnię­tym tłusz­czem i reszt­ka­mi jedze­nia, dla­te­go – co cie­ka­we – czas i wyma­ga­ne środ­ki” potrzeb­ne na rzad­kie pozmy­wa­nie tej góry nagro­ma­dzo­nych naczyń, są zawsze więk­sze niż suma nakła­dów pra­cy na czę­ste drob­ne zmy­wa­nie. Zmywanie naczyń to nie­lu­bia­na a koniecz­na czynność.

Z tech­no­lo­gią w fir­mach jest bar­dzo podob­nie: postęp tech­nicz­ny i ewo­lu­cyj­ne zmia­ny w fir­mach, są jak nara­sta­ją­ca licz­ba brud­nych naczyń: prę­dzej czy póź­niej będzie­my musie­li to upo­rząd­ko­wać (nad­ro­bić) – albo wyrzu­cić i kupić nowe. Jedno i dru­gie kosz­tu­je spo­ro. Dotyczy to w jed­na­ko­wym stop­niu aktu­ali­zo­wa­nia zakre­sów obo­wiąz­ków, doku­men­ta­cji tego jak fir­ma pra­cu­je, ana­liz i pro­jek­to­wa­nia, doku­men­ta­cji archi­tek­tu­ry IT jak i upgra­de­’ów oprogramowania.

Pojęcie ?dłu­gu? w pro­jek­cie śle­dzę od lat. Zjawisko to zna­ne jest od lat 90-tych, przy­kład takie­go dłu­gu opi­su­je E.Yourdon, któ­ry okre­śla go opi­so­wo jako ?brak pro­jek­tu? (pomi­ja­nie eta­pu ana­li­zy i pro­jek­to­wa­nia), w rozu­mie­niu bra­ku cało­ścio­wej kon­cep­cji, i wska­zu­je, że kon­se­kwen­cją zacią­ga­nia tego dłu­gu jest ?usta­wicz­ne prze­ra­bia­nie? opro­gra­mo­wa­nia w takt poja­wia­nia się nowych wyma­gań. Dług ten (archi­tek­to­nicz­ny, tu w rozu­mie­niu archi­tek­tu­ry opro­gra­mo­wa­nia) jest zacią­ga­ny poprzez roz­po­czy­na­nie prac nie zapla­no­wa­nych i nie poprze­dzo­nych pro­jek­to­wa­niem archi­tek­tu­ry cało­ści. Zadziwia mnie to, że nie raz źle piszą o tym dłu­gu tak­że zwo­len­ni­cy metod zwin­nych, któ­re to meto­dy bazu­ją wręcz na zacią­ga­niu tego dłu­gu. Prace pole­ga­ją­ce na odkry­wa­niu wyma­gań meto­da­mi kolej­nych przy­bli­żeń z pomo­cą pro­to­ty­pów, przy prak­tycz­nie zupeł­nym bra­ku eta­pów ana­li­zy i pro­jek­to­wa­nia, np. prze­cięt­ny ?sprint? to góra tydzień, jeże­li to jedy­ne pla­no­wa­nie w pro­jek­cie trwa­ją­cym (pla­no­wa­nym na) rok to jest to mega dług.

Nie zna­czy to, że wszyst­ko w fir­mie musi być koniecz­nie w naj­now­szej wer­sji, to zale­ży od tego jaki cykl życia fun­du­je nam dostaw­ca każ­dej apli­ka­cji z osob­na, jaką stra­te­gię wybie­rze­my My. Każdą nale­ży roz­pa­try­wać nie­za­leż­nie ale świa­do­mie. Z per­spek­ty­wy pro­gra­mi­sty mamy np. tak:

Wiedza o dłu­gu pozwa­la nam rów­nież go zacią­gać świa­do­mie. Moim zda­niem nie wol­no, pod karą chło­sty kla­wia­tu­ra­mi, iść na skró­ty w czę­ściach koro­wych sys­te­mu ale już w deta­lach np. inter­fej­su użyt­kow­ni­ka (KTÓRY NIE POSIADA LOGIKI APLIKACJI I LOGIKI BIZNESOWEJ!!!), może­my sobie cza­sem pozwo­lić na gor­szą jakość. Pójście na skró­ty w pierw­szym przy­pad­ku będzie mia­ło brze­mien­ne skut­ki dla całe­go sys­te­mu, w dru­gim bar­dziej lokal­ne. Jeśli w obu sytu­acjach pój­ście na skró­ty ozna­cza zysk 5h to gdzie lepiej zosta­wić małe lokal­ne pie­kieł­ko? za pomo­cą Dług Technologiczny : arek onli­ne.

Generalnie dług taki doty­czy nie­mal­że każ­de­go obsza­ru dzia­ła­nia orga­ni­za­cji. Warto więc wie­dzieć, że takie zja­wi­sko występuje:

koszty dlugu technologicznego

Ten pro­sty dia­gram obra­zu­je isto­tę dłu­gu tech­no­lo­gicz­ne­go, a raczej nawet uogól­nia­jąc: dłu­gu sta­gna­cji”. Zielona linia obra­zu­je sche­ma­tycz­nie okre­so­we, rela­tyw­nie drob­ne, zmia­ny i ich koszt. Mogą to być zarów­no bie­żą­ce upgra­de­’y (pat­che) opro­gra­mo­wa­nia jak i aktu­ali­za­cja doku­men­ta­cji opi­su­ją­cej: stra­te­gie fir­my, zakre­sy obo­wiąz­ków pra­cow­ni­ków w ich umo­wach, pro­ce­du­ry ISO (i inne) czy po pro­tu pro­jekt w toku. Brak takie­go uak­tu­al­nia­nia powo­du­je, że doku­men­ta­cja szyb­ko sta­je się nie­przy­dat­na (bo jest nie­ak­tu­al­na) a sko­ko­wy jej upgra­de wyma­ga cza­sem nawet prak­tycz­nie powtó­rze­nia całe­go pro­jek­tu wdro­że­nio­we­go (powtór­ne ponie­sie­nie jego dużych kosz­tów). Dodatkowy koszt sko­ko­wy dużej zmia­ny, to efekt mię­dzy inny­mi tego, że: nie mamy na nią zbyt wie­le cza­su więc ponie­sie­my dodat­ko­wy koszt skró­ce­nia tej czyn­no­ści (przy­mu­so­wy zakup zmy­war­ki). Kolejny koszt to sko­ko­wa zmia­na przy­zwy­cza­jeń ludzi, zmia­ny ewo­lu­cyj­ne odby­wa­ją się pły­nie, prak­tycz­nie bez kosz­tów, sko­ko­we to dodat­ko­we szko­le­nia i czas na dosto­so­wa­nie. Taki dług potra­fi w skraj­nych sytu­acjach dopro­wa­dzić fir­mę do upa­dło­ści albo co naj­mniej do znisz­cze­nia jej kon­ku­ren­cyj­no­ści (brak środ­ków na sko­ko­wą zmia­nę tech­no­lo­gii, pod­nie­sie­nie kom­pe­ten­cji kadry itp.).

Klasycznym przy­kła­dem takie­go dłu­gu jest obec­ny pro­blem wie­lu firm, posia­da­czy Windows XP, firm któ­re do tej pory nie wyko­na­ły upgra­de. Czy to dużo firm? No nie­ste­ty jak widać, dużo:

W mar­cu z kom­pu­te­rów z opro­gra­mo­wa­niem Windows XP pocho­dzi­ła bli­sko jed­na czwar­ta ruchu w sie­ci ? wyni­ka z danych fir­my Gemius. Zakończenie wspar­cia dla tego sys­te­mu ope­ra­cyj­ne­go może być pro­ble­mem ? oce­nia­ją eks­per­ci z Akademii Leona Koźmińskiego.

Zdaniem Macieja Madzińskiego, eks­per­ta Akademii Leona Koźmińskiego ds. inno­wa­cji i nowo­cze­snych tech­no­lo­gii, zaprze­sta­nie wspie­ra­nia sys­te­mu Windows XP przez Microsoft będzie pro­ble­mem i będzie wywo­ły­wać, a nawet już wywo­łu­je pew­ne nie­za­do­wo­le­nie. (Koniec Windowsa XP ? pro­blem czy szan­sa? :: Gemius SA).

W efek­cie fir­my te nie tyl­ko w koń­cu i tak ponio­są koszt tej aktu­ali­za­cji. Poniosą tak­że kosz­ty sko­ko­wej aktu­ali­za­cji wie­lu innych pro­duk­tów (przej­ście na now­szą wer­sje Windows, w wie­lu przy­pad­kach wyma­ga aktu­ali­za­cji wie­lu apli­ka­cji, sys­te­mów zarzą­dza­nia sie­cią, ich powtór­ne wdra­ża­nie itp.). Niektórzy eks­per­ci oce­nia­ją, że w nie­któ­rych fir­mach będą to kosz­ty więk­sze w porów­na­niu z kosz­ta­mi pro­ble­mu roku 2000”. Przytoczę teraz cytat z inne­go bloga:

Na blo­gu Szymona Błochowicza umiesz­czo­na jest taka defi­ni­cja dłu­gu tech­no­lo­gicz­ne­go: ?Cokolwiek co czy­ni Twój pro­dukt trud­nym do zmia­ny w przy­szło­ści jest dłu­giem tech­no­lo­gicz­nym ? możesz albo zapła­cić peł­ną cenę tech­no­lo­gicz­ną teraz zro­bić od razu roz­wią­za­nie ela­stycz­ne albo zacią­gnąć dług i spła­cić go póź­niej zro­bić roz­wią­za­nie szyb­kie ale nie­ela­stycz­ne a przy pierw­szej koniecz­no­ści zmia­ny mieć trud­ność z bra­kiem ela­stycz­no­ści?. Najczęściej dług tech­no­lo­gicz­ny koja­rzo­ny jest ze spo­so­bem kodo­wa­nia, doku­men­to­wa­nia czy też testo­wa­nia. Ale Arkadiusz Bendedykt na swo­im blo­gu wska­zu­je rów­nież, że ?dług tech­no­lo­gicz­ny to nie tyl­ko pój­ście na skró­ty pod­czas kodo­wa­nia, to rów­nież zanie­cha­nie prze­cho­dze­nia na naj­now­sze wer­sje narzę­dzi pro­gra­mi­stycz­nych oraz nie wspie­ra­nie naj­now­szych sys­te­mów ope­ra­cyj­nych?. Jeszcze dalej idzie Jan Rychter, któ­ry wska­zu­je że: ?gdy doty­czy to [tj. pój­ście na skró­ty – przy­pis A.S.] poje­dyn­czych funk­cji w kodzie, dług jest nie­wiel­ki. Gdy jed­nak mówi­my o decy­zjach archi­tek­tu­ral­nych [wolał­bym uży­wać okre­śle­nia decy­zje archi­tek­to­nicz­ne – przy­pis A.S.], może być olbrzy­mi i pocią­gać za sobą koniecz­ność prze­ra­bia­nia kie­dyś całych sys­te­mów?. (źr. Czym jest dług archi­tek­to­nicz­ny? | Architektura Korporacyjna).

Tak więc sta­gna­cja szko­dzi, są to krót­ko­trwa­łe zyski, podob­ne do nie­za­pła­ce­nia rachun­ku za ener­gie elek­trycz­ną: za mie­siąc będzie dwu­krot­nie wyż­szy plus odset­ki. Bieżące, dobrze zapla­no­wa­ne aktu­ali­za­cje” (opro­gra­mo­wa­nia, doku­men­ta­cji pro­jek­to­wej, ana­li­zy i pla­no­wa­nia, itp.) to rela­tyw­nie małe kosz­ty, a dla fir­my istot­ne są nie tyle kwo­to­we chwi­lo­we wydat­ki (oszczęd­no­ści) co płyn­ność finan­so­wa i dłu­go­ter­mi­no­wa ren­tow­ność. Dlatego per­ma­nent­ni dłuż­ni­cy zawsze pła­ca wię­cej a cza­sa­mi ban­kru­tu­ją. Tu pole­cam mój wpis z przed roku: Utopia – czy­li model ide­ału poma­ga w pro­jek­tach.

zmiany vs. stagnacja

___

Rok póź­niej:

A na koniec pole­cam to:

Zasady panu­ją­ce na ryn­ku pro­duk­tów i usług IT wyda­ją się przej­rzy­ste: klient wyda­je pie­nią­dze na jakiś pro­dukt, ocze­ku­jąc w zamian okre­ślo­nych korzy­ści. Jak wyni­ka z udo­stęp­nio­nych przez Gartner Inc. ana­liz, fir­my reali­zu­ją przy oka­zji swo­ją stra­te­gię, o któ­rej wola­ły­by klien­tom nie mówić. Jakie są ich cele? […] Omawiając stra­te­gie firm, Gaughan pod­kre­ślił rów­nież zna­cze­nie dzia­ła­ją­cych przy nich ośrod­ków badaw­czych. Ich nad­rzęd­nym celem jest two­rze­nie inno­wa­cji w takich spo­sób, aby ? zacho­wu­jąc pozo­ry roz­wo­ju ? utrzy­my­wać ist­nie­ją­cy stan rze­czy tak dłu­go, jak to tyl­ko moż­li­we.(źr. Czego naj­więk­sze fir­my tech­no­lo­gicz­ne nie mówią swo­im klien­tom?. oraz ory­gi­nał: What Microsoft, Oracle, IBM, And SAP Don’t Tell Customers)

Utopia – czyli model ideału pomaga w projektach

Usługa ta sta­no­wi sobą audyt tre­ści i struk­tu­ry doku­men­tów w pro­ce­sach biz­ne­so­wych oraz opra­co­wa­nie mode­lu archi­tek­tu­ry IT w celu mapo­wa­nia doku­men­tów na apli­ka­cje, w któ­rych powsta­ją i są wyko­rzy­sty­wa­ne (inte­gra­cja). Są to wyłą­czo­ne i połą­czo­ne razem pierw­sze eta­py usług Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści oraz Analiza i Opracowanie Wymagań na Oprogramowanie. Jednym z głów­nych celów i pro­duk­tów jest opra­co­wa­na stra­te­gia cyfry­za­cji i archi­wi­za­cji doku­men­tów w orga­ni­za­cji oraz zarzą­dza­nia ich treścią.

Ten wpis adre­su­ję przede wszyst­kim mene­dże­rom nie tyl­ko IT. Analitycy i pro­gra­mi­ści spo­koj­nie mogą go pomi­nąć, chy­ba, że …;) chcą wie­dzieć dla­cze­go powin­ny powsta­wać ide­ali­zo­wa­ne pro­jek­ty, kie­dy mogą cza­sem wyko­nać nie­ko­niecz­nie ide­al­ną imple­men­ta­cję i dla­cze­go nie nale­ży pomi­jać eta­pu pro­jek­to­wa­nia ide­ali­za­cji .

W jed­nym z ostat­nich wpi­sów w dys­ku­sji napi­sa­łem w komen­ta­rzach, że:

…jestem pury­stą for­mal­nym. Jednak nie dla­te­go, by pacy­fi­ko­wać pro­jek­ty orto­dok­sją. To efekt dwóch rze­czy: teo­ria pozna­nia jako restryk­cyj­ne pod­cho­dze­nie do seman­ty­ki, pozwa­la unik­nąć nie­jed­no­znacz­no­ści. Druga rzecz, to zde­fi­nio­wa­nie ide­ału, pozwa­la oce­nić (zmie­rzyć) odstęp­stwo kon­kret­ne­go pro­jek­tu od nie­go [od ide­ału]. To pozwa­la oce­nić ryzy­ko takie­go pro­jek­tu. Fizyka ma np. nie­ist­nie­ją­ce w natu­rze ide­al­ne waha­dło czy cia­ło dosko­na­le czar­ne , po co? By móc oce­nić błąd rze­czy­wi­stych obli­czeń. Zdaję sobie spra­wę, że to filo­zo­fia, ale taki mam cel , nie tyl­ko ana­li­zo­wać i mode­lo­wać ale w 100% rozu­mieć (Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu).

Dość czę­sto spo­ty­kam się z zarzu­tem, że to szko­dzi pro­jek­tom, że trze­ba z jed­nej stro­ny nagi­nać zasa­dy a z dru­giej, że nie ma co zaj­mo­wać się ide­al­ny­mi sys­te­ma­mi bo takich nie będzie, że ogra­ni­cze­nia pro­jek­tu, głów­nie czas i budżet, wyma­ga­ją psu­cia” bo na ide­ały nie ma czasu. 

To są nie­ste­ty, w moim mnie­ma­niu, tłu­ma­cze­nia ludzi nie potra­fią­cych tego ide­ału zro­bić czy­li nie­ma­ją­cych pomy­słu na wła­ści­we roz­wią­za­nie, czy­taj, nie potra­fią­cych pro­ble­mu rozwiązać. 

Droga na skró­ty to dro­ga nie­wie­dzy. Nie twier­dzę tu, że sens mają wyłącz­nie pro­jek­ty ide­al­ne. Twierdze, że na eta­pie ana­li­zy pro­ble­mu i pro­jek­to­wa­nia powi­nien powstać ide­ał, a dopie­ro na eta­pie ana­li­zy zakre­su pro­jek­tu i oce­ny wyko­nal­no­ści, jest miej­sce na ewen­tu­al­ne uprosz­cze­nia, bo tu są one czy­nio­ne świadomie.

Z tezą taką w lite­ra­tu­rze spo­ty­kam się bar­dzo rzad­ko, ale spo­ty­kam . Możliwe, że to bar­dzo odważ­na teza: 

więk­szość pro­jek­tów to roz­wią­zy­wa­nie nie­zro­zu­mia­ne­go problemu. 

Statystyki jed­nak zda­ją się potwier­dzać, że coś jest na rze­czy .

Na szczę­ście, nie ja jeden tak sądzę. Tu zacy­tu­ję tak­że blog pew­ne­go programisty:

cią­gle zmie­nia­ją­cy się pro­gram zwięk­sza swo­ją zło­żo­ność o ile nie pochy­li­my się nad kodem aby ją zmniej­szyć. Pisanie pro­gra­mów jest łatwe, wręcz banal­nie łatwe, jed­nak pisa­nie tak, aby dało się je dłu­go i w mia­rę tanio utrzy­my­wać jest bar­dzo trud­ne. Wynika to z dwóch zło­żo­no­ści. Jedna to zło­żo­ność same­go pro­ble­mu, dru­ga to zło­żo­ność przy­pad­ko­wa. Tą przy­pad­ko­wą two­rzy­my my sami ? pro­gra­mi­ści. Sami kom­pli­ku­je­my soft bar­dzo czę­sto zupeł­nie nie­po­trzeb­nie. Sami idąc na skró­ty gma­twa­my kod tak, że sta­je się z dnia na dzień coraz droż­szy w utrzy­ma­niu. To podra­ża­nie utrzy­ma­nia to wła­śnie dług tech­no­lo­gicz­ny. Dług tech­no­lo­gicz­ny, jak każ­dy dług ma to do sie­bie, że im dłu­żej nie spła­ca­ny tym wię­cej będzie kosz­to­wać. (Dług tech­no­lo­gicz­ny | @rek onli­ne | Arkadiusz Benedykt, Gorąco pole­cam cały ten cykl artykułów).

Tu autor pastwi się, i słusz­nie, na zacią­ga­niem dłu­gu, któ­ry ja postrze­gam jako dług nie tyl­ko tech­no­lo­gicz­ny. To dług nie­zro­zu­mie­nia mają­cy swój począ­tek już na eta­pie ana­li­zy: ktoś nie chciał do koń­ca zro­zu­mieć zło­żo­no­ści pro­ble­mu (patrz wytłusz­cze­nie w cyta­cie), zigno­ro­wał etap dogłęb­nej ana­li­zy pro­ble­mu i zaczął kodo­wać: zacią­gnął dług nie pono­sząc kosz­tu zro­zu­mie­nia tyl­ko zaczy­na od razu kodo­wać. Przypomnę, że pomi­ja­nie dogłęb­nej ana­li­zy i two­rze­nie kodu to imple­men­ta­cja cze­goś, cze­go wła­śnie nie chcie­li­śmy do koń­ca zro­zu­mieć. Czy to zda­nie nie brzmi strasz­nie? Co powstanie?

Czego się spo­dzie­wać po pro­jek­cie, gdy sły­szę: nie ma cza­su na ana­li­zę, myśmy już pod­pi­sa­li umo­wę z wyko­naw­cą bo nasza fir­ma nie ma cza­su. Niestety naj­czę­ściej taki pro­jekt trwa znacz­nie dłu­żej niż pla­no­wa­no, pie­nią­dze oszczę­dzo­ne na zbęd­nym” pro­jek­to­wa­niu ide­ału z ogrom­ną nawiąz­ką są wyda­wa­ne na kolej­ne mody­fi­ka­cje i popraw­ki (spła­ta dłu­gu, nie raz bar­dzo kosztowna).

O sku­tecz­nym zarzą­dza­niu, posia­da­niu wizji, napi­sa­no wie­le, nie jest to miej­sce na powie­la­nie tych prawd. Spójrzmy na poniż­szy cytat:

Społeczeństwo nie­zdol­ne do wyda­wa­nia na świat uto­pii i do poświę­ca­nia się jej zagro­żo­ne jest skle­ro­zą i ruiną. Mądrość, dla któ­rej nie ist­nie­ją żad­ne fascy­na­cje, zale­ca nam szczę­ście dane, goto­we. Wybór szczę­ścia wyobra­żo­ne­go czy­ni nas zdol­nym do zmia­ny, do wzro­stu. Emil Cioran (Business Dialog – Posłuchaj. Powiedz. Przynosimy radość owoc­nej roz­mo­wy)..

A teraz małe ćwi­cze­nie: zamień­cie pań­stwo sło­wo Społeczeństwo” na Organizacje”…

Powyższe wywo­dy, cza­sa­mi wspo­mi­nam o pro­ble­mie dłu­gu na kon­fe­ren­cjach czy na forach, natych­miast wywo­łu­ją pobud­kę zwo­len­ni­ków metod zwin­nych (co by to nie mia­ło zna­czyć). Wiem, że są podob­no róż­ne for­my zwin­no­ści, te dobre i te złe. Ale podob­no zakoń­czo­ne suk­ce­sem zwin­ne pro­jek­ty są jak Yeti: każ­dy o nich mówi a nikt nie widział. Tu zno­wu zacy­tu­ję przy­wo­ły­wa­ny już tu blog:

Modne ostat­nio pro­gra­mo­wa­nie agi­le czy też pro­gra­mo­wa­nie zwin­ne ozna­cza w dużym uprosz­cze­niu cią­głą ewo­lu­cję i cią­głe wpro­wa­dza­nie zmian, tak żeby być ela­stycz­nym na potrze­by biz­ne­su. Nie da się być agi­le budu­jąc mono­li­ty, nie da się być agi­le zacią­ga­jąc coraz to nowe dłu­gi tech­no­lo­gicz­ne. W koń­cu, nie da się być agi­le jeśli po roku czy dwóch wpro­wa­dza­nie zmian zaczy­na trwać dłu­żej i dłu­żej. Jeśli chce­my być agi­le to musi­my bar­dzo moc­no trzy­mać się zasad dobre­go pro­gra­mo­wa­nia. Musimy two­rzyć ela­stycz­ne i otwar­te kon­struk­cje zamiast mono­li­tów. SOLID w tym bar­dzo poma­ga cho­ciaż nie jest to jedy­na ?reli­gia?. Aby to zro­bić trze­ba poświę­cić odpo­wied­nią ilość cza­su i potu aby wypro­du­ko­wać dobry kawa­łek kodu. (Monolity to też dług tech­no­lo­gicz­ny | @rek onli­ne | Arkadiusz Benedykt).

Cóż, o SOLID za nie­dłu­go napi­szę wię­cej, dziś podam jed­ną z klu­czo­wych zasad, nazwał bym ją klu­czo­wym wyma­ga­niem poza­funk­cjon­la­nym: pro­jekt ma być odpor­ny na zmia­ny i otwar­ty na roz­sze­rze­nie. Jak to osią­gnąć? jest tyl­ko jeden spo­sób: wyko­nać dobry pro­jekt. Dobry czy­li prze­my­śla­ny, z peł­nym zro­zu­mie­niem pro­ble­mu i świa­do­mym odkła­da­niem pew­nych prac.

Na zakoń­cze­nie przy­znam, że wśród moich nie­do­szłych klien­tów i pro­gra­mi­stów mam wie­lu wro­gów. To Ci, któ­rzy uwa­ża­ją, że ana­li­zy i pro­jek­to­wa­nie ide­ału (co by tu sło­wo nie mia­ło ozna­czać) na samym począt­ku są bez sen­su, bo i tak wyma­ga­nia biz­ne­su się zmie­nią, więc i pro­gram będzie się zmie­niał. Ja wte­dy pytam: zmie­niał czy roz­sze­rzał? Jeżeli wyma­ga­nia się zmie­nia­ją to raczej sygnał, że nie zosta­ły na począt­ku prze­my­śla­ne… Ale wyma­ga­niem powi­nien być cel a nie aktu­al­ne środ­ki jego osią­ga­nia! Biznes tak­że ma skłon­no­ści do zacią­ga­nia opi­sy­wa­ne­go dłu­gu… Na koniec w kwe­stii wro­gów pół żar­tem i pół serio:

Chińczycy hoł­du­ją powie­dze­niu: ?jak posie­dzisz wystar­cza­ją­co dłu­go nad brze­giem rze­ki, to zoba­czysz tru­py swo­ich wro­gów pły­ną­ce z prą­dem”. No więc sobie siedzę.

… i nie raz je oglą­dam… a sie­dzę sobie ana­li­zu­jąc i pro­jek­tu­jąc… 😉 i nie jestem tu sam…

Źródła

Niaz, M. (1999). The role of ide­ali­za­tion in scien­ce and its impli­ca­tions for scien­ce edu­ca­tion. Journal of Science Education and Technology, 8(2), 145 – 150.
Niaz, M. (1993). If Piaget’s epi­ste­mic sub­ject is dead, shall we bury the scien­ti­fic rese­arch metho­do­lo­gy of ide­ali­za­tion? Journal of Research in Science Teaching, 30(7), 809 – 812. https://​doi​.org/​1​0​.​1​0​0​2​/​t​e​a​.​3​6​6​0​3​0​0​717
Weisberg, M. (2007). Three Kinds of Idealization: The Journal of Philosophy, 104(12), 639 – 659. https://​doi​.org/​1​0​.​5​8​4​0​/​j​p​h​i​l​2​0​0​7​1​0​4​1​240
Jørgensen, M., & Moløkken-Østvold, K. (2006). How lar­ge are softwa­re cost over­runs? A review of the 1994 CHAOS report. Information and Software Technology, 48(4), 297 – 301. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​5​.​0​7​.​002
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Matthews, M. R. (2004). Idealisation and Galileo’s pen­du­lum disco­ve­ries: Historical, phi­lo­so­phi­cal and peda­go­gi­cal con­si­de­ra­tions. Science & Education, 13(7 – 8), 689 – 715.

Czego największe firmy technologiczne nie mówią swoim klientom?

Zasady panu­ją­ce na ryn­ku pro­duk­tów i usług IT wyda­ją się przej­rzy­ste: klient wyda­je pie­nią­dze na jakiś pro­dukt, ocze­ku­jąc w zamian okre­ślo­nych korzy­ści. Jak wyni­ka z udo­stęp­nio­nych przez Gartner Inc. ana­liz, fir­my reali­zu­ją przy oka­zji swo­ją stra­te­gię, o któ­rej wola­ły­by klien­tom nie mówić. Jakie są ich cele? […]

Omawiając stra­te­gie firm, Gaughan pod­kre­ślił rów­nież zna­cze­nie dzia­ła­ją­cych przy nich ośrod­ków badaw­czych. Ich nad­rzęd­nym celem jest two­rze­nie inno­wa­cji w takich spo­sób, aby ? zacho­wu­jąc pozo­ry roz­wo­ju ? utrzy­my­wać ist­nie­ją­cy stan rze­czy tak dłu­go, jak to tyl­ko moż­li­we.(źr. What Microsoft, Oracle, IBM, And SAP Don’t Tell Customers)

Skąd się u wie­lu użyt­kow­ni­ków tech­no­lo­gii IT bie­rze dług tech­no­lo­gicz­ny już w momen­cie pod­pi­sa­nia umo­wy na wdro­że­nie? Stąd, że zle­co­no ana­li­zę przed­wdro­że­nio­wą wyma­gań dostaw­cy tech­no­lo­gii, a w jego inte­re­sie jest dostar­czyć to co ma, a nie to cze­go potrze­bu­je klient.