Model czy abstrakcja

[zak­tu­ali­zo­wa­ny lip 16, 2020 @ 13:28]

Niedawno pisa­łem na temat mode­lu sys­te­mu” i mode­lu dzie­dzi­ny sys­te­mu”. Oba te poję­cia są sobie bli­skie, pierw­sze jest bar­dzo ogól­ne, doty­czy sys­te­mu zawę­żo­ne­go do jego dzie­dzi­no­wej spe­cy­fi­ki. Model dzie­dzi­ny sys­te­mu to tak­że, w inży­nie­rii opro­gra­mo­wa­nia, nazwa kon­kret­ne­go kom­po­nen­tu, nazy­wa­ne­go Model, w archi­tek­tu­rze opar­tej na wzo­ru MVC. Swego cza­su pisa­łem, że (Czym jest a czym nie jest model dzie­dzi­ny…):

Pojęcie sys­tem ozna­cza albo deta­licz­ną struk­tu­rę okre­ślo­nej rze­czy­wi­sto­ści albo abs­trak­cję ją repre­zen­tu­ją­cą (model systemu).

Jest to stan­dar­do­we tłu­ma­cze­nie tego poję­cia w lite­ra­tu­rze z zakre­su teo­rii sys­te­mów a tak­że wła­śnie inży­nie­rii opro­gra­mo­wa­nia .

Mam wła­śnie za sobą kil­ka spo­tkań na tar­gach IT Future Expo. Dotyczyły mię­dzy inny­mi roli pro­duct owne­ra”, ana­li­ty­ka biz­ne­so­we­go i wymia­ny infor­ma­cji pomię­dzy deve­lo­pe­ra­mi i resz­tą świa­ta”. Okazuje się, że naj­więk­szym pro­ble­mem w pro­jek­cie jest: (a) zro­zu­mieć cze­go chce zama­wia­ją­cy biz­nes, (b) prze­two­rzyć to tak by deve­lo­per wie­dział co ma zaim­ple­men­to­wać. I tu nie­ste­ty jest pro­blem: deve­lo­per owszem jest bar­dzo dobry w imple­men­ta­cji… i w niczym wię­cej. Co cie­ka­we, pro­gra­mi­ści, z któ­ry­mi czę­sto mam do czy­nie­nia, nie potra­fią (nie chcą?) myśleć abs­trak­cyj­nie, ocze­ku­ją typo­wej kawy na ławę” (pierw­szy dzień pro­jek­tu a tu nagle ktoś pyta o typ pola nazwi­sko”). Gorzej, wie­lu z nich myśli wyłącz­nie o odda­niu kodu na jutro rano”. Paradoksalnie, nie mała rota­cja na sta­no­wi­skach pro­gra­mi­stów oraz regu­lar­ne prze­no­sze­nie wszel­kich kosz­tów i ryzyk na kupu­ją­ce­go (któ­ry tego nie wie, bo nie rozu­mie tej tech­no­lo­gii), powo­du­je, że prze­my­śla­na archi­tek­tu­ra cało­ści to coś cze­go nie nikt robi, deve­lo­per po pro­stu koduje…

Nie wal­czy­my z fak­ta­mi, musi­my się z nimi zmie­rzyć. Jak? Dać deve­lo­pe­ro­wi i egze­kwo­wać archi­tek­tu­rę i logi­kę sys­te­mu jako wyma­ga­nie, a nie zebra­ne wyma­ga­nia”. Niestety, oso­ba zwa­na ana­li­ty­kiem, nie powin­na postrze­gać swo­jej pra­cy jako kolek­cjo­ne­ra” („zbie­ra­nie wyma­gań” zawsze koja­rzy mi się ze zbie­ra­niem grzy­bów). Tak zwa­ny ana­li­tyk musi abs­tra­ho­wać od wszel­kich deta­li, bez tego pro­jekt zosta­nie już na samym począt­ku zabi­ty” ich ilo­ścią. To się nazy­wa utra­ta pano­wa­nia nad zło­żo­no­ścią pro­jek­tu” a w kon­se­kwen­cji utra­ta pano­wa­nia nad zakre­sem pro­jek­tu”. W arty­ku­le o zega­rze [1] opi­sa­łem jak to zro­bić, tu opi­szę źró­dła tego podejścia.

Analiza systemowa dziedziny problemu

