metaclass | Программистское мракобесие

Программистское мракобесие

Я почему-то думал, что когда 10 лет толпой людей разрабатывают сложные системы, там не делают так, как я - держа все знания по проекту только в виде кратких текстовых набросок по поводу архитектуры, часть информации в голове(чтобы можно было проектировать в уме в любое время), и основную часть - в виде структуры проектов и кода в системе контроля версий.

А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

Threaded | Top-Level Comments Only

Хотите разговора по существу? Ок, я не против. Давайте проверим, насколько Вы способны поддерживать беседу по существу. Не переходя на личности.
Это на фоне то Вашей последующей реплики? Я вижу, что жанр нашей переписки Вы уже выбрали совершенно однозначно.

(1) То что документацию, отдельную от кода, на практике в большом и длинном проекте невозможно держать в когерентном состоянии - это факт, с которым регулярно сталкиваются почти все. И возразить Вам на него по существу нечего. Эта проблема объективно существует, не так ли? Будем признавать наличие проблемы, спокойно, и без переходов на личности?
Есть проблема трудоёмкости, нет проблемы невозможности.
Сталкиваются почти все, поддерживают не все, спорить не буду.
Про невозможность - ну расскажите разработчикам из компании IBM например. Почему то у них такой проблемы нет.
Разумеется, никто не может постулировать 100% соответствие. Но и постоянное удержание 9x процентов - очень хорошая и полезная практика.

Мой тезис (3) состоит в том, что документация не есть адекватный способ обеспечить (2) в условиях наличия (1). Но это вовсе не означает, что способа нет. Вот, смотрите, здесь я подробно объясняю, почему (3), и показываю как эффективно и дешево достичь (2). Вот это -работает. Вот ЭТО я рекомендую.

Есть ли у Вас что-нибудь сказать по существу?

Да, есть.
Документация не является сама по себе единственным способом обеспечить как Вы выразились (2), но без её наличия адекватное (2) попросту невозможно.

Более того, наличие адекватной документации по системе критично для тех случаев, когда Вы открываете доступ к бывшим внутренним интерфейсам системы для сторонних разработчиков - т.к. в код их пускать малоинтересно, а такая необходимость возникает у многих и регулярно.

То, что наличие такой документации ускоряет адаптацию новых разработчиков к проекту - это факт, который не подлежит обсуждению, если мы только исходим из того, что у нас в команде работают не только мегазвёзды, но и середнячки или даже 'просто кодеры'.

Вопрос о том, каким образом собирается документация - с помощью каких-то полуавтоматических систем или вручную - это вопрос отдельный, но в любом случае, полностью автоматическая её генерация по комментам - вряд ли хорошая идея. Т.к. таким способом можно сделать текст быстрым, но невозможно сделать его хорошим с точки зрения человеческого восприятия.

> Ты видел их внутреннюю, проектную документацию? Ну конечно не видел, откуда тебе.

1. Давайте на "Вы".
2. Я говорю про MSDN. Очень сомневаюсь, что его пишут после программеров отдельные писатели, анализируя код. Таки писателей в общем-то не найти.
3. О подобной проектной документации есть описания.

Случай тяжелый. У меня нет мании величия, уважаемый. Критикуя подход КОМПАНИИ в моем лице,, Вы пытаетесь учить жизни КОМПАНИЮ, а не меня. И не имеет никакого значения, совладелец я бизнеса, или нет.
Уровень аргументации, мягко скажем, несерьёзный.
Вы путаете 'жизнь', 'бизнес' и 'технологическую дисциплину'.
Судя по тому, что Вы рассказали, Вы публично выступаете от имени компании по вопросам 'технологической дисциплины', а к бизнесу имеете опосредованное отношение.
Повторю ещё раз - я никого (включая Вас) вообще в данном случае ничему учить не собираюсь. Но находясь в публичном пространстве - имею право и буду давать свои оценки Вашим публичным высказываниям.

Разгребать "последствия моей деятельности" - Вы фитилек-то мании величия прикрутите, хорошо? :)
Пошлым образом манипулируете текстом. Я нигде не писал, что лично я буду последствия лично Вашей деятельности разгребать. Кому-то скорее всего придётся.

