Vlákno názorů k článku Tři programátoři, jeden počítač, dvanáct úkolů aneb světové finále ICPC 2012 od Honza - Zajímavý článek o zajímavé události. Akorát kluci ještě...

Zajímavý článek o zajímavé události. Akorát kluci ještě netuší, že v komerční praxi 90% z nich bude řešit z 99% algoritmicky nezajímavé (a přesto často velmi netriviální) úlohy typu jak se neztratit ve velkém projektu, jak zvládnout nějakou novou a nedokumentovanou knihovnu, jak pracovat s kolegou, co programuje jiným stylem, jak opravit rozbitý build s chybou v kolegově kódu po commitu jiného kolegy, když oba jsou na dovolené, jak zvládnout dobře práci s gitem nebo svn, jak najít padačku, když z nějakého důvodu nejde program krokovat, jak řídit tým neschopných programátorů...

Přesně tak :-D

Myslím, že to ve skutečnosti není zas až takový rozdíl - kromě posledního bodu budou ve všech jmenovaných případech ve výhodě díky svým hard skills oproti těm, kteří "hrubou silou" tolik neoplývají. Matematická inteligence a intuice, schopnost rychle se zorientovat v hromadě bordelu, dostat pěkný nápad tehdy, když ostatním už nápady došly, to je přesně to, co z nich v praxi udělá elitu ve srovnání se všemi těmi "highly motivated team player".

Ale jo, ja jsem nerikal, ze schopnost vyresit rychle algoritmicky problem je v praxi na houby. Minimalne je to dobre procvicovani programatorske intelignece. Clovek ktery rychle navrhne nejaky algoritmus se nejspis taky napr. rychle vyzna v nejakem cizim a neprehlednem kodu.

Alebo ako je ten bordel schopny upratat.

Tak, tak, v mládí jsme se tahali po matematických a programovacích soutěžích a v praxi děláme něco naprosto něco jiného, většinou zázraky zadarmo na počkání. 90 % kódu je dneska naprasena stylem hlavně že to funguje, doslova se to plácá z ho***, nejpoužívanější výpočetní metoda je hrubá síla, optimalizace se dělá zakoupením nabušenějšího hardware. Prakticky už všude se používají skriptovací zmetky PHP, Java, Perl, Python ale to není zdaleka všechno, vynořují se nová pekla jako ORM. Za této situace je soutěž naprosto odtržená od reality, troufám si tvrdit, že 5 a méně osob ze soutěže bude dělat něco jiného než jsem popsal.

Pro velké firemní sponzory je to ideální způsob, jak se dostat k těm nejlepším z nejlepších a přetáhnout je k sobě.

To jistě ano, jenže v tak velkých firmách, které si mohou dovolit spozoring, je paradoxně maras v IT tak silně rozšířený, že málokterý génius jim tam vydrží :-)

Já osobně za největší rozdíl považuji kvalitu zadání. To ostatní je důsledek pragmatismu a neshledávám v tom žádný větší problém. Ale ta zadání. Na těhle soutěžích jsou zadání velmi kvalitní a jeden by nabyl dojmu, že to tak bude i v praxi. A pak na vás mžourá pán s brejličkama a vlastně ani neví, jestli chce aby každá paleta měla vlastní záznam, nebo ne. On potřebuje, aby záznam měla, protože chce vidět její číslo. Ale zároveň se mu nechce vyplňovat 33 záznamů kdykoliv přijede kontejner. Po týdnech se doberete k tomu, že bude jeden záznam pro kontejner a budou tam dvě políčka - id palety od a id palety do. Takže zadá, že přijely palety 12345 až 12362. No a po pár dnech je tu pán zase, že mu nesedí report, protože zjistil, že ačkoliv si byl skálopevně jist, že čísla palet jsou rostoucí sekvence, tak ono občas nějaká zůstane v Amsterdamu, takže to vlastně číselná řada není. Tak mu doděláte detail, kam může palety vypsat, aniž by každá dělala skladovou transakci. A on za pár týdnů přijde s tím, že je to moc pracné a že to vlastně nepotřebujete. Tak to přepnete na nepovinné. A on je za pár týdnů zpátky, že to sice u nich nikdo nepotřebuje, ale customer services dělají nějaký report pro zákazníka, který to vidět občas chce (jen když je nějaký problém, který potřebují dohledat). A já tu pak stojím a pláču, že chci zákazníka, který ví co chce!

