Vlákno názorů k článku
Vývojář si jen s programováním nevystačí

Podobně jako spousta jiných vývojářů zde pracuji v softwarové firmě s ročním obratem v desítkách miliónů korun. Na obchodní myšlení máme obchodníky, na organizaci práce máme project managery a na programování programátory. Samozřejmě všichni tito lidé musí být schopni nějaké té týmové práce, ale to nepovažuji za žádnou výjimečnou a vzácnou schopnost. Za těch téměř pět let, co ve firmě pracuji, se našel pouze jediný „autista“, který nebyl týmové práce schopen, a tak byl po několika měsících propuštěn.

Při přijímacích řízeních, kde posuzuji uchazeče na místa programátorů, kladu důraz především na schopnost programátorsky myslet a na zvládnutí dané technologie, zatímco „měkké dovednosti“ mohou hrát roli jen tehdy, když zcela absentují.

Žádná revoluce se nekoná, dobrý programátor je prostě ten, kdo umí dobře programovat :)

„kladu důraz především na schopnost programátorsky myslet a na zvládnutí dané technologie“

Hmm, bohuzel jsem videl vysledky podobnych programatoru v podobne firme, jako bude zrejme i ta vase (pozor, usuzuji pouze podle vasich minimalnich naroku u prijimacich pohovoru). Vysledek byl po par letech tento:

"""A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
…
…
Such code can become a personal fiefdom, since the author care barely understand it anymore, and no one else can come close. Once simple repairs become all day affairs, as the code turns to mud. It becomes increasingly difficult for management to tell how long such repairs ought to take. Simple objectives turn into trench warfare. Everyone becomes resigned to a turgid pace. Some even come to prefer it, hiding in their cozy foxholes, and making their two line-per-day repairs.
"""
http://www.laputan.org/mud/mud.html#BigBallOfMud

Na Internetu se vali spousta clanku o tom, jak spravne delat prijimaci pohovory, od lidi, kteri je delaji desitky let. Muj oblibeny: http://www.martinfowler.com/bliki/PreferDesignSkills.html

„Na Internetu se vali spousta clanku o tom, jak spravne delat prijimaci pohovory, od lidi, kteri je delaji desitky let. Muj oblibeny…“

IMHO je to jen jiný pohled na věc a nelze říct, že by jeden z nich byl špatný. Martin Fowler sice hezky popisuje, jak si vybírá spolupracovníky, aby nebyli přeborníky jen na vymezenou oblast, ale spíš všestraně užiteční, až bude společnost přecházet na jinou vývojovou platformu. S tím se dá ale s úspěchem polemizovat. Proč bych nabíral skvělého „vymýšleče“ do týmu, když ty, co to navrhnou a vymyslím mám a prostě potřebuju člověka, který umí platformu a bude kódovat a navrhovat relevantní úpravy, protože zná výborně danou oblast? Taky v kolika firmách se přechází na jinou platformu tak často, aby se jim nevyplatilo si své lidi vyškolit (z Delphi do .NET/Java, z jedné databáze na jinou apod.)?

– „Martin Fowler sice hezky popisuje, jak si vybírá spolupracovníky, aby nebyli přeborníky jen na vymezenou oblast, ale spíš všestraně užiteční, až bude společnost přecházet na jinou vývojovou platformu. S tím se dá ale s úspěchem polemizovat.“

V tomto clanku bohuzel nic podobneho nevidim. Vidim tam tvrzeni, ze jsou tito lide pro zakaznika/firmu vyhodnejsi.
Doporucuju k prostudovani nejake dalsi clanky na podobne tema od MF:

http://martinfowler.com/bliki/CheaperTalentHypothesis.html – """Its really difficult to drive this point to old school companies who think a army of cheap programmers is a bargain than small teams of really talented people. No wonder why there is so much inefficiency all around."""

http://martinfowler.com/bliki/CannotMeasureProductivity.html
http://martinfowler.com/bliki/TechnicalDebt.html

Pripadne nejake clanky od Joela: http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html

A hlavne neco o metodologii, protoze se mi zda, ze tu propagujete „Monumental“:
http://martinfowler.com/articles/newMethodology.html
„From Nothing, to Monumental, to Agile“, tzn. ze jste rekneme 10 az 20 let pozadu za opravdu uspesnyma firmama jako jsou Microsoft, Apple, Google a dalsi:

""""
Before Google, companies in Silicon Valley already knew it was important to have the best hackers. So they claimed, at least. But Google pushed this idea further than anyone had before. Their hypothesis seems to have been that, in the initial stages at least, all you need is good hackers: if you hire all the smartest people and put them to work on a problem where their success can be measured, you win. All the other stuff—which includes all the stuff that business schools think business consists of—you can figure out along the way. The results won't be perfect, but they'll be optimal. If this was their hypothesis, it's now been verified experimentally.
""""
http://www.paulgraham.com/5founders.html

Vezmu-li v uvahu, ze dobry programator je hlavne dobry optimalizator (coz vychazi z jeho nezbytne lenosti: Why Good Programmers Are Lazy and Dumb – http://blogoscoped.com/archive/2005-08-24-n14.html), tak jestlize ma programator moznost zoptimalizovat procesy, bude z toho Agile a nikoli Monumental. Tzn. Google a ne „Velka Enterprise Nekompetentni Firma“ s programatory v Indii nebo Cine.

– „Proč bych nabíral skvělého „vymýšleče“ do týmu, když ty, co to navrhnou a vymyslím mám a prostě potřebuju člověka, který umí platformu a bude kódovat a navrhovat relevantní úpravy, protože zná výborně danou oblast?“

Protoze http://martinfowler.com/articles/newMethodology.html#PlugCompatibleProgrammingUnits ? :

""""
Plug Compatible Programming Units

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren't so important, only the roles are important. That way if you plan a project it doesn't matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.

But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption.

Perhaps the most explicit rejection of people as resources is Alistair Cockburn. In his paper Characterizing People as Non-Linear, First-Order Components in Software Development, he makes the point that predictable processes require components that behave in a predictable way. However people are not predictable components. Furthermore his studies of software projects have led him to conclude the people are the most important factor in software development.

In the title, [of his article] I refer to people as „components“. That is how people are treated in the process / methodology design literature. The mistake in this approach is that „people“ are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts of unplanned project trajectories we so often see.

-- [Cockburn non-linear]

One wonders if not the nature of software development works against us here. When we're programming a computer, we control an inherently predictable device. Since we're in this business because we are good at doing that, we are ideally suited to messing up when faced with human beings.

Although Cockburn is the most explicit in his people-centric view of software development, the notion of people first is a common theme with many thinkers in software. The problem, too often, is that methodology has been opposed to the notion of people as the first-order factor in project success.

This creates a strong positive feedback effect. If you expect all your developers to be plug compatible programming units, you don't try to treat them as individuals. This lowers morale (and productivity). The good people look for a better place to be, and you end up with what you desire: plug compatible programming units.

Deciding that people come first is a big decision, one that requires a lot of determination to push through. The notion of people as resources is deeply ingrained in business thinking, its roots going back to the impact of Frederick Taylor's Scientific Management approach. In running a factory, this Taylorist approach may make sense. But for the highly creative and professional work, which I believe software development to be, this does not hold. (And in fact modern manufacturing is also moving away from the Taylorist model.)
"""

„V tomto clanku bohuzel nic podobneho nevidim. Vidim tam tvrzeni, ze jsou tito lide pro zakaznika/firmu vyhodnejsi.“

Myslím, že není nutné slovíčkařit. Vzhledem k odkazům a pojmenování situace („…protoze se mi zda, ze tu propagujete „Monumental“…“) se mi zdá, že si rozumíme, co jsem chtěl říct. Taky bych rád podotknul, že i když jsem to nezmínil (neboť jsem to nepokládal za důležité), tak jsem svou reakcí chtěl hrát spíše ďáblova advokáta než prezentovat svůj názor (který se spíše blíží tomu, co se popisuje v odkazovaných článcích, byť si nemyslím, že z toho lze vždy uplatnit vše). A když jsem pak pročítal všechny ty odkazy, byl jsem velmi rád, že jsem vůbec toho advokáta zahrál. Texty jsou opravdu zajímavé a díky za ně. K přečtení je mohu jen doporučit.
-

Zkusím se ale ještě vrátit a pokusím se nahlédnout do české reality – myslím, že na poli IT se tu objevují v podstatě jen firmy, které:

1. jsou podobočkou / dceřinkou zahraniční korporace a pracují buď nějaké velmi vymezené oblasti (typicky „banda kodérů“) nebo customizují a udržují jinde napsaný kód („banda konfigurátorů“).

2. fungují jako námezdní síla pro krátkodobý vývoj či outsourcing (továrna na kód).

3. postavily svou existenci na jedné aplikaci (např. informačním systému), kterou postupně obalují dalšími featurami / moduly, a pokud to bude možné, tak ji budou vyvíjet až do skonání světa.

4. stojí na jediné osobě analytik-vývojář-tester-konzultant v jedné osobě – tj. one-man show firmy / živnostníci.

Ani u jedné kategorie (možná s vyjímkou dostatečně osvícených firem z třetí skupiny) si nejsem jistý, že by dokázala využít schopnosti nového Paula Buchheita a změnit například osvědčenou (tj. tu zrovna zavedenou) metodologii vývoje.

U tohoto mě napadá – existují i u nás nějaké společnosti, které by opravdu dělaly vývoj „jinak“. Sice se toho už hodně změnilo a spousta vývojářů zná klíčová slova jako je agilní programování, unit testy apod. (dokonce se o tom i učí děti na školách), ale existuje „český“ ThoughtWorks?

Do které skupiny bys zařadil firmy jako Unicorn nebo Logos (v době, kdy ještě byl Logosem)?

Nevim proc bych mel hodnotit „Logos, kdyz byl jeste Logosem“ – zkuste jej ohodnotit vy. Pokud firmu znate nejak lepe, urcite se vam povede ji nejak priblizit nam, co je znaji maximalne podle jmena.

Presto si ale zkusim tipnout. Jelikoz je pred dvema lety koupil Ness, bude z nej nejspise primovni „tovarna na kod“ a „my vam to zautsourcujem – bude to levnejsi“ – cili sehnat „projekt“, nejak nabouchat, vyfakturovat, dalsi upravy solidne nadsadit, aby jich moc nechteli a casem pripadne dotlacit k novemu projektu, kteremu budeme rikat upgrade ci modernizace a bude se to delat v podstate od nuly.

S Unicorn jsem prisel do styku jen pred osmi lety, kdy jsem shanel jako student bez valne praxe nejakou praci. Nebyl jsem z firmy nadseny, takze jsem nakonec radeji skoncil u male ceske spolecnosti, kde mi prislo, ze jsou otevrenejsi k napadum a zmenam. Unicorn mi z popisu nekolika mych kolegu, kteri ve spolecnosti pracovalo pripadal (pred temi nekolika lety) jako typicka „tovarna na kod“. Je mozne, ze se vsak mnohe zmenilo a ze opravdu uz „delaji software jinak“. Ja jako skeptik to vidim jen na velmi povedeny marketing. Aktualne ale informace zevnitr nemam, mozna nam je tu nekdo prednese a budeme vedet vice. Budu rad, kdyz se budu mylit.

Zajímavý (a záslužný) pokus o typologizaci českých firem, leč uvedená typologie rozhodně není úplná. Např. http://www.definity.cz/cz/sekce/o+spolecnosti/ nelze zařadit do ani jedné z kategorií, dokonce se žádné z kategorií ani nepřibližuje.

Tak nam ji popis – co a jak se u nich dela. Uz treba jen ten vstupenkovy system by mohl byt zajimavy a je otazkou proc jej neprodavaji jinam ale je udelan jen pro TicketArt?

Proc vlastne u nas nevznika software, ktery by se pokusil konkurovat v Evrope ci ve svete? Existuje prece tolik oblasti, kde je znalost ceskeho prostredi mozne snadno generalizovat (tj. ne treba ucetnicky program, ale ten system na prodej vstupenek snad ano).

Proc kdyz uz vznikne neco zajimaveho, tak s tim autori radeji jdou pryc nez aby se toho nejaka ceska sw firma chopila a rozjela ten spravny byznys? Napr. Stankuv NetBeans, ktery skoncil u Sunu (malou naplasti muze byt to, ze Sun vyvoj nynni snad dela ve sve ceske pobocce).