Тим Мазер, владелец CQG, как нибудь все "разгребет" и без Ваших советов. Последние 29 лет он как-то без Ваших советов обходился, и ему это пошло впрок - умудрился стать мультимиллионером. А Вам до уровня, когда Вам потребуется архитектор, способный справится с миллионами строк кода - еще расти и расти. Растилку отрастите сначала, ок? :)
Это всё разговоры из серии "да мы с Вовой Путиным".
Тиму Мазеру я не давал советов, а Вы сейчас пытаетесь сделать вид, что Вы с ним одно и тоже. Уясните себе разницу между действия владельца бизнеса и действиями нанимаемых им сотрудников - тогда у нас будет предмет для разговора, а пока у Вас просто отсутствует необходимый для такого разговора бэкграунд.
Про мой уровень просто молчали бы уже, сколько можно Вам позориться, швыряясь какашками? Я, замечу, в Ваш адрес не высказывался, что Вы, например, непрофессиональны или ещё что-то такое. Всё что было - это указание на то, что профессионализм не подразумевает сам по себе правильной практики ведения дел.

Во-первых, отучайтесь лезть с оценками, когда Вас о них никто не просит. Есть неплохой шанс выставить себя клоуном.
Во-первых, не говорите что мне делать - и я Вам не буду говорить, куда Вам пойти с такими советами.
Во-вторых, находясь, как я уже указал, в публичном пространстве, не рассчитывайте, что Ваши высказывания не будут комментироваться и оцениваться.
И не воспринимайте негативные оценки как персонально направленную агрессию. Мне то всё равно, а Вы лицо теряете.

Во-вторых, уважаемый, я менеджер, а не архитектор. Меня брать на работу архитектором действительно нецелесообразно - обойдусь слишком дорого. :)
Верю. И я написал уже, почему :)

И в третьих - Вы не в курсе, что давным давно есть возможность не пИсать против ветра, и всю "документацию по внутренним API" генерировать из кода и комментариев автоматически?
В курсе. Это всего лишь повод для разговора о том, какая часть описания системы должна генерироваться, какая - писаться руками, а какую - действительно не нужно писать. Но эта постановка вопроса далековато находится от Вашего тезиса о принципиальной некогерентности документации и проекта, которая якобы мешает эту документацию вести и которая не даёт документации приносить пользы.

> а до этого никто никуда не спешит в стиле "некогда документировать - код писать надо"

"Писать код" в общем-то никогда не надо. Есть проблемы нервов у исполнителей, есть проблемы мозга у бизнеса, бывают проблемы простого неумения и незнания, "как делается документация". Но вообще писать программы срочно очень редко бывает реально надо.

Вы выступили с броневичка с фигой в кармане: начальство -- дураки, занимаются дуростью. Это ВЫ смотрите на начальство с презрением. Я лично нахожусь в середине.

> Есть проблема трудоёмкости, нет проблемы невозможности.

Есть проблемы а) высокой трудоемкости, которая обеспечивает практическую невозможность, и б) целесообразности.

У Вас есть что сказать предметно по обеим проблемам?

> Разумеется, никто не может постулировать 100% соответствие. Но и постоянное удержание 9x процентов - очень хорошая и полезная практика.

Не вижу в Ваших словах никакой практики - только декларации. Опишите процесс поддержания документации, который сработает в ситуации поддержки, о которой я говорю. Если Вы не в курсе, что это такое и на что похоже, а Вы не в курсе - это когда у вас примерно половина разработки управляется запросами в трекере - частично дефектами, частично фичреквестами. Поток этих запросов большой, они по отдельности - относительно мелкие, и за год приводят к поистине удивительным транформациям кода и его расхождению с документацией.

> Да, есть.
> Документация не является сама по себе единственным способом обеспечить как Вы выразились (2), но без её наличия адекватное (2) попросту невозможно.

"Попросту невозможно" - это по существу! :))) Докажиземлюешь. :) Вот я Вам "попросту" объясняю в тексте по ссылкам, как это делать, чтобы было "возможно", и почему так. И почему ваши документы проблем не решают, объясняю. Более того - я прекрасно знаю, как это работает на практике. Видел неоднократно. Читать и понимать, что там написано, будем? По существу, предметные возражения - будут?

Есть проблемы а) высокой трудоемкости, которая обеспечивает практическую невозможность, и б) целесообразности.
У Вас есть что сказать предметно по обеим проблемам?