Praca ana­li­ty­ka powin­na mieć cha­rak­ter nauko­wy”: na bazie fak­tów opi­su­je się logi­kę dzia­ła­nia ana­li­zo­wa­nej orga­ni­za­cji . Przede wszyst­kim trze­ba mieć świa­do­mość, że bada­nym sys­te­mem jest np. orga­ni­za­cja a nie tyl­ko sys­tem infor­ma­tycz­ny”. Organizacja (fir­ma, urząd, itp.) to sys­tem skła­da­ją­cy się z ludzi i narzę­dzi jakich uży­wa­ją a całość jest ste­ro­wa­na regu­ła­mi (pra­wo, regu­la­cje wewnętrz­ne nie­spi­sa­ne zasa­dy itp.). Część z tych narzę­dzi to opro­gra­mo­wa­nie. Jeżeli jest to opro­gra­mo­wa­nie pla­no­wa­ne do zaku­pu i wdro­że­nia, to zna­czy, że ktoś musi zro­zu­mieć stan obec­ny, zro­zu­mieć cele i zapro­jek­to­wać stan przy­szły, zakła­da­ją­cy ist­nie­nie nowe­go opro­gra­mo­wa­nia. Nie ma tu zna­cze­nia czy będzie to opro­gra­mo­wa­nie wspo­ma­ga­ją­ce pro­duk­cje czy praw­ni­ka i jego pracę. 

A gdzie wyma­ga­nia? Wymaganiem jest pro­jekt logi­ki (archi­tek­tu­ra) nowe­go opro­gra­mo­wa­nia. Czy to robo­ta ana­li­ty­ka? Tak, bo deve­lo­per jest od wyko­na­nia implementacji.

Zegar. Abstrakcja systemu

Przede wszyst­kim war­to upo­rząd­ko­wać uży­te tu poję­cia, któ­re są czę­sto mylo­ne lub źle interpretation:

  • abs­tra­hu­je­my od czegoś 
  • ide­ali­zu­je­my coś

Modelowanie pole­ga na abs­tra­ho­wa­niu od okre­ślo­nych szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mechanizm

Powinno paść pyta­nie: Co sys­tem robi? (będzie robił jak go wdrożymy).

Jeżeli był­by to zegar, to sys­tem wska­zu­je aktu­al­ny czas”. To jest biz­ne­so­wy cel, uzna­no, że potrzeb­na jest sta­ła zna­jo­mość aktu­al­nej godzi­ny, a nie my chce­my mieć zegar”.

Teraz decy­zja: Jak sys­tem to robi? Może to być zegar ścien­ny, ana­lo­go­wy, cyfro­wy, może to być sta­le włą­czo­ne radio. Decyzja brzmi: zegar ścien­ny ana­lo­go­wy (poni­żej pro­to­typ w posta­ci mock-up’u). 

I dopie­ro teraz wiem o co pytać dostawców!

Tu draż­li­wy moment. Jeżeli opi­sze­my to tyl­ko pro­sty­mi histo­ryj­ka­mi użyt­kow­ni­ka to może się skoń­czyć tak, że deve­lo­per po pro­stu stwo­rzy kil­ka­dzie­siąt obra­zów tar­czy zega­ra i będzie je wyświe­tlał np. na wiszą­cym ekra­nie. To nic inne­go jak lite­ral­nie zre­ali­zo­wa­ne zebra­ne wyma­ga­nia” (pro­szę się nie śmiać, tak to nie raz wyglą­da: hard­ko­do­wa­nie” wymagań).

Dlatego war­to jed­nak opra­co­wać abs­trak­cyj­ną archi­tek­tu­rę roz­wią­za­nia czy­li model opi­su­ją­cy mecha­nizm dzia­ła­nia tego co chce­my otrzymać:

To nam zagwa­ran­tu­je, że deve­lo­per nie pój­dzie na łatwi­znę, że nasz zegar będzie się dał w przy­szło­ści roz­wi­jać i mody­fi­ko­wać .

Teraz dopie­ro deve­lo­per, mając (i słusz­nie) nie­co zwią­za­ne ręce, opra­cu­je kon­cep­cję reali­za­cji (Jak sys­tem został zre­ali­zo­wa­ny?), my ją zatwier­dzi­my i dosta­nie­my np. to:

