Joel Spolsky se pěkně otřel o to, jak budou uživatelé vypínat Windows Vista. Rozhraní označil za příliš komplikované, nabízí podle něj příliš mnoho možností.
Shodou okolností máme možnost přečíst si i názor z Microsoftu – programátor, který implementoval uživatelské rozhraní k vypnutí počítače vzpomíná na to, jak strávil vývojem této vlastnosti rok. Joelova kritika je zajímavá, ale popis vývoje je ještě mnohem zajímavější. Z blogpostu – a z dlouhé, ale velmi zajímavé diskuse pod ním – lze vyčíst mnoho o tom, jak funguje Microsoft.
První příjemné zjištění je, že malá měkká firma je už velká a zkostnatělá – do takové drobnosti tak či onak remcalo 43 lidí. Navíc poměrně těžkopádný systém buildů způsoboval, že každá oprava se integrovala do zbytku systému týdny až měsíce.
V diskusi schytalo sestavování Windows pěknou dávku kritiky – systém je rozsáhlý a tak je rozdělen do mnoha komponent, které mají vlastní vývojářské teamy. Ty nemají k dispozici snadno přístupné společné uložiště zdrojových kódů, ale změny jsou do něj postupně integrovány v několika krocích. Na tom by nebylo nic špatného, pokud by byly komponenty volně svázané přes slušně definovaná rozhraní (ne, v hodinách softwarového inženýrství, se o něčem takovém nemluví druhou hodinu). Protože jsou však komponenty svázány dost těsně a závislosti jsou mnohdy i cyklické, nastává pro vývojáře peklo na zemi. Jen v něm jsou místo kotlů schůze a místo čertů s vidlemi managoři.
Anonym to v diskusi shrnul takto:
The people who designed the source control system for Windows were *not* idiots. They were trying to solve the following problem:
- thousands of developers,
- promiscuous dependency taking between parts of Windows without much analysis of the consequences
–> with a single codebase, if each developer broke the build once every two years there would never be a Longhorn build (or some such statistic – I forget the actual number)
There are three obvious solutions to this problem:
1. federate out the source tree, and pay the forward and reverse integration taxes (primarily delay in finding build breaks), or…
2. remove a large number of the unneccesary dependencies between the various parts of Windows, especially the circular dependencies.
3. Both 1&2
#1 was the winning solution in large part because it could be executed by a small team over a defined period of time. #2 would have required herding all the Windows developers (and PMs, managers, UI designers…), and is potentially an unbounded problem.
Pěkně také vysvětlil, proč open source netrpí v takové míře podobnými problémy:
- rarely take dependencies on unshipped code
- rarely make circular dependencies
- mostly take depemdencies on mature stable components.
Jak později poznamenává (jiný nebo stejný?) Anonym, který o sobě tvrdí, že je vývojářem Windows – oddělení různých větví vývoje funguje v prvních fázích vývoje, protože dobře separuje nefunkční kód, ale při přípravě milestonů je to nepříjemný zádrhel – každá dosud neintegrovaná větev se chce nejednou dostat do release a to působí neplechu.
Několik pisatelů v diskusi také zmiňuje důležitost akceptačních testů – to je pro mne důležité zjištění, je to oblast, kterou bych si měl lépe nastudovat.
Těžko říci, jak z toho ven. Možná je lepší se nikdy nedostat dovnitř… Možná je nutné změnit paradigma (OK, ten článek je zastaralý, tedy chci říci klasika), abyste nezjistili, že jste napsali 200 funkčních řádek za rok. Rád si v diskusi přečtu i váš názor.