Spolehlivost programátorů aneb slovo dělá muže(?)

Reaguji na Pavla Krátkého:
Snažím se mít stabilní klienty se zajímavými tvůrčími projekty, kterým časový skluz nepůsobí existenční problémy. Termíny slibuji velmi nerad, nestíhám je v podstatě nikdy, protože vylepšuji zadání a kvůli vylepšeným (komplikovanějším a zajímavějším) cílům pak nemám čas na stihnutí jiných termínů :-)

„Máte třeba k dispozici nějaké "kamarády", kteří by Vás mohli zastoupit?“
Pokouším se mít, ale často jsou všichni zaneprázdnění.

Pavel Krátký:
Podle mě to nějaký zásadní „flejm“ či „problém“ není… Nebo ho tam nevidím.

Termín a co se stane při jeho nesplnění je přece věc dohody o té zakázce. Některému klientovi na termínech moc nezáleží, jiný je striktně vyžaduje.

„Máte třeba k dispozici nějaké "kamarády", kteří by Vás mohli zastoupit?“
Tak v situaci, kdy tři dny před termínem jsou na projektu ještě dva dny práce a já je nemůžu odpracovat, si neumím moc představit shánět nějakého kamaráda.
Navíc když ten projekt předtím neviděl, za poslední tři dny na něm stejně nejspíš dva dny práce neodpracuje.

U projektu, na kterém už od začátku dělá tým lidí, je to samozřejmě jinak, tam často není problém. (Možná přesněji řečeno v tom není jiný problém, než že pak někdo pracuje 14 hodin denně a podobně, ale s takovou možností se asi v závěru projektu tak nějak počítá :) )

Pavel Krátký:

No a jak je teda řešíme? U dražších zakázek a nových klientů smluvně – včetně záloh, výše slevy při nedodržení termínu a výše penále při zpoždění platby.

Pavel Krátký:
„ovšem do hry vstupuje taky ještě fakt(or) "a new client, would he pay me?"“
Ako zvykneš riešiť vec platby bez toho, aby klienta akokoľvek urazilo, že si myslíš, že nezaplatí?

„Jak řešíte termíny?“
Väčšinou som schopný zhruba čas odhadnúť a ak sa jedná o niečo väčšie, pridám si aspoň deň ak by nastali komplikácie. Na nejakom globálnejšom projekte tvorby celého webu som ešte nepracoval. Spravidla tam je vyžadované viac než viem.

Chamurappi:
„protože vylepšuji zadání a kvůli vylepšeným (komplikovanějším a zajímavějším) cílům pak nemám čas na stihnutí jiných termínů :-)“
Ako zvykne druhá strana reagovať na takýto komfort? Posledne, keď som niečo prerábal, chcel som iba, aby všetko čo som robil ja fungovalo. Zvyšok bol otrasný, ale nemal som snahu skúšať to prerábať. Platia ti zákazníci za to, že prirobíš ešte niečo nové? Prípadne, ako sa s nimi dohaduješ? Dávaš im nejaké argumenty, prečo je dobré dať si niečo prerobiť alebo proste vystúpiš s tým, že si tam prirobil ešte pár ďalších vecí a necháš zákazníka oceniť tvoju iniciatívu?

Inak, chcel by som sa vrámci tohoto vlákna opýtať, ako riešite samotnú časť platby. Ja zvyknem zopakovať všetky práce, ktoré som vykonal, ak treba poslať nejaké súbory, pošlem aspoň časť z nich s tým, že po prevedení platby na účet dodám zvyšok a podrobné inštrukcie na uloženie. Prípadne, ak mi dá zákazník prístup na FTP, viem, že on mi dôveruje a tak pociťujem aj ja akúsi dôveru k tomu, že všetko prebehne ako má. V takom prípade zákazník tiež vidí všetky zmeny a môže pripomienkovať všetko s čím nie je spokojný.

Celkovo nerád prijímam platbu ak si nie som istý, či som všetko spravil podľa predstáv druhej strany.