…albo opro­gra­mo­wa­nie zawie­ra­ją­ce trzy kom­po­nen­ty i wyświe­tlacz. Jak nam kie­dyś przyj­dzie do gło­wy doda­nie datow­ni­ka albo zamia­na tar­czy ana­lo­go­wej na cyfro­wą, to będzie to roz­wój opro­gra­mo­wa­nia a nie kosz­tow­ne pisa­nie od zera (gdy­by nam dano pro­jek­tor z fil­mem z nakrę­co­nym zega­rem ana­lo­go­wym). To jak ten sys­tem został zre­ali­zo­wa­ny zale­ży od deve­lo­pe­ra, jed­nak jego logi­ka i archi­tek­tu­ra powin­ny być opra­co­wa­ne wcze­śniej po stro­nie zama­wia­ją­ce­go i narzu­co­ne deve­lo­pe­ro­wi (inży­nie­rom).

Inny przy­kład. Popatrzmy na szklan­kę jako opi­sa­ne histo­ryj­ka­mi użyt­kow­ni­ka wymagania:

  • moż­li­wość picia kawy,
  • moż­li­wość prze­cho­wa­nia cukru,
  • moż­li­wość zła­pa­nia muchy na stole,
  • moż­li­wość pod­la­nia wodą kwiatów,
  • .…

Alternatywą dla tego opi­su będzie:

- Szklanka jako pro­jekt: szkla­ny cylin­drycz­ny pojem­nik o śred­ni­cy 8 cm i pojem­no­ści 250 ml”.

Zastanówcie się, któ­ry z powyż­szych opi­sów będzie więk­szym ryzy­kiem, jeże­li wyśle­my go do huty szkła jako zamó­wie­nie na 1000 szt. szkla­nek dla pra­cow­ni­ków… .

P.S.

Czy te moż­li­wo­ści” to przy­pad­ki uży­cia szklan­ki? Nie. Przypadek uży­cia szklan­ki, to co ona fak­tycz­nie robi (usłu­ga sys­te­mu), to przechowanie/magazynowanie sub­stan­cji cie­kłej lub syp­kiej z pew­ny­mi ogra­ni­cze­nia­mi taki­mi jak np. mak­sy­mal­na tem­pe­ra­tu­ra. Te moż­li­wo­ści to co naj­wy­żej histo­ryj­ki użyt­kow­ni­ka… któ­re są może dobrym mate­ria­łem do ana­li­zy ale nie są dobrym wyma­ga­niem. Większość pro­gra­mi­stów, jak dosta­nie tak opi­sa­ne moż­li­wo­ści” jako wyma­ga­nia, to je po pro­tu wprost zako­du­je i odda sys­tem zgod­ny z wyma­ga­nia­mi”… sami oceń­cie jego przy­dat­ność teraz i w przyszłości…

Źródła

Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Börger, E. (2018). Why Programming Must Be Supported by Modeling and How. In T. Margaria & B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Modeling (Vol. 11244, pp. 89 – 110). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 03418-4_6
Bertalanffy, L. van. (2003). General sys­tem the­ory: foun­da­tions, deve­lop­ment, appli­ca­tions (Rev. ed., 14. paper­back print). Braziller.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

Inne artykuły na podobny temat