Я уже Вам сказал, Вы не увидели. Трудоемкость высока, целесообразность возникает для любых предприятий с высокими технологическими требованиями. Для тех кто в танке привожу простой жизненный пример. Если у Вас есть софт, управляющий логикой работы некоего прибора в самолёте или там элемента АЭС - мало кого гребут Ваши творческие изыски по передаче знаний в коллективе.
Для проекта критично, чтобы в этом софте можно было быстро разобраться в любой конкретно взятый момент лет этак 30-40 после сдача объекта в эксплуатацию. Показанный Вами способ сопровождения системы реализации этого требования не обеспечивает. Точка.

Впрочем, можно и продолжить, указав на то, что та же самая проблема встаёт для любого предприятия, которое живёт чуть более, чем несколько лет и которое не связано с IT как таковой. Тиму Мазеру очень хорошу рулить компанией, которая производит софт. Потому что у него ничего кроме софта и нет, и он имеет возможность и полное право фокусировать своё внимание на софте.

Когда Вы делаете систему управления предприятием, занимающимся какой-то иной деятельностью - Вы обнаруживаете, что фокус внимания руководства компании сосредоточен отнюдь не на IT-подразделении.
Практически это означает, что вероятность более-менее резких смен состава IT-подразделения достаточно велика.
И тут (снова про трудоёмкость), если Вы экономите на написании документации - Вы экономите своё время за счёт чужого.
Подход понятный, но, как минимум, надо честно декларировать последствия тому, кто заказывает музыку.

Если Вы не в курсе, что это такое и на что похоже, а Вы не в курсе - это когда у вас примерно половина разработки управляется запросами в трекере - частично дефектами, частично фичреквестами. Поток этих запросов большой, они по отдельности - относительно мелкие, и за год приводят к поистине удивительным транформациям кода и его расхождению с документацией.
Кончайте высказываться в мой адрес, надоели уже эти глупости.
Вы просто не понимаете, где должна проходить граница между документацией и трекером - только и всего. Впрочем, подозреваю, что понимаете, но просто делаете вид из риторических соображений.

Попросту невозможно" - это по существу! :))) Докажиземлюешь. :) Вот я Вам "попросту" объясняю в тексте по ссылкам, как это делать, чтобы было "возможно", и почему так
Ваше объяснение - это не объяснение а рассказ в стиле 'у нас работает'. Вы мне расскажите, что с поддержкой Вашей системы произойдёт после того, как состав разработчиков сменится процентов так на 100% - нет рассказа, будем считать, что не возможно.

> Уровень аргументации, мягко скажем, несерьёзный.
> Вы путаете 'жизнь', 'бизнес' и 'технологическую дисциплину'.

Я ничего не путаю.

> Уясните себе разницу между действия владельца бизнеса и действиями нанимаемых им сотрудников - тогда у нас будет предмет для разговора, а пока у Вас просто отсутствует необходимый для такого разговора бэкграунд.

Ну так помолчите, раз предмета для разговора нет, что из вас льется и льется-то? :)

> Во-первых, не говорите что мне делать - и я Вам не буду говорить, куда Вам пойти с такими советами.

А я Вам не даю советов. Я Вам уже вежливо говорю, куда Вам идти со своими оценками и советами, до Вас просто удивительно туго это доходит.

>> Во-первых, отучайтесь лезть с оценками, когда Вас о них никто не просит. Есть неплохой шанс выставить себя клоуном.
>И не воспринимайте негативные оценки как персонально направленную агрессию. Мне то всё равно, а Вы лицо теряете.

Если Вы себя клоуном выставите, то я лицо потеряю? :) О как! :)

>> И в третьих - Вы не в курсе, что давным давно есть возможность не пИсать против ветра, и всю "документацию по внутренним API" генерировать из кода и комментариев автоматически?
> В курсе. Это всего лишь повод для разговора о том...

Только если с Вами кто-то захочет разговаривать, любезный, или хотя бы читать ваши комменты. Я, честно, в данный момент не вижу, что может меня заставить это сделать :). Во-первых, я терпеть не могу наглых хамов, таких как Вы. Во-вторых - мне неинтересно читать унылую высокомерную распонтовку, маскирующую тупость и ленность ума. Адью, продолжайте без меня.

Хотите разговора по существу? Ок, я не против. Давайте проверим, насколько Вы способны поддерживать беседу по существу. Не переходя на личности.

Как красиво Вы проиллюстрировали свой слив.

Собственно говоря, всё что Вы написали тут про высокомерную распонтовку - это Вы о себе написали, не обо мне :)