Souhlas. Často ani kvalitní objektový návrh/přístup nepomůže. Pak máte 2 možnosti (nepočítám odstoupení od zakázky). Refaktorovat a "při/přebastlit". Často se volí ono bastení (málo času, otrávenost z recidivy změn, nařízení z vrchu, není to tak hrozné, atd...) s tím, že doufáte, že je to konečná. Jak to dopadá, nemusím rozepisovat... :-)

Myslím si, že problém je v tvém očekávání. Zkus se vžít do role toho klienta. On nedokáže na začátku naspecifikovat do detailu všechny požadavky, málokdo umí do detailu promýšlet zatím neexistující věci. Neumí odhadnout, jak se mu s tím bude dělat, když si to jenom představuje. Pro něj je daleko snazší doupřesňovat nějaký prototyp, ladit si to pro své potřeby postupně. Že je to nepřijatelné pro externího smluvního vývojáře? Tomu samozřejmě rozumím, ale pak by měli jít spíš na řadu malých kontraktů, postupně. A nebo na hodinovku, pokud ti bude věřit.

Není to jednoduchý :-)

Přesně tak - řešitelné to je, opravdu to není jednoduché a škola vás na to nepřipraví. A jako vývojáři by mi to vlastně mělo vyhovovat, protože dostávám zaplaceno znovu a znovu. Jenže zaprvé je mi to líto, a zadruhé to časem omrzí.

Ale zatím jsme to vždy vyřešili, a to i ke spokojenosti zákazníka. Jen jak říkám - 80% času trávíme činnostmi, o jejichž existenci nám ve škole ani neřekli, natož aby nás na ně teoreticky připravili. UML, BPML apod. je sice fajn, ale tomu zákazníci nerozumí. To jsou nákupčí, prodejci a výrobní manažeři.

myslim, ze to je problem i u nas, ze zakaznik sepise co chce a az nakonci
si to prekontroluje a takhle to jde cyklicky donekonecna.

lepsi by bylo, kdyby nekdo od zakaznika vstoupil do celeho vyvojoveho
procesu a upravy/zmeny by se daly delat rychleji/opera­tivneji bez nasledneho
prekopavani.

Naše strategie je dělat systémy modulární a konfigurovatelné. Takže obvykle nepřeprogramo­váváme, jen schováváme sloupečky a volby v menu. Někdy je ale potřeba učinit zásadní rozhodnutí, která mají vliv buď na výkon systému, nebo na dostupná data. A to je kámen úrazu a já neznám žádnou účinnou metodu komunikace. Ono obecně zákazníci chtějí mít maximum dostupných dat, ale bez nutnosti data pořizovat. A nemají odvahu ke kompromisu a musí se jim pomáhat. Jenže to aby měl člověk vystudovanou psychologii a rétoriku, nikoliv IT.

Aktuální perlička je sledování zásobníků drobného materiálu pro výrobu. Prostě se tam položí paleta a lidé z výroby si berou materiál jak potřebují. Zákazník chce vidět v systému kolik materiálu na paletě zbývá. Jenže z té palety si bere každý tolik co potřebuje, syslí si to na linkách a samozřejmě se materiál průběžně spotřebovává. Jenže jak zjistit, kolik tam na té paletě zbývá, když nikdo nikdy nikam nehlásí, kolik si bere? A sjet to podle plánované spotřeby říká, že je na paletě tolik, že se to tam ani nevejde (protože ono to ve skutečnosti je na linkách a ve skříních mistrů z výroby). Takže přesvědčit zákazníka, že buď někdo musí hlásit, kolik materiálu se odebralo, nebo prostě akceptovat, že to systém neví. S tímhle mi refactoring ani demo verze nepomůžou. Teď se na ně chystá kolega, co má zkušenosti s kanbanovými systémy a plánujeme jim navrhnout zásadní změnu procesu (proč je na linkách neřízené množství a proč si mistři musí zamykat "pojistnou zásobu" do skříněk?) Zákazník nakonec bude spokojen, já se jen snažím říci, že tohle mě ve škole neučili. A to jsem studoval softwareové inženýrství :-)