Komentarze

  1. Sławek S. 28 września 2017 at 12:44

    Jako pro­gra­mi­sta napi­szę jak wyglą­da to z naszej per­spek­ty­wy. Trzymając się Twojej meta­fo­ry zega­ra: ok, klient chce widzieć aktu­al­ny czas; mam zespół, któ­ry spe­cja­li­zu­je się w skła­da­niu try­bi­ków… skła­da­li­śmy z nich już roz­rzut­ni­ki obor­ni­ka, skrzy­nie bie­gów i takie tam; ale nigdy nie skła­da­li­śmy zega­ra mecha­nicz­ne­go, ba nie wie­my, że ist­nie­je takie coś jak zegar mecha­nicz­ny czy jaki­kol­wiek zegar oraz, że ktoś w ogó­le mie­rzy czas i co to jest czas.

    Tak więc prze­skok od pomia­ru cza­su do obra­ca­nia się try­bi­ków ma po dro­dze zbyt wie­le *prze­sko­ków wnio­sko­wa­nia*. Samo wyma­ga­nie jest dla nas nie­wie­le war­te, ew. może słu­żyć jako kry­te­rium odbio­ru ale tutaj moż­na zro­bić jak piszesz wyświe­tla­nie z góry umó­wio­nych obraz­ków” bo nikt nie rozu­mie JAK to dzia­ła, tyl­ko CO ma pokazać. 

    Wiem, że brzmi to jak Monty Python ale tak powsta­je soft:P

    Są oczy­wi­ście zespo­ły, któ­re zna­ją się na zega­rach mecha­nicz­nych lub na cza­so­mier­zach ogól­nie. Ale gene­ral­nie nie­wie­lu znaj­dziesz chęt­nych aby zawę­żyć swo­ją spe­cja­li­za­cję do skła­da­nia try­bi­ków z zega­ry bo w przy­szło­ści może poja­wić się klient od skrzy­ni bie­gów czy cze­goś bar­dziej intrat­ne i było­by nie­ra­cjo­nal­ne aby inwe­sto­wać wysi­łek inte­lek­tu­al­ny (czas i miej­sce” w gło­wie) w pozna­nie natu­ry czasomierzy.

    • Jaroslaw Zelinski 28 września 2017 at 18:12

      Pytanie brzmi: kto ma zapro­jek­to­wać imple­men­ta­cję? Bo ja spo­ty­kam się z:
      – my jako deve­lo­per zro­bi­my po swo­je­mu bo wie­my i mamy pomysły
      – my jako deve­lo­per ocze­ku­je­my deta­licz­ne­go projektu 

      I powiedz mi bo chy­ba mi albo Tobie coś umknę­ło: jeże­li daję opis mecha­ni­zmu jak ten: MECHANIZM to kto powi­nien opra­co­wać imple­men­ta­cję? Albo jaki poziom szcze­gó­łów nale­ży dać deve­lo­pe­ro­wi by nie narzu­cać mu tego co on sam robi dobrze?

    • Jaroslaw Zelinski 28 września 2017 at 18:15

      P.S.
      Ja sto­su­ję taką strategię:
      – daję dość ogól­ny pro­jekt aby jak naj­mniej wią­zać ręce deve­lo­pe­ro­wi (w zasa­dzie logi­ka biznesowa)
      – deve­lo­per pyta o wszyst­ko cze­go nie wie lub woli dostać, a ja do doprecyzowuje
      Jak Ty to widzisz?

  2. Sławek S. 28 września 2017 at 21:28

    To nie jest takie oczy­wi­ste… jeże­li mamy wnio­sko­wa­nie a->b->c->d gdzie po jed­nej stro­nie jest potrze­ba biz­ne­so­wa a po dru­giej roz­wią­za­nie tech­nicz­ne, to teraz zale­ży do któ­re­go pozio­mu może/chce/powinien dojść wykonawca.
    W dome­nach życio­wych” ludzie mie­wa­ją zwy­kle lep­sze intu­icje niż w bar­dziej hermetycznych.

    Wydaje mi się, że pro­blem jest w kie­run­ku prze­ka­zy­wa­nie infor­ma­cji. Klasycznie kie­ru­nek jest PUSH: ana­li­tyk, klient, po,… nie wie cze­go do swo­jej pra­cy potrze­bu­je wyko­naw­ca, nie zna się, nie wie co on wie, więc two­rzy jakieś utwo­ry i artefakty. 

    Często nie­tra­fio­ne, bo to co jest oczy­wi­ste dla odbior­cy arte­fak­tów ana­li­tycz­nych jest dobrze opi­sa­ne a to nie jest nie jest opi­sa­ne (pomi­jam jakoś inte­lek­tu­al­ną tych wytwo­rów oraz zdol­ność do ana­li­tycz­ne­go myśle­nia ich auto­rów, bo tu moż­na by roz­po­cząć festi­wal uża­la­nia się). 

    Lubię DDD za to, że pro­mu­je podejść PULL: wyko­naw­ca (któ­ry sam wie cze­go potrze­bu­je do pra­cy) wycią­ga wie­dzę jakiej potrze­bu­je. Oczywiście nie każ­dy wyko­naw­ca będzie na tyl­ko doświad­czo­ny i świa­do­my aby dobrze to wycią­gnąć ale ilość odpa­dów (waste) w całym pro­ce­sie pro­duk­cji kodzi­ku (bo na koniec dnia to kodzik na ser­we­rze robi lub oszczę­dza pie­nią­dze) jest znikoma.

    • Jaroslaw Zelinski 29 września 2017 at 08:34

      Czy to zna­czy, że gene­ral­nie: jeże­li w peł­ni opi­szę logi­kę biz­ne­so­wą, tę któ­rą ma reali­zo­wać apli­ka­cja, to wyko­naw­ca, mając to CO I JAK MA ROBIĆ logi­ka, ubie­rze to w imple­men­ta­cję i zagwa­ran­tu­je jakość (wyma­ga­nia poza­funk­cjo­nal­ne)? Bo DDD w zasa­dzie tak chy­ba nale­ży rozu­mieć. Mam teraz taki wła­śnie pro­blem w pro­jek­cie: wyko­naw­ca dostał pro­jekt w któ­rym ma dwóch akto­rów: klien­ta fir­my oraz pra­cow­ni­ka fir­my, ich upraw­nie­nia opi­su­ją maszy­ny sta­no­we obiek­tów biz­ne­so­wych i regu­ły (np. jeże­li zamó­wie­nie ma stan do spraw­dze­nia” to dostęp do nie­go ma wyłącz­nie pra­cow­nik dla któ­re­go atry­but stanowisko=sprzedawca. Tu waż­na jest wie­dza, że pra­cow­ni­cy mają czę­sto zmie­nia­ny zakres upraw­nień i mogą one być róż­ne w róż­nych pro­jek­tach. Statusy doku­men­tów zmie­nia­ją się dyna­micz­nie (są dla nich opi­sa­ne maszy­ny sta­no­we). Wykonawca jed­nak for­su­je model imple­men­to­wa­nia skoń­czo­nej ilo­ści kom­bi­na­cji upraw­nień (nazy­wa­ją to rola­mi, było ich nawet kil­ka­dzie­siąt plus kło­pot z zarzą­dza­niem nimi). Tu fak­tycz­nie pro­jek­tu­ję pra­wie wszyst­ko”, tak jak napi­sa­łeś. Czy taki model uwa­żasz za bez­piecz­niej­szy? Bo ja cza­sa­mi mam nadzie­ję, ze archi­tek­tu­rę deta­li opra­cu­je na bazie SOLID itp… deve­lo­per… jed­nak to co piszesz skła­nia mnie do jed­ne­go wnio­sku: deve­lo­per ma dostać logi­kę biz­ne­so­wą tacy i bez potrze­by domy­śla­nia się cze­go­kol­wiek. Czy tak?

    • Jaroslaw Zelinski 29 września 2017 at 08:52

      Podpucha:)
      opisz w kil­ku zda­niach ide­al­ne­go deve­lo­pe­ra i ide­al­ny doku­ment dla niego 🙂

  3. Sławek S. 30 września 2017 at 13:42

    Przypadek, któ­ry opi­su­jesz wyglą­da jak by wyko­naw­ca uznał, że roz­wią­zy­wał już podob­ny pro­blem i naj­lep­sze będzie roz­wią­za­nie, któ­re już zna. Ryzykowna jest teza, że pro­blem jaki kie­dyś roz­wią­zy­wał jest ana­lo­gicz­ny do aktu­al­ne­go. Jeżeli wyko­naw­ca uznał, że tak to praw­do­po­dob­nie na wła­sną rękę doko­nał ana­li­zy – pyta­nie zatem po co byłeś tam potrzeb­ny Ty;)

    Co do ide­al­ne­go deve­lo­epra to w DDD mamy 3 role: eks­pert dzie­dzi­no­wy, mode­larz i faci­li­ta­tor. Modela ma za zada­nie stwo­rzyć model dzie­dzi­ny pro­ble­mu, któ­ry będzie imple­men­to­wal­ny – więc mamy tutaj nie­czę­sto wystę­pu­ją­ce w przy­ro­dzie zja­wi­sko, że ktoś jest w sta­nie roz­ma­wiać z tak zwa­nym biz­ne­sem i jed­no­cze­śnie mieć wyobra­że­nie o roz­wią­za­niu. No ale te kom­pe­ten­cje daje się ćwi­czyć i coraz wię­cej osób na ryn­ku pra­cy może bez pro­ble­mu sta­nąć do roli modelarza.

    • Jaroslaw Zelinski 30 września 2017 at 18:57

      No to uff.. jed­nak nie jestem sam w tej opi­nii… Ja tak­że uwa­żam, że Ryzykowna jest teza, że pro­blem jaki kie­dyś roz­wią­zy­wał jest ana­lo­gicz­ny do aktu­al­ne­go. ” (nie znam przy­pad­ku gdy w dedy­ko­wa­nych pro­jek­tach copy-paste mia­ło by sens). Po dru­gie: jeże­li deve­lo­per dosta­je pro­jekt i mimo to for­su­je swój to zna­czy, że for­su­je swo­je inne roz­wią­za­nie, pyta­nie na jakiej pod­sta­wie sko­ro nie robił ana­li­zy? Jeżeli robił swo­ją mają już moją to pyta­nie po co sko­ro to dodat­ko­wy koszt?

  4. Sławek S. 30 września 2017 at 23:20

    Skoro już tak szcze­rze roz­ma­wia­my, to dodam, że wyko­naw­cy zwy­kle robią swo­ją ana­li­zę ponie­waż nie widzą war­to­ści w arte­fak­tach dostar­czo­nych ana­li­ty­ków. Nie widzą jej bo a) nie rozu­mie­ją lub b) arte­fak­ty te są mier­nej jakości.

    Twój warsz­tat znam ale widzia­łem też tony wytwo­rów innych ana­li­ty­ków” i muszę z przy­kro­ścią zgo­dzić się ze sta­rym indiań­skim przy­sło­wiem, któ­re mówi, że lepiej nie mieć w pro­jek­cie ana­li­ty­ka niż mieć sła­be­go ana­li­ty­ka”. Wykonawcy zaczy­na­ją też instynk­tow­nie odróż­niać oso­by posia­da­ją­ce umysł zdol­ny do ana­li­tycz­ne­go myśle­nia od osób posia­da­ją­cych jedy­nie wpi­sy w nazwie sta­no­wi­ska pra­cy. Tak więc nie może­my się dzi­wić, że wyko­naw­cy doświad­cze­ni życio­wo” z auto­ma­tu przyj­mu­ją posta­wę panie, idź Pan w %$# z tymi doku­men­ta­mi, sami się temu przyj­rzy­my”. Nie chcę oce­niać czy to dobrze czy to źle, po pro­stu mówię jak jest”:)

    • Jaroslaw Zelinski 1 października 2017 at 10:09

      🙂 odpo­wie­dzia­łeś na pytanie …

    • Jaroslaw Zelinski 1 października 2017 at 10:13

      Ale jest też dru­gi pro­blem z nie­któ­ry­mi” deve­lo­pe­ra­mi: tkwią w tech­no­lo­gii i archi­tek­tu­rze (narzę­dziach) z przed 30 nawet lat. Nie sto­su­ją powszech­nie zna­nych wzor­ców pro­jek­to­wych” (nie tyl­ko DDD), upie­ra­ją przy water­fall czy­li naj­pierw zapro­jek­tu­je­my tę jedy­nie słusz­ną rela­cyj­ną bazę danych dla całe­go pro­jek­tu”… i Ci tak­że mówią ?panie, idź Pan w %$# z tymi doku­men­ta­mi, sami się temu przyj­rzy­my?.… ale powo­dy są inne: oni to napi­szą w Borlandzie …

  5. Sławek S. 1 października 2017 at 21:31

    Skoro nie dzia­ła w ich przy­pad­ku mitycz­na nie­wi­dzial­na ręka wol­ne­go ryn­ku” to muszą mieć jakieś walo­ry o jakich nie mamy wie­dzy:) Może w tych pro­jek­tach cho­dzi o coś inne­go niż się nam wydaje…

    • Jaroslaw Zelinski 2 października 2017 at 11:32

      Obserwuję dwa wytłumaczenia:
      – jak zauwa­ży­łeś: inne niż nam się wydaje”,
      – nie potra­fi­my ina­czej ale mimo to ofe­ru­je­my swo­je usługi.

      Ale obser­wu­ję też, że nie­wi­dzial­na ręka wol­ne­go ryn­ku” jak naj­bar­dziej dzia­ła… Zjawisko, o któ­rym tu pisze­my to ostat­nie podry­gi dino­zau­ra, jed­nak zanim dino­zaur pad­nie, ktoś się z nim jesz­cze meczy… Czasami dino­zaur przed śmier­cią zdą­ży np. na szko­le­nie u Ciebie 😉 i unik­nie śmierci …

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.