Pavel Krátký:
„To je taky zásadní část tématu (celý odstavec).“
Ďakujem za názor, otázku som ale smeroval na Chamurappiho. Takisto sme sa asi zle pochopili v mojej vete: „Zvyšok bol otrasný, ale nemal som snahu skúšať to prerábať.“. Ja som to neprerobil. Obdivoval som Chamurappiho, že urobí prácu navyše a zaujímalo ma, ako to potom pokračuje. Pravda nemohol som sa na ten hnusný kód pozerať, ale zabralo by mi to dni práce všetko prerobiť. Keby mi za to niekto ponúkol odmenu, možno by som o tom uvažoval inak, ale keďže sám klient na to kašľal a záležalo mu iba na tom, aby to navonok dobre vyzeralo, prečo by som ja mal dbať?

Tak ona je otázka, co si představit pod vylepšení zadání.

„Hnusný kód“ zpravidla na funkci nemá moc vliv, takže někdo jiný než programátor jeho zkrášlení neocení. Zatímco když v zadání bude „kreslit kolečka“ a člověk umožní kromě koleček kreslit i trojúhelníčky, tak to může být pro zadavatele zajímavé.

Jinak k původní otázce: Hrozně záleží na vztahu mezi programátorem a zadavatelem; kdo koho víc potřebuje:

1) U relativně nekvalifikované činnosti může zadavatel programátora honit, protože není zase takový problém najít za pár hodin náhradu.

2) U složitějších věcí je nabídka programátorů značně omezená, navíc se programátor v průběhu projektu stává obtížně nahraditelným (nabídka programátorů ochotných se hrabat v cizím kódu je ještě menší, navíc to zabere další čas), takže se ho zadavatel spíš snaží neztratit, nehoní ho termíny, platí mu víc, než požadoval, a podobně. Zkrátka ten pracovní trh funguje jaksi opačně, než bývá zvykem.

Tomáš123:
„Ako zvykne druhá strana reagovať na takýto komfort? Posledne, keď som niečo prerábal, chcel som iba, aby všetko čo som robil ja fungovalo. Zvyšok bol otrasný, ale nemal som snahu skúšať to prerábať.“

Str4wberry:
„‚Hnusný kód‘ zpravidla na funkci nemá moc vliv, takže někdo jiný než programátor jeho zkrášlení neocení. Zatímco když v zadání bude ‚kreslit kolečka‘ a člověk umožní kromě koleček kreslit i trojúhelníčky, tak to může být pro zadavatele zajímavé.“

Ale pozor, četl jsem například teď nějaké knihy o testování a tam bylo napsané, že situace „software má funkčnost, která ve specifikaci není“ by měla být nahlášená jako chyba!
Čímž se naznačuje, že je špatně do aplikace svévolně přidávat funkčnost.
Podle mě ani není správné aplikaci svévolně vylepšovat, pokud to nesouvisí s tím, co na ní mám dělat.

Vývoj není jen programování. Změna, která není součástí žádného požadavku, případně dokonce nikdo neví, že se programátor v té části aplikace hrabal, se těžko může otestovat.
Takhle programátor může do aplikace zanést chyby, které se objeví až v ostrém provozu.

Samozřejmě u malých projektů to není tak dramatické.

A samozřejmě když se ta změna protáhne celým „kolečkem“, tj. nechá odsouhlasit jako změna zadání, není problém.


„Inak, chcel by som sa vrámci tohoto vlákna opýtať, ako riešite samotnú časť platby.“
Tak pokud si od klienta necháte podepsat objednávku a potvrdit zadání, není pro něj tak snadné to pak nezaplatit a dělat mrtvého brouka.

Jinak že mi někdo nezaplatil se mi stalo jen u nějakých drobností, kde prostě dotyčného dám na blacklist a dál to neřeším.

Teď jsem dokonce v opačné situaci, kdy dlužím já peníze klientovi a když mu to čas od času připomenu, řekne, že si u mě určitě nějakou práci ještě objedná a tím se to vyrovná :-)

Pavel Krátký:
> Vzpomněl jsem si právě na rozhovor s jedním potencionálním klientem, kdysi:
> Klient Potřebuju stránky, nutně, hned!
> Já Ok, pro koho ty stránky budou, co budou umět...?
> Klient, 10 vteřin ticha... Hmm, tak nic.

Z toho by podle mě stejně bylo lepší vycouvat, protože obvykle dobrat se k tomu, co vlastně klient chce (de facto analýza problému) trvá hrozně dlouho, přičemž tihle klienti většinou nepočítají s tím, že by za to měli platit.
Tj. ve finále to je tři dny snahy se dobrat k nějakému rozumnému zadání, plus dva dny programování. Přičemž klient očekává, že zaplatí ty dva dny programování.

Nemluvě o případě, kdy po pracné analýze přijde s tím, že takhle to nechtěl.
A nejlepší hláška: No, tu analýzu jsem sice podepsal, ale to jsme si o tom jen tak povídali, já netušil, že to podle toho skutečně uděláte! :-)

„‚ještě dva dny práce a já je nemůžu odpracovat‘ To je právě ono! Jak to řešíš, když den má jenom 24h?“

Tak to je pochopitelně už těžko řešitelné.
Respektive:
Jedna věc je samozřejmě to ideálně nenechávat až na poslední chvíli a druhá věc udělat důležité věci jako první.
Čekal bych, že tři dny před koncem vývoje bude hotového už něco použitelného a problém bude např. že tam nejsou zanesené poslední změny nebo chybí nějaké kosmetické věci.
Takže klient dostane alespoň něco funkčního, byť ne úplně hotového.

Ale v mém případě jsou vesměs klienti laxnější, než já. A klient, kterého tři měsíce upomínám o dodání podkladů, nemá moc silnou pozici ke stěžování si na délku vývoje :-)

Reakce na Jokera:
„situace ‚software má funkčnost, která ve specifikaci není‘ by měla být nahlášená jako chyba!“

Při práci ve větším týmu, kdy jsou činnosti rozděleny mezi více lidí, to má dobrý důvod. Ale myslím, že se tady bavíme spíš o situaci, kdy analysu, návrh, programování i testování dělá tentýž člověk (nebo nikdo).

Potom může nastat v zásadě jen problém, že to zadavatel nebude chtít zaplatit nebo se mu daná funkce nebude líbit a bude se muset odebrat.

Pavel Krátký:
„Díky! Jinak, jsem jednočlenný tým, už x-krát klient přerušil komunikaci, když jsem mu poslal návrh smlouvy (kde je odstaveček o záloze). Aneb, jak je důležité míti Obchoďáka :)“
Nejde o zálohu, ta není nutná, jde o smlouvu. Prostě o to jasně určit kdo, co všechno, za kolik a do kdy udělá a co se stane když neudělá. Zabraňuje to situacím typu "Ale vy jste říkal … a my jsme mysleli …".

„Díky! Nemohl bych to vidět (pk11 na centrum.cz)? Čistě ze zvědavosti...“
Něco ve smyslu, že jsi kecal ukecaný bez schopnosti rozlišit co je v tématu důležité a co už plácání játrama. Snad to stihneš, než juriad zakročí :)

Reaguji na Tomáše123:
„Dávaš im nejaké argumenty, prečo je dobré dať si niečo prerobiť alebo proste vystúpiš s tým, že si tam prirobil ešte pár ďalších vecí a necháš zákazníka oceniť tvoju iniciatívu?“
To je různé, záleží na okolnostech (= kdy mě zlepšení napadne, jestli je zákazník zrovna vzhůru, jak moc se obávám nesouhlasu, zda ho chci příjemně překvapit atd.).
Ještě jsem měl podotknout, že zdaleka ne vždy ta vlastní iniciativa končí něčím pracnějším. Občas detailnějším rozborem (který nebyl žádán a který také zabírá čas) dospěji k tomu, že bude lepší, když požadovaná součinnost nevznikne, nebo když se odloží do vzdálenějšího budoucna, kdy do projektu lépe zapadne.

Poslední dobou se snažím nepracovat na projektech, ke kterým nemám žádný bližší vztah. Zůstávají mi dlouhodobé (mnohaměsíční) spolupráce, kde funguji do značné míry i jako konzultant, nikoliv jen jako programátor. Jsem si vědom, že moje situace není moc přenositelná.
Pokud se pustím do něčeho menšího, je to menší o několik řádů, třeba na pár hodin (typicky opravit někomu web, aby fungoval ve všech prohlížečích) a tam termín dodržím.

Jo a ještě bych chtěl vyjasnit, že předělávám spíš zadání, ne cizí hnusné kódy. Částečně i díky zkušenostem z diskuse se umím celkem obstojně zorientovat v cizím chaosu a pokud klient chce přistavět mezipatro do svého domečku z karet a bláta, obejdu se obvykle bez velkého bourání. I kdybych všechno přepsal, stejně se stanu součástí tradičního koloběhu programátorské kritiky předchůdců:



Reaguji na Martina2:
„Snad to stihneš, než juriad zakročí :)“
Také to zatím najde v kontejneru. Popichovat můžeš, ale stále platí pravidlo, že bys měl s ostatními jednat slušně. A moderátor na tebe přivolaný stojí před jinou volbou než mlčenlivý přihlížející vědoucí váhající :-)

Pavel Krátký:
„budu trvat na svém, že jsou případy, kdy hlavní důvod úprav kódu, které jsem po někom zdědil, mi v budoucnu ušetřily práci.“

Proto se taky obvykle dělají :-)
Na druhé straně mám i případy, kdy taková i celkem nevinná „vedlejší úprava“ zanesla do kódu nepříjemnou chybu, nebo dokonce odstartovala celý řetěz dalších problémů.

Čímž samozřejmě nechci zatracovat refaktoring, refaktoring je potřeba. Spíš je možná riziko u těch drobných změn ke snižování laťky standardů. Ve smyslu, že „hlavní požadavek“ je celkem solidně zanalyzovaný, pak implementovaný a otestovaný… A někdy na konci testů programátora napadne nějaká „drobnost“, tak to tam střelí ještě před nasazením.

Ještě k tomu přepisování cizího kódu, zvážil bych, nakolik je to potřeba a nakolik je to spíš NIH syndrom.
Četl jsem článek o tom, že zahodit původní kód a začít znovu od začátku je principiálně špatně a nikdy by se to nemělo dělat.
Že refaktoring je správně, ale jako vylepšování, ne původní kód zahodit a začít znovu.
Důvodem je, že pokud ten stávající kód nějak funguje, během jeho fungování se nejspíš vynořila a opravila hromada chyb, během provozu se objevily překážky a problémy a implementovalo se jejich řešení.
Takže zahozením starého kódu se ta „zkušenost“ ztratí a nový kód nejspíš znovu bude obsahovat velkou část z chyb, které ten původní už opravil.

Podotýkám ale, že autor asi neviděl některé kódy, které jsem viděl já :-)
Podle mě existují případy, kdy původní kód je tak strašný a sám o sobě generuje tolik problémů, že se přesto vyplatí ho zahodit a začít znovu.
Abych se třeba některých návštěvníků nedotkl, tím nemyslím kódy tady na diskusi, když se to někdo učí, je v pořádku, že to neudělá hned správně. Na druhé straně, pokud si někdo říká odborník a nechá si za to platit, dodání kódu otřesné kvality je těžko omluvitelné.

„On právě tím "Hmm, tak nic." z toho v tu chvíli vycouval.“
To jsem pochopil.
Já měl na mysli, že by asi bylo lepší z toho vycouvat i v pozici toho programátora (kdyby to neudělal klient).

Str4wberry:
„Potom může nastat v zásadě jen problém, že to zadavatel nebude chtít zaplatit nebo se mu daná funkce nebude líbit a bude se muset odebrat.“
Tak.
Asi jen výjimečně bude zadavatel takový šmejd, že počítá od začátku s tím, že tu práci nezaplatí.
Obvykle je problém v tom, že dodaný produkt se liší od představy zadavatele, jak to mělo vypadat.
Právě k tomu je dobrá ta analýza a právě proto mi připadá riskantní brát práci, u které mám problém zjistit, co klient vlastně chce.

„A někdy na konci testů programátora napadne nějaká ‚drobnost‘, tak to tam střelí ještě před nasazením.“
Na omezení (nebo aspoň lepší promyšlení) těchto živelných úprav je dobré používat verzovací systém. Tam se neschová ani drobnost, takže vývojář musí promyslet, jestli ta úprava stojí za to, aby pro ni vytvářel commit. Když se rozhodne, že ano, udělá to pořádně (protože nechce mít v historii bordel). Před commitem si ještě projde, co vlastně odesílá, takže takový vlastní code review (teď nemluvím o týmech, kde dělá code review někdo jiný). Tuhle změnu pak uvidí kolegové, případně i testeři, takže se na to mohou dodatečně podívat a když už by se přecejen něco rozbilo, lze v historii hledat příčinu a vzít ji zpět/opravit.