Zadávání je zoufalství skoro vždy. Před několika lety potřebovala firma, ve které jsem pracoval, informační systém. Společně ještě s jedním kolegou jsme měli být "styčnými důstojníky" s vybranou firmou, která systém vytvoří. Oba jsme měli základní představu, kterou jsme chtěli upřesnit na základě detailní analýzy aktuálního stavu a potřeb ze strany dané firmy. Dalo by se říct, že to byla oboustranně ideální dohoda - pár lidí od nich bylo tři dny v týdnu u nás ve firmě, sledovali kompletní provoz firmy, vyptávali se lidí (všichni byli instruováni a kupodivu spolupracovali). Kolega a já jsme průběžně kontrolovali zjištěné, dovysvětlovali, upřesňovali a po dvou měsících vznikla velmi dobrá analýza toho, co skutečně potřebujeme.

Ve chvíli, kdy to dostal na stůl šéf, tak se strhl neuvěřitelný a nepochopitelný brajgl. Šéf se vytočil, za dva měsíce se akorát dozvěděl, co ve firmě děláme, a že to už dávno ví. Nenechal si nikým vysvětlit, že tohle bylo cílem první analýzy, abychom nedostali nepoužitelný systém. Nakonec tu firmu doslova vyrazil, zaplatil odstupné a projekt zadal někomu úplně jinému, který slíbil dodat první verzi systému do měsíce.

A dopadlo to pochopitelně tak, jak se dalo čekat - přestože dostali navíc celou analýzu, dodali nepopsatelnou hrůzu, která nefungovala a ignorovala téměř vše, co bylo v analýze (ergo neřešila naše potřeby). Více než rok se ji snažili spatlat do provozuschopného stavu a nakonec se projekt ukončil. Pochopitelně to vyšlo mnohem dráž, než kdyby to dodělala první firma. No, a nemluvě o tom, že kolega a já jsme byli označeni za ty, kteří za to mohou.

Vas problem dobre znam a myslim si ze prvni a nejvetsi chyba je, ze od zakaznika vubec neco ocekavate, krome uhrady dohodnute maximalni ceny... K nasledujicimu jsem dosel po letech dodavek IT/Automatizace do prumyslu:

1. Pokud jsem placen za navrh a dodavku nejakeho systemu jako celku, reseni vzdy navrhuji "pro sebe", tak jak by melo logicky a racionalne prakticky vypadat, aby se mi s danym systemem dobre pracovalo.

2. Nejake zadani od zakaznika je mi ukradene, vzdy musim JA SAM pochopit, co vsechno to ma delat, co se tim resi, k cemu to slouzi, jak to pracovnici v praxi pouzivaji, jake vystupy chteji atd. Podle toho si navrhnu sve reseni a pri znalosti problemu extrapoluji budouci mozny rozvoj a budouci pozadavky.

3. Datovy i aplikacni model od pocatku predpoklada maximalni vetveni a variabilitu, tak aby do nej s minimem prace a zmen v budoucnu zapadl i pozadavek na to, ze kazdy sroubek muze mit sadu individualnich parametru.

To ze vystupem vyse uvedenho je implementace cca 20% rozsahu navrzene funkcionality, jen te ktera je prakticky, aktualne potrebna a zaplacena, nic nemeni na nutnosti takto uvazovat, protoze jinak bych se z naslednych pozadavku na zmeny, upravy a rozsireni zblaznil. Takto jen pred uzivatelem schovavam nebo zpristupnuji datove polozky v GUI, pripadne dodelavam drobnou funkcionalitu a pokud me opravdu svymi pozadavky na zmeny uz nasere, tak mu sdelim ze toto je uz mimo ramec puvodniho objednaneho navrhu, je nutny zasadni redesign, nauctuji 50% ceny systemu... a pak pridam tech par polozek do sveho megalomansky a paranoidne navrzeneho modelu...

Souhlas :)
Málokdo to ale dovede pochopit, natož ocenit.

Je možné, že to je odtržené od reality, ale škola nemá učit studenty co mají dělat v praxi (na to stačí školení). Škola má učit lidi myslet a dát jim teoretické základy. Podobné soutěže mají smysl v tom, že to lidi baví. Asi těžko se někdo přihlásí do soutěže refaktorizace starého kódu nebo oprav testů a dokumentace kódu (proč by to dělali na soutěži, když to můžou dělat za peníze v nějaké firmě). Bohužel je dneska trend dělat z VŠ školící střediska, protože "do školy chodíme, abychom měli vyšší plat" a ne abychom se něco naučili.

Škola až do Ing./Mgr. je oficiálně příprava na budoucí povolání, to jen mimo soutěž.
Soutěže na optimalizaci cizího kódu jistěže existují, ale nemají takovou publicitu.

Na druhou stranu budouci povolani spravneho matfyzaka je, ze zustane na skole a ze se bude hrabat v teorii :-)