NIH by SUN

This week I have written a blog entry about Not Invented Here syndrome at Sun. It was reaction on presentation of Kohsuke Kawaguchi on CZJUG meeting. There were some comments under the entry that it would be more fair to write it in English so Kohsuke and others can react. So I am writing it again. It is not exact translation, this entry is much shorter and less bitter.

So what is the problem? Kohsuke was showing new Glassfish v3 server. The idea is great, they are trying to create a modular server that will be able to start really fast, initialize its parts on demand, will be able to run RoR, PHP etc. Moreover, they are using Maven in really interesting way. But during the whole presentation I was thinking that I see a nice example of NIH syndrome. They needed module system. So they wrote one. They needed IoC container. So they wrote one. It does not matter that there already are dozens of IoC containers. They just wrote their own. What is the reason for it? I am quite sure that it is not stupidity or lack of experience. They have to be quite clever and experienced to be able to write an application server. I think that there is politics behind it. Although Glassfish is an open source project, it is primarily project owned by Sun. And Sun can not use some existing IoC container that dos not even have its own JSR. Imagine that. Sun using Spring (or Guice or whatever) internally. It would be unbelievable. The same is with the module system. Sun just can not use OSGi, they are at war with them. (Or at least it seems like they are). It does not matter that OSGi is proven solution. They just have to create their own. Why? Because of NIH.

NIH podle Sunu

V pondělí jsem se zúčastnil CZJUGu. Obě přednášky byly zajímavé, ale při druhé, týkající se nového Glassfishe, se mi do mysli neodbytně vkrádala zkratka NIH. Pro ty, kteří nevědí co to NIH je doporučuji pěkný Dagiho článek.

Zkratka NIH znamená Not Invented Here, česky by se dalo snad říci „nevymyšleno u nás“. Používá se, když někdo vymýšlí něco co už bylo dávno vymyšleno, jenom proto, že to nevymyslel on. Přesně v tomto duchu se nesla prezentace Glassfishe. Potřebovali modulární systém, tak si ho naimplementovali. Potřebovali IoC kontejner, tak si ho naimplementovali. Potřebovali jezdit do práce, tak si sestrojili něco na čtyřech kolech s motorem. (I když, teď si nejsem jistý, jestli to poslední zmiňovali). Vůbec nevadí, že už existují funkční vyzkoušené modulární systémy. Vůbec nevadí, že existuje hromada IoC frameworků. Napíšeme si to znovu a mnohem lépe.

Domnívám se, že v tomto případě nešlo o hloupost nebo neznalost. Myslím, že za tím stojí politika. Asi si myslí, že by vypadalo hloupě, kdyby používali Spring. Co by tomu řekli lidi. Vynálezci EJB, autoři přehršle skvělých a bezchybných JSR používají něco co není posvěceno JCP! Nebo nedejbože používat OSGi. Fuj.

U toho OSGi bych se chvíli zdržel. Je to standard, se kterým se budeme setkávat stále více a více. Slouží k implementaci modulárních systémů, umožňuje nadefinovat moduly, které mezi sebou komunikují pomocí daného rozhraní, definuje životní cyklus a mnoho dalšího. První verze spatřila světlo světa v roce 2000, teď je ve verzi 4. Existuje několik implementací. Používá se v automobilech, stojí na něm Eclipse, začíná ho používat BEA, jede na něm WebSphere 6.1 a další. Člověk by řekl, že to je věc, která by stála zato, aby ji vzal na vědomí i Sun.

Chyba lávky, Sun rozjel vlastní specifikaci JSR 277 (Java Module systém), která obsahuje jakousi nekompatibilní podmnožinou možností OSGi (mimochodem OSGi najdete pod JSR 291). Jelikož za JSR 277 stojí Sun, má velkou šanci se dostat do Java EE 6. Že neexistuje žádná vyzkoušená implementace? Nevadí. Že se nepoučili z chyb ostatních? Nevadí. Peter Kriens, jeden s klíčových lidí OSGi, popisuje, jak se snažil dostat do skupiny, která na JSR 277 pracuji. Prý ho odmítli s tím, že už jich je tam moc. Proč myslíte, že se Sun takto chová? Já si myslím, že je za tím NIH.