"завязываю системы на себя и оставляю полунаркотическую зависимость и потребность в сопровождении через большое время после того, как расстались."
Идея конечно хорошая, но в реальности получается так:
а) Заказчик не может предоставить достаточно информации о своих требованиях в виде, достаточном для того, чтобы можно было сделать завершенный проект. Не говоря уже об постоянном изменении законодательства.
б) Заплатить сразу деньги, достаточные для того, чтобы покрыть разработку и поддержание документации в актуальном виде, заказчик не может. Вот доплачивать за обслуживание мелкие суммы каждый месяц - нормально.
в) При обслуживании времени на доработку документации опять же нет. "Доработка нужна вчера"
г) Своих специалистов, способных понять техническую документацию на систему в полном объеме там банально нет. Не на кого оставлять систему.

Так что система, которой занимаюсь я, действительно представляет собой черный ящик, знания о ней основаны на устной передаче. И самое главное - я хотел бы написать по ней техническую документацию, но это совершенно не оправдает себя ни в каком смысле - система пишется для одного заказчика, априори является временным решением, которое или нужно будет развивать дальше(если за это вообще когда-нибудь заплатят), или выкидывать и заменять готовым софтом.
А уйти с нее они не могут - по всем вышеописанным причинам внедрить готовый софт они не в состоянии.

У меня периодически бывает, что "срочно надо писать". Но это особенности клиентов, которые могут за пару дней до сдачи налоговой декларации прислать ее новую форму, да и вообще бардака местного, когда по самой сути нормальная организация труда означает удорожание проекта в несколько раз, после чего он становится никому не нужен.

"примерно половина разработки управляется запросами в трекере - частично дефектами, частично фичреквестами. Поток этих запросов большой, они по отдельности - относительно мелкие, и за год приводят к поистине удивительным транформациям кода и его расхождению с документацией."

Я сейчас участвую в трех таких проектах одновременно, причем на всех трех я и архитектор и разработчик одновременно, а денег и времени на написание и поддержание документации никто не выделяет и выделять не собирается - т.к. если это будет медленнее и дороже, проекты просто станут никому не нужны.

Случаи, они бывают разные (с) анекдот.
В исходном тексте, однако, разрабатываемый продукт - основной предмет бизнеса для заказчика.

Не, товарищ

golosptic кое в чем прав.
Безотносительно к теме беседы про документацию, вы в своих аргументах часто таки переходите на личности и не совсем вежливо разговариваете с оппонентом, а потом, когда он таки сорвется на такой же тон, обвиняете его в этом :) Я читал у вас в посту, как вы поругались с

beskov - примерно в таком же стиле. У меня в голове, честно говоря, не очень совмещается работа менеджером и такой стиль общения - менеджеру ж постоянно надо общаться с людьми, причем не всегда адекватными, и если на них так резко реагировать - это ж можно крышей от работы поехать. Я по работе постоянно общаюсь с клиентами, их админами, своими и сторонними разработчими - и там постоянно приходится себя сдерживать от того, чтобы на них всех наорать, обозвать тупицами и послать обратно в школу учится :)

С тезисами про документацию я согласен - затраты на ее поддержание затормозят и повысят стоимость проекта в несколько раз, хотя считаю, что с этим надо как-то бороться, т.к. действительно в идеале должна быть возможность отдать проект совершенно другим людям на продолжение разработки.

С тезисами про документацию я согласен - затраты на ее поддержание затормозят и повысят стоимость проекта в несколько раз, хотя считаю, что с этим надо как-то бороться, т.к. действительно в идеале должна быть возможность отдать проект совершенно другим людям на продолжение разработки.

Вопрос состоит в том, каков реальный жизненный цикл проекта.
Если это заведомая затычка перед переходом на какую-то более крутую систему - один вариант, если подразумевается, что система будет в дальнейшем достаточно долго экслуатируются - скорее всего недокументированный проект рано или поздно придёт к такому состоянию, что его нереально модифицировать.

Качество кодинга (и редизайна архитектуры) в будущем не может гарантировать никто - 2-3 раза лидер разработчиков поменяется, каждый новый - со своими идеями будет приходить, в отсутствие систематически ведущейся документации система начнёт из себя представлять откровенную неуправляемую помойку.

Спасибо за целеуказание, добавил

beskov во френдленту :)

Обратите внимание, это Вы сами сказали, я Вас за язык не тянул. ;)

Примите моё искреннее восхищение усердием, с которым Вы обороняете абстрактное начальство от призрачного презрения. Место "в средине", видимо, ко многому обязывает.

более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

Скажите, это действительно ВЫБОР? Предсказуемость одного измерения результата достигается за счет другого?

Порекомендуете ли Вы CMMI при целевой функции вида "не очень дорого И достаточно качественно"?

> Безотносительно к теме беседы про документацию, вы в своих аргументах часто таки переходите на личности и не совсем вежливо разговариваете с оппонентом, а потом, когда он таки сорвется на такой же тон, обвиняете его в этом :)

Я вообще очень редко в своих постах затрагиваю личность собеседника. Во многом потому, что личность интернетовских анонимусов и их внутренние душевные метания меня не интересуют - они вообще кроме них самих никому не интересны, на самом деле.

Переходить на личности - это в том или ином виде обсуждать личность собеседника, вынося суждения относительно нее, смещая акцент с темы - в любой форме, не обязательно в резкой. Сюда входят также любые "выводы" и оценки, касающиеся личности собеседника на основании его слов, в том числе и в том случае, если они не содержат прямых оскорблений. Вы посмотрите внимательно посты, и поглядите еще раз, кто и когда переходил на личности.

Я в форумах далеко не первый год, типичные паттерны поведения людей в сети знаю очень хорошо, и намерение собеседника мне видно практически сразу - по нескольким постам. Если бы у него было что сказать по существу, не волнуйтесь, он бы давно это сказал.

> У меня в голове, честно говоря, не очень совмещается работа менеджером и такой стиль общения - менеджеру ж постоянно надо общаться с людьми, причем не всегда адекватными, и если на них так резко реагировать - это ж можно крышей от работы поехать. Я по работе постоянно общаюсь с клиентами, их админами, своими и сторонними разработчими - и там постоянно приходится себя сдерживать от того, чтобы на них всех наорать, обозвать тупицами и послать обратно в школу учится :)

Если я вижу в ЖЖ откровенного клоуна, который поставил себе цель самоутвердится за мой счет, и совершенно откровенно хамит мне, я не вижу ничего предосудительного в том, чтобы в ответ послать его в жопу. Вы думаете, у меня буря эмоций что-ли какая-то при этом происходит? :) Ошибаетесь. :) А если человек общается уважительно - и я с ним общаюсь уважительно.

Вообще, вы поймите простую вещь - работа и ЖЖ это не одно и то же, и все психически нормальные люди ведут себя по разному в разных контекстах. Менеджер я на работе, это профессия. На работе, кстати, мне не приходится себя сдерживать, как вам, у нас все общаются вежливо и уважительно. Даже если кто-то что-то не понимает, представляете - он не колотит себя пяткой в грудь, а просто просит объяснить, и ему просто объясняют.

"Порекомендуете ли Вы CMMI при целевой функции вида "не очень дорого И достаточно качественно"?"

В этом случае на CMMI надеятся бесполезно, имхо. Там может быть "очень дорого и качественно" или "очень дорого и можно пользоваться".

1) Как у вас контроллируется, что код соответствует дизайну? Когда это проверяется? Кто на кого дефект открывает?
в процессе тестирования контроллируется, может тест кейсы вы тоже без документов пишете?

2) Вот у вас этот код, созданный по дизайн-документу попал в тестирование, и его автору пошли дефекты. "Кодер" каждый раз будет багу открывать, чтобы вы документ поправили, если исправление касается дизайна? А если он этого не сделает (а он не сделает) - как вы это проверите?
тест кейс создаётся на основании дизайна, если на этапе тестирования открывается дефект а оказывается что это правильно с точки зрения дизайна но неправильно с точки зрения тест кейса то дефект закрывается на основании "бай дизайн", меняется тест кейс так чтобы соответствовал дизайну. Иначе - это косяк кодера. Если у кодера есть притензии к дизайну - открывает дефекты или, как это нередко бывает, сам меняет, потому что сам его и писал.

3) Вот у вас этот код попал в эксплуатацию, и через год пришли дефекты, исправление которых требует изменения дизайна. Опишите подробно процедуру, которая гарантирует отражение этой правки в документе. Для исправлений дефектов и реализации фичреквестов вы тоже дизайн-документы писать будете, да? И открывать дефекты на эти документы?
Зависит от методологии. Если система сделано по дизайну, то это не дефекты а чендж реквесты. Если в рамках поддержки оказалось что в дизайне проблемы - естественно исправлять дизайн, он должен соответствовать системе.

