Убей в себе IT-шника

[singalen]

Придумал доклад-статью. Мыслей крутилось много, но как начал записывать - они куда-то схлынули, осталось немного флуда.

Коллеги, Вы замечали неудачные паттерны мышления, свойственные в основном айтишникам? Типа неспособности ориентироваться в нечёткой логике.

Если можно, с примерами и своими соображениями :) А я вас в докладе использую :)

Под катом мои соображения.

Существует “правильный” способ делать что угодно

Конечно, способ складывать 2 и 2 существует только один. Не существует даже таких технических вещей, как “единственно правильный” язык программирования, фотоаппарат, автомобиль. И уж тем более не бывает единственно правильного устройства таких гуманитарных конструкций, как работа, бизнес, человеческое общество.

Яркий пример - какой-то IT-шник на политическом форуме высокомерно заявил о человеческом обществе: “Возможно построить надёжную систему из ненадёжных элементов - читайте фон Неймана”. Сам он его если и читал, то явно не понял. Из ненадёжных элементов, может, и можно - если эти элементы не анализируют саму систему, не выискивают в ней слабину и не занимаются активным противодействием.

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

Interactions over processes and tools. Почему так сказали? Потому, что люди а) должны помогать друг другу выполнять обязанности, и б) зоны ответственности должны перекрываться. В ситуации “Ты не сделал отчёт”, например, следует сказать “Я не напомнил тебе сделать отчёт”.

Если Вам нужно абсолютно чёткое разделение ответственности - значит, у вас конфликт вроде “- Ты не то делаешь! - Нет, это ты не то делаешь!”. Значит, у вас неэффективный контакт с коллегой/ заказчиком/ начальством, вам нужна какая-то документально закреплённая защита.

Может статься, что инструкцию напишут. И тут оказывается, что по инструкции Вы отвечаете за примерно в пять раз большую зону, чем Вам сейчас кажется. Скажем, за покрытие тестами. А как его сделать, если времени на тесты не дают? Идиотская инструкция! Неправильная!

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

Твитнуто Фаулером: There is an (unfortunate) belief that testers test, programmers code, and the separation of the two disciplines is important.
Документация всех спасёт. Аналитик должен делать правильные документы/(требования), тогда программисту всё будет понятно.

Миф происходит из 1) нежелания вступать в общение, 2) желания переложить ответственность на другого (мы всё делаем, как вы сказали!)

Никто и никогда не может дать полных и непротиворечивых требований на мало-мальски нетривиальную систему.

Порой понять, что от вас хотят, можно только долго общаясь об этом. Фиксируя знания и решения в документации, конечно. Но документация - это не главный инструмент, это - блокнот для памяти. Главный результат - понимание - рождается в общении. Документация - однородный документ, по нему не видно, что для заказчика важно, а что нет. Часто он сам этого не понимает.

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

Синдром всезнайки

Считает, что если он понял некий общий принцип, то понял всю дисциплину - например, изучил новый фреймворк. “Всё понятно, это как Rails, только на Java”.
И ещё считает возможным поучать других с высоты своего космического понимания. Если он довольно логичен и проворно пользуется гуглом, то такого “Гуглоневежду” бывает довольно трудно уличить в незнании. Помогает прямой вопрос - а что сделал ты.
В то время, как devil in details. “Принципы” - это только модели, а на практике важны различия между моделями и реальностью. “Теоретически, между теорией и практикой нет разницы; на практике, она есть”.

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

Comments

[johndegree.livejournal.com]

я по роду деятельности интересовался этой темой. мой вывод - изучение точных наук ведет к развитию избыточной прямолинйности мышления.(В этом предложении не рекурсия, это самоирония :). В особо запущенных случаях все усугубляется поведенческим паттерном "hit and run".
Но, с другой стороны, стоит отметить что отчасти именно благодаря таким образу мышления и поведения наша индустрия достаточно быстро прогрессирует.

[singalen]

Слабую коммуникативную функцию не забыть.

[profuel.livejournal.com]

из недавнего — TestDriven разработка.
Убивает напрочь желание подумать, прежде чем сделать. В итоге — код пояляется по строчке в минуту, при нереальном количестве прогонов/тестов.
“Не трогай” — неплохой принцип, но во мне еще жив немного математик, и я примерно 50/50 трогаю или нет :)
Более общий пример — “я лучше сделаю это сам, чем возьму готовое и допилю”. Зависимость потерь имеет степенную зависимость от сложности задачи, а порой и приводит к краху.

В том направлении изыски?

[mapm.livejournal.com]

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

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

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

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

[klizardin.livejournal.com]

"неуверенность в своих силах"

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

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

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

[arumad.livejournal.com]

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

[stahman.livejournal.com]

1) Чудовищный оптимизм. IT-шник с трудом принимает факт, что люди будут действовать не только во вред окружающим, но и во вред себе.
2) Инженерный рефлекс, на базе опыта: если что-то сделать нетак, плохо, оно или сломается или будет масировано мешать. По этому внутреннее чувство достоверности и надёжности/халтурности, которое мешает воспринимать поведение окружающих и нетехничных сфер, строящееся от прокида или просто лжи.