Poznámka: Dnes jsem se nechal trochu unést. Proto jsem článek prošpikoval odkazy, abyste si mohli udělat vlastní obrázek. Budu rád, když mě někdo vyvede z omylu. Zajímavou diskuzi najdete také na InfoQ

Měříme touhu

V mé choré mysli se zrodil plán. V případě nedostatku vlastních myšlenek, jako například teď, vás budu oblažovat výběrem oblíbených kapitol z oblíbených knih. Takže se postupně budu vracet i ke knihám o kterých jsem už psal dříve, když jsem je četl.

Dnes budu psát o kapitole Prioritizing desirability, z knihy Agile Estimating and Planning Mika Cohena. Kapitola je o zjišťování toho, co si zákazník přeje. Začíná Kanovým modelem zákaznické spokojenosti. V principu jde o to, že existují tři základní kategorie vlastností produktu

  • Nutné – vlastnosti, bez kterých se neobejde. Když kupuji notebook, chci aby měl monitor.
  • Lineární – čím víc tím líp. Čím má notebook větší paměť, tím lépe.
  • Vzrušující – věc kterou jsem nečekal a příjemně mě překvapí. U notebooku to může být například dálkové ovládání pro sledování filmu z postele.

Když si to zakreslíme do grafu, dopadne to asi takto

Kano model

Na svislé ose máme spokojenost zákazníka. Nahoře je spokojený, dole nespokojený. Na vodorovné ose vidíme míru přítomnosti dané vlastnosti (nebo potřeby). Vlevo úplně chybí, vpravo je plně obsažena.

Zeleně jsou označeny nutné vlastnosti. Vidíme, že když nejsou obsaženy, tak zákazník dokáže být hodně nespokojený. Nicméně i když je do produktu přidáme, moc vysoko se na žebříčku spokojenosti nevyšplháme.

Modré jsou lineární vlastnosti. Ty jsou podle mě snadno pochopitelné.

Červeně jsou označeny vzrušující vlastnosti. Když nejsou obsaženy, zákazníka to moc neštve. Když je ale přidáme, můžeme si snadno zajistit jeho spokojenost.

Je důležité si uvědomit, že to samé rozdělení platí i u vlastností software. Když vyvíjíme agilně, můžeme toto rozdělení použít pro prioritizaci práce. Víme, že nutné vlastnosti musí náš produkt nutně obsahovat. Musíme je proto rozhodně stihnout do releasu, není dobré je odkládat. Nicméně nemusíme je implementovat plně. Vidíme, že nárůst spokojenosti není od určité úrovně naimplementování moc velký.

Lineární vlastnosti jsou druhé na řadě. Měli bychom jich stihnout co nejvíce v co největší míře. Nakonec je dobré přihodit pár vzrušujících vlastností, abychom si zákazníka trochu rozmazlili.

Otázkou zůstává, jak zjistit, do které kategorie daná vlastnost patří. I na to v knize dostaneme odpověď. Zeptáme se například následující otázkou, s možnými odpovědmi

Pokud váš nový program bude umět exportovat data do excelu

  1. Budu rád
  2. Čekám že to tak bude
  3. Je mi to jedno
  4. Zvládnu s tím žít
  5. Nebudu rád

Trik je v tom, že se ho zeptám ještě jednou na opak

Pokud váš nový program nebude umět exportovat data do excelu

  1. Budu rád
  2. Čekám že to tak bude
  3. Je mi to jedno
  4. Zvládnu s tím žít
  5. Nebudu rád

Když dostaneme odpověď na obě otázky, můžeme použít následující tabulku pro určení dané vlastnosti

Tabulka

Teď už nám nic nebrání v tom, abychom se zeptali několika potencionálních uživatelů a podle toho určili, co vlastně od našeho produktu chtějí. Samozřejmě to nikdy nevyjde jednoznačně, ale s použitím statistiky nebo jiného podfuku to dokážeme zpracovat. Dostaname tak zajímavý nástroj na prioritizaci vlastností.