Прочитал книгу The Cathedral and the Bazaar.
Автор Eric Steven Raymond.
Пока читал не переставал вспоминать забавный случай как я ходил в Мейл на собес, там один из собеседующих был такой каноничный программист-анальник, взрощенный на хабре, ну прям карикатурно. Я, конечно же, спросил насчёт удалёнки, на что получил презрительный смешок и вот как бы свысока нравоучительным тоном что-то вроде: «Мальчик, чтобы ты знал, ни один крупный проект не может быть создан удалённой командой, это просто абсурд, все должны сидеть в офисе». Стало ясно, что собес он завалил и я в эту команду точно не пойду (а Мейл это именно команды, а не монолит). Это всё было, конечно, до того как все команды во всём мире принудительно перевели на удалёнку.
Эта книга не про программирование, точнее ровно настолько же только про программирование как «Язык шаблонов» только про градостроительство.
На самом деле основная идея в том, что умным и мотивированным людям не нужна организация, начальство и т. д. Если есть достойное общее дело, они сами договорятся как и что делать и главная задача начальника это не мешать людям работать. Но для компаний это так себе новость, это скорее означает, что наиболее крутые ребята будут либо что-то делать на стороне, либо к ним вообще не пойдут.
И единственный способ для корпораций привлечь к себе людей, это не только хорошие деньги предлагать, это само собой. Нужно находить заинтересованных программистов и это не написать в описании про «ГОРЯЩИЕ ГЛАЗА». Речь о том, чтобы показать людям продукт, заинтересовать их в нём и дать возможность поучаствовать. Проблема большинства современных компаний в том, что они делают ненужную фигню, которая не заинтересует никого. Очередная CRM система или сайт по продаже фигни дурачкам, «инновационная» система из категории «миллениалы изобрели»
Такой продукт мало кого может привлечь.
Но есть продукты которые плюс-минус решают какие-то проблемы и действительно приносят пользу. Вот к ним и надо привлекать людей. Лучшее для этого решение для таких продуктов именно в аспекте привлечения программистов — это опенсорс. И если раньше кто-то мог в этом сомневаться, то в 2020 это должно быть очевидно по опыту того же фейсбука с реактом, микрософта с вс кодом и многих других.
Эти компании, помимо очевидного привлечения талантливых людей, ещё также с переменным успехом пытаются принять характерный подход к разработке — Базар.
В книге рассказывается про два подхода к организации людей и работы. Речь про Собор и Базар. В то время, начало-середина 90ых, Линукс только только выкатили, опенсорс уже, конечно был, но никто не верил, что что-то действительно великое может быть не просто опенсорсным, но ещё и децентрализованно сделанным.
Вот что говорит на этот счёт автор:
I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time. Linus Torvalds’s style of development-release early and often, delegate everything you can, be open to the point of promiscuity-came as a surprise. No quiet, reverent cathedral-building here-rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches
Это сейчас мы пользуемся Линуксом и лучшие из имеющихся программ у нас тоже опенсорсные, а вот когда-то, оказывается, было иначе.
На протяжении книги Эрик рассказывает о своем опыте организации Базара, в то время с почтовыми клиентами было так себе и вот он решил написать свой.
Every good work of software starts by scratching a developer’s personal itch.
Вот, например как надо относиться к юзерам
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently. In fact, I think Linus’s cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: «I’m basically a very lazy person who likes to get credit for things other people actually do.» Lazy like a fox. Or, as Robert Heinlein famously wrote of one of his characters, too lazy to fail.
Насчёт багов и выдрачиваний релизов
Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don’t want to wear out the patience of your users. This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you’d only release a version every six months (or less often), and work like a dog on debugging between releases.
Как часто надо релизить? Как можно чаще, баги не так уж и важны
Linus’s innovation wasn’t so much in doing quick-turnaround releases incorporating lots of user feedback (something like this had been Unix-world tradition for a long time), but in scaling it up to a level of intensity that matched the complexity of what he was developing. In those early times (around 1991) it wasn’t unknown for him to release a new kernel more than once a day! Because he cultivated his base of co-developers and leveraged the Internet for collaboration harder than anyone else, this worked.
Закон Линуса:
Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this: Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, «Given enough eyeballs, all bugs are shallow.» I dub this: «Linus’s Law».
Про пользу команд:
Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect.
Почему тестеры должны знать код:
Non-source-aware users tend to report only surface symptoms; they take their environment for granted, so they (a) omit critical background data, and (b) seldom include a reliable recipe for reproducing the bug. The underlying problem here is a mismatch between the tester’s and the developer’s mental models of the program; the tester, on the outside looking in, and the developer on the inside looking out. In closed-source development they’re both stuck in these roles, and tend to talk past each other and find each other deeply frustrating. Most bugs, most of the time, are easily nailed given even an incomplete but suggestive characterization of their error conditions at source-code level. When someone among your beta-testers can point out, «there’s a boundary problem in line nnn», or even just «under conditions X, Y, and Z, this variable rolls over», a quick look at the offending code often suffices to pin down the exact mode of failure and generate a fix.
Почему закон Брука можно обойти
The Brooks’s Law analysis (and the resulting fear of large numbers in development groups) rests on a hidden assummption: that the communications structure of the project is necessarily a complete graph, that everybody talks to everybody else. But on open-source projects, the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only within that small core group do we pay the full Brooksian overhead.
Опять об отношении к людям:
If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
Почему большинство осовремененных продуктов не получится делать по этому принципу. Потому что они говно не нужное и понадобится ещё штат маркетологов, чтобы это людям всучить
Your nascent developer community needs to have something runnable and testable to play with. When you start community-building, what you need to be able to present is a plausible promise. Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.
Ещё про Брука:
In The Mythical Man-Month, Fred Brooks observed that programmer time is not fungible; adding developers to a late software project makes it later. As we’ve seen previously, he argued that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly. Brooks’s Law has been widely regarded as a truism. But we’ve examined in this essay an number of ways in which the process of open-source development falsifies the assumptionms behind it-and, empirically, if Brooks’s Law were the whole picture Linux would be impossible.
Как эго позволяет организовать команду крутых:
Voluntary cultures that work this way are not actually uncommon; one other in which I have long participated is science fiction fandom, which unlike hackerdom has long explicitly recognized «egoboo» (ego-boosting, or the enhancement of one’s reputation among other fans) as the basic drive behind volunteer activity. We may view Linus’s method as a way to create an efficient market in «egoboo»-to connect the selfishness of individual hackers as firmly as possible to difficult ends that can only be achieved by sustained cooperation. Many people (especially those who politically distrust free markets) would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by (to give just one example) the stunning variety, quality, and depth of Linux documentation. It is a hallowed given that programmers hate documenting; how is it, then, that Linux hackers generate so much documentation? Evidently Linux’s free market in egoboo works better to produce virtuous, other-directed behavior than the massively-funded documentation shops of commercial software producers.
Про менеджмент там тоже много хорошего, основной поинт в том, что большую часть времени традиционный менеджмент занимается защитой своих ресурсов от других менеджеров, а оставшееся время пинает программистов, чтобы те делали рутину.
If the conventional, closed-source, heavily-managed style of software development is really defended only by a sort of Maginot Line of problems conducive to boredom, then it’s going to remain viable in each individual application area for only so long as nobody finds those problems really interesting and nobody else finds any way to route around them. Because the moment there is open-source competition for a `boring’ piece of software, customers are going to know that it was finally tackled by someone who chose that problem to solve because of a fascination with the problem itself- which, in software as in other kinds of creative work, is a far more effective motivator than money alone.
Кароче, книга поразительно хороша, учитывая что она читается часа за полтора. Там каждая глава потянет на пару книг от издательства Манн Иванов Фербер, только без воды и тупости.
Качать тут https://github.com/inferno986return/cathedral-bazaar-ebook