Вот вы говорите год... а вы работали на проекте где разработка закончена 10 лет назад? При этом использован десяток разных технологий и пяток языков программирования?
Вот я вчера взяло документ написанный 7 лет назад. На основании этого документа сегодня можно сесть и написать ту же функциональность. Человек, который это писал (он же и кодировал) давно не работает в фирме, да что человек, того отдела давно не существует. А так я имую полную картинку. Вы пробовали работать в фирме в которой дизайн ведётся в одном месте, разработка во втором а тестирование в третьем? Я никогда не был в Индии или в США, я никогда не видел людей, которые делают то, что мне нужно. Я беру документы с других проектов, анализирую, если они мне подходят - беру код с этих проектов, иначе пришлось бы писать два раза.

"В мои планы не входит спорить с вашими ДОГМАМИ, и вас переубеждать. Я деже не буде комментировать вашу "методологию разработки" - хоть на голове пишите, это ваше дело. Я прояснил свою позицию. Чтобы ее понять, я написал достаточно."
вы просто скажите в каких методологиях вы работали? А то я вижу у вас вся карьера в фирмах до 50 работников, может вы и правда не знаете что такое методология и зачем она нужна. В таких маленьких фирмах она естественно не нужна, лишняя перегрузка. Ну разве что методология экстремального программирования.

"Поработайте с системой такого возраста и размера (сейчас в ней почти десяток миллионов строк кода), а потом я может быть послушаю ваше мнение о лени, бардаке, и о том, как весело кодеров от дизайнеров разделять."
пиписьками хотите померяться? Да вы крутой, и проекты у вас самые крутые в мире (аж с 10 миллионами строк, гыгыгыгыгы :), спорить не буду.

"религия денег", ага

Если так, то для тех, кто не метит в ее адепты, CMMI в целом бесполезны - что не мешает осторожному употреблению карго-артефактов или приспособлению отдельных практик.

Под "выбором" я имел в виду следующее. Любые изменения (в процессах, вообще в организации дел) должны проводится ради решения конкретных проблем и (или) улучшения имеющегося (в т.ч. предсказуемости каких-либо (!) показателей, примеры которых я и привел). И этот принцип должен действовать независимо от того, что из моделей, методологий вы собираетесь внедрять. Хоть CMMI, хоть Scrum, хоть XP, хоть еще чего.

Любые изменения сами по себе затратны. Но это, прежде всего, инвестиции, результат использования которых и надо потом определить. Если не оценить результат - это бессмысленные изменения. Если используете CMMI в качестве базы - определитесь: чего вы хотите добиться этим. Потом сопоставьте ожидаемые затраты и сопоставьте: дорого это или нет. Многое в затратах, связанных с внедрением CMMI, занимают официальные мероприятия и подготовка к ним. Если же официальный "публичный" рейтинг вам не важен, то затраты на внедрение будут не на много больше, чем любой другой методологии или модели.

В нашей "конторе" продукт успешно развивается с 90 года, и к коду возвращаются постоянно. Он - живой, и один и тот же. Поработайте с системой такого возраста и размера (сейчас в ней почти десяток миллионов строк кода), а потом я может быть послушаю ваше мнение о лени, бардаке, и о том, как весело кодеров от дизайнеров разделять.
Я сделаю попытку телепатии предыдущего комментатора.
Речь идёт о "конторах" где много мелких "бизнес-приложений" или "веб-сайтов".
Каждый разрабатываемый "веб-сайт" отличается от другого "веб-сайта" той же конторы всем, кроме программирования.
Чем отличительны эти компании?
* Большим количеством разработчиков.
* Большим количеством проектов.
* Отсутствием ярко выраженной тематики бизнеса - т.е. они делают "всё подряд".
* Даже если они делает не "всё подряд", то пересечения наблюдаются только в предметной области, используемых языках, инструментах и никогда - в дизайне или архитектуре
* Либо 90% разработчиков дешёвые и "заменяемые" а 10% "нужные", либо "дорогие" все, но на их эффективность всем положить прибор.

Писал с портрета двух компаний, одна очень мелкая, а другая очень крупная.
С мелкой сталкивается любой россияин, но не замечает её или не знает о ней, с крупной сталкивается почти любой пользовать PC

Threaded | Top-Level Comments Only

Page 4 of 5

Программистское мракобесие

no subject

no subject

no subject

no subject

Re: кстати

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Re: начальство -- дураки, занимаются дуростью

no subject

no subject

no subject

no subject

Re: pt. 2

no subject

no subject

Re: pt. 2