sobota, dubna 29, 2006

Trocha poctivé demagogie

Takže další kolo. (Než se pustíte do dalšího čtení, doporučuji vaší pozornosti poměrně zajímavý komentář uživatele Q, který jste třeba přehlédli.)

Problém s celou věcí je v tom, že naprostá většina lidí se otázkám, v nichž nějak figuruje Microsoft, nedokáže vyhnout zpolitizování věci, a tak, místo abychom se tu bavili o tom, jak obecně přistupovat k podobnému druhu chyb, kterým se někdy prostě nedá vyhnout, a může se s nimi setkat každý vývojář, řešíme nějaké zbytečné spory ve smyslu katedrála vs bazar, uzavřený vs otevřený, Microsoft vs Samba. Uznávám, mám na tom svůj díl viny, protože jsem si nedokázal odpustit trochu té infantilní jedovatosti (a protože je mi bližší Joel Spolsky než Paul Graham, jsem nutně vychýlený na stranu -- jak to bylo? -- jedné dominantní firmy).

Co mě osobně na celém problému nejvíce zaujalo, je to hledání metody, jak s podobnou chybou naložit. Upřímně řečeno -- nevím. Myslím si, že uživatelé mají právo na zpětnou kompatibilitu, současně ale souhlasím s tím, že zrychlení operací FindFirstFile, FindNextFile je žádoucí, a že po něm korporátní zákaznící Microsoftu touží, a neměli by o něj být připraveni. Myslím, že není správné vyhazovat message box u takových operací jako je vylistování obsahu adresáře, ale přitom chápu, že spamování error logu není řešením pro domácí uživatele, kteří najednou neuvidí své soubory, a kteří nevědí (a nechtějí vědět) nic o tom, co je to nějaká Samba, nebo jakým způsobem Explorer zjistí které soubory jsou ve kterém adresáři. Souhlasím s tím, že nejlepším řešením je opravit instalace vadné Samby, ale nejsem si úplně jistý, jestli je to realizovatelný požadavek u jednoúčelových fileserverů, které firmy (s Linuxem ve ROM/flash paměti) chrlí po desítkách tisíců.

Jak říkám -- nevím jak takovou situaci řešit. Proto mě celý problém zaujal, protože jsem si myslel (a pořád si to myslím), že se dovím, jak se v takové situaci zachovají (ať už se to někomu líbí nebo ne) ti nejlepší programátoři a softwaroví obchodníci na planetě.

Pokud jde o to, jestli samba-team musel nebo nemusel reverzně inženýrovat (ha!) protokoly Microsoftu: Microsoft má svaté právo nechat si své protokoly pro sebe. Nejsem tak kovaný v historii operačních systémů, abych to mohl říct určitě, ale domnívám se, že snahou MSFT v době, kdy "SMB" vznikalo, bylo primárním úkolem zlikvidovat konkurenci ztělesňovanou firmou Novell. Myslím si, že v té době, nikdo nezveřejňoval specifikace svých protokolů, protože se to prostě nedělalo, a jejich utajení a vzájemná nekompatibilita byly považovány za konkurenční výhodu (jako tomu donedávna bylo -- a leckde stále ještě je -- u instant messaging aplikací a protokolů). Od těch blažených devadesátých let se lecos změnilo, a dnes se naopak protokoly zveřejňují a velké firmy se stávají členy konsorcií, kde se protokoly a formáty domlouvají ke všeobecné nespokojenosti. Je to jako s programováním -- od rigidního stylu vše bude naplánováno, pak implementováno, nakonec otestováno, a co si zákazník nevymyslí hned zkraje, to mít nebude se postupně přechází k extrémnímu programování, které říká neplánujte nic, napište pár testů a uvidíte co z toho vzejde.

Stejně jako se za těch deset patnáct let změnila představa ideálního programovacího stylu, změnila se i představa ideálního přístupu k protokolům. Dříve nepředstavitelné zveřejňování obchodních tajemství se dnes stalo všeobecným standardem, a firmy sázejí víc na to, že nabídnou synergické řešení všech problémů, které bude zákazníky demotivovat od nákupu produktů konkurence (pravým důvodem proč používat Outlook není příjem pošty, ale propojení s Exchangem a zbytkem balíku Microsoft Office, důvodem proč nepoužívat OpenOffice.org není těch 1397 funkcí, které má Excel navíc, ale absence návaznosti na Exchange a další produkty Microsoftu).

Abych to shrnul: Vývojáři Samby v diskusi pod Chenovými příspěvky sami přiznali, že chyba nevznikla proto, že by neznali protokoly Microsoftu (který je prý už docela obstojně dokumentuje a s týmem Samby snad i spolupracuje), ale proto, že prostě udělali normální stupidní chybu (nějaký ten zapomenutý case ve příkazu switch()). Údajně zabrala oprava chyby (včetně testování) asi tři minuty. (Což mi připomíná, že, pokud jsem to správně pochopil, problém není v tom, že by listování adresáře nevyhodilo chybu. Problém je v tom, že ji vyhodí i když nemá!)

Blog Old New Thing se problémem zpětné kompatibility zabývá poměrně často. I proto ho čtu -- protože mi stále připomíná, že opravit chybu někdy nestačí...

1 komentář:

BVer řekl(a)...

Konvergence

Coby černý v druhém tahu nabízím remízu, ono by to totiž už dál nebylo moc zajímavé. Jak bylo už víckrát poznamenáno, jde o politickou otázku. Těžko by sis (bychom si, my všichni) kauzy všiml(i), kdyby zainteresované strany byly jiné. Takto ale je to velmi ostře nahozeno a málokdo umí zůstat skutečně nad věcí a držet se podstaty problému.

O ryze technických podrobnostech se vlastně diskuse nedá moc dobře vést. Kdybych měl detailní informace, které jsou k dispozici pouze vývojářům Visty, kdybych znal obchodní priority coby rámec svého rozhodování, kdybych věděl, kolik času je na řešení daného problému k dispozici, tak bych se nejspíš uměl kvalifikovaně rozhodnout a své závěry dovedl podložit argumenty. Leč nemám nic z výše uvedeného a domnívám se, že ostatních 99% celosvětově diskutujících je na tom podobně. :-)

Ještě tři poznámky:
1. Otevřenost či uzavřenost síťových protokolů zřejmě není v kauze podstatná -- ve svém komentáři jsem se o tom zmínil okrajově a nebylo by dobré nějak se opírat o to, zda je třeba něco zpětně inženýrovat či nikoliv.

2. Extrémní programování neříká přímo "neplánujte", ale spíš něco jako "plánujte pro momentální úkoly a nedělejte zbytečné předpoklady o budoucích požadavcích, místo toho si zachovejte pružnost a lehkost vývoje", viz tzv. iterační plánování a ostatní principy XP. Není to jen o testech.

3. Paul Graham a Joel Spolsky: Oba pánové jsou výjimeční v tom, co dělají, i v tom, co a jak píší, a má smysl je číst oba. Myslím, že toto hodnocení je výstižné: "I'd rather have Paul if I need a prototype the next week that will develop into the next big thing, but i'd rather have Joel for a product whose needs are known at the outset and will need maintenance by unknown programmers in the future. (Eric B)". Osobně mi více imponuje originální přístup PG, zatímco v JS vidím spíše pragmatického managera.

Nicméně -- mám za to, jIRI, že si v podstatných věcech rozumíme.

Je mi jen lehce líto fundamentalistů v obou táborech.
Neustálé zaklínání se "běžným uživatelem" -- ať už tento figuruje jako modla, které je třeba obětovat technickou kvalitu a vůbec i vše ostatní, nebo naopak představuje plivátko ve spodních patrech věže, s níž bohorovně shlížejí povýšení rooti -- nesvědčí o ničem jiném než o ubohém mentálním nevolnictví. A je jedno, na čím pozemku je toto provozováno.