vit_r

Продавцы душ часто шакалят проекты. Обычно это идёт как «У нас замечательный, прекрасный, чудесный проект, только нам нужны отзывы о вашей работе. Дайте телефоны двух-трёх начальников...»

Но сегодняшний разговор уникален:
- Вы свободны?
- Ну, может быть, скоро и свободен.
- Вы делаете Х?
- Ну да, могу и Х.
- А у вас сейчас есть предложения?
- Ну да, с кем-то разговариваю, кто-то не подходит.
- А не могли бы вы то, что не подходит, мне прислать? У меня сейчас много-много студентов, на всё готовых.

И это при том, что социалистическая министерша тащит сейчас через утверждение закон, который фрилянсеров в Германии как класс уничтожит. Останутся только цеховые, которым льготы положены со средних веков.

Как сказал один из великих, «Любая плохо документированная технология неотличима от магии.»

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

Многочисленные проверки, изменения имени, прав и содержания ни к чему не привели. Пришлось лезть в код базовой библиотеки.

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

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

Если бы исходного кода не было, или если я был менее усердным, это нетривиальное решение так бы и осталось для меня загадкой.

Кстати, как подтвердил недавний эксперимент, только малая часть читателей, показанных местной статистикой, дочитывает до конца длинные посты.

Сегодня коллега из Индии уезжал домой. В смысле, ехал готовиться поступать доучиваться в Штаты. В прощальном письме стоит «И желаю огромного успеха этому проекту.»

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

Пожалуй, самый весёлый проект. По крайней мере, за много последних лет.

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

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

В таблице 7 строк со значением 666 в первом столбце то появляются, то исчезают. Разумных объяснений этому поведению найти не удалось. Документации, естественно, нет.

Написал клиенту, чтобы нашли шутников и спросили, что они этой нумерологией хотели сказать.

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

Ещё один текст на немецком. Так как вещи банальные и уже было, то без перевода. Немецкий не блестящий, просто как заготовка.

Standardisierung und andere Irrtümer im Outsourcing

( Read more... )

Есть такой замечательный тул DOORS фирмы Telelogic купленной фирмой Rational, которую в свою очередь купила IBM. Тул этот захватил почти весь рынок автоматизации сбора и контроля требований. Разработан он был в девяностых годах прошлого века и до сих пор поддерживает странную идеологию хранения данных. Знаменит тем, что программировать на нём можно только на языке DXL, ужаснее которого я не видел в этом веке, да, пожалуй, и в прошлом тоже.

Одна фирма, не будем показывать пальцем, но вполне понятно, кто там в Мюнхене из автомотива сидит... Так вот, одна фирма ищет ассенизатора.

Die durch DOORS generierte Datenmenge steigt beim Kunden stark an (verstärkte Nutzung, Erweiterung der Nutzergruppen, Baukasten-/ Masteransätze, Vernetzung von Anforderungsebenen).

In Summe existieren über 80.000 DOORS Module in ca. 2.000 DOORS-Projekten, (ein Großteil (ca. 75%) der Datenmenge wird von 1% der Module erzeugt).

У клиента DOORS порождает дикие объёмы данных. Сейчас в системе более 80 000 модулей в 2000 проектов. При этом 1% модулей занял около 75% объема памяти.

Задача, естественно, немного почистить.

Aufgaben:
=========
vertiefte inhaltliche Analyse der DOORS Datenbestände hinsichtlich

- Potenzialen zur Reduzierung des benötigten Speicherplatzes (Dateianzahl + Gesamtgröße) und Durchführung
- Daten-Redundanzen im Modul bereinigen
- Objekte, die gelöscht aber nicht gepurged sind (soft-deletes), endgültig löschen
- Große Dateianhänge (Hochauflösende Bilder; eingebettete Excel-Dateien, von denen nur Ausschnitte sichtbar sind etc.) in der Größe reduzieren
- Hohe Anzahl von Bildern und Anhängen reduzieren
- Nicht mehr benötigte Inhalte, (außer Archivierungswürdige und aktive Daten), identifizieren und bereinigen
- Nicht mehr benötigte Attribute und Attributinhalte bereinigen
- Reduktion der Gesamtdatenmenge ggf. durch Aufspaltung von Modulen
- Erarbeitung von Vorgehensweisen, um die pro Zeit notwendigen Baselines zu reduzieren
- Ableitung möglicher Reduzierungspotenziale unter Berücksichtigung der aus der Fachliche Analyse und IT Ansätze
- von Reduzierungspotentialen (semantisch)
- Regelbasiert, wenn möglich automatisierbare Ansätze mittels DOORS Skripten (DXL)
- Kontrolle und Dokumentation der Optimierungserfolge

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

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

Естественно, первым делом я полез в Гугл. Естественно, в первой же позиции он выдал мне ссылку на презентацию некой фирмы из Мюнхена о том, как они введут сейчас DOORS и как у них всё станет прекрасно.

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

Думаю, все уже прочитали эпический пост про программиста, пославшего нафиг подрядчиков с менеджерами и решившего всё запрограммировать самостоятельно, а также дискуссию по этому поводу у metaclass и в вечернем противогазе

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

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

Мой опыт показывает, что основная проблема в том, что из-за ошибочного отнесения программизма к точным наукам никто не понимает, как использовать математику.

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

Между тем, практически всегда можно найти метрики, которые дают однозначный ответ на поставленный вопрос. Нужно просто понять, чем измерять неизмеримое напрямую.

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

В принципе, в этом нет ничего сложного. Так создают статьи в биологии, психологии или экономике. Нужно просто правильно поставить вопрос и посмотреть, где копать.

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

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

Добавлю из комментариев к теме на которую ссылается вчерашний пост.

Про экспертов и гур

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

Берём с полки «Quality is free» by Philip B Crosby (между прочим, год публикации 1980), открываем страницу 32 и смотрим названия столбцов для пяти этапов: Uncertainity, Awakening, Enlightment, Wisdom, Certainity.

Открываем известный стандарт. Читаем название пяти медалек: Initial, Repeatable, Defined, Quantitatively Managed, Optimizing.

Уже по использованным словам понятно, что сделано для людей, а что для того, чтобы вынимать у них деньги.

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

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

• - The output is garbage: each third record is wrong.
• - Why garbage? Two thirds of values are correct.

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

Про mission critical и теорию вероятности

Секрет mission critical софтопроизводства в том, что разницу между софтом с надёжностью 0.9999 и 0.999 невооружённым взглядом заметить сложно.

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

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

Люди талантливые и заинтересованные в своём развитии стараются найти что-то поинтереснее.

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

И крутые архитекторы с сеньёр-программистами считающие, что система с ярлычком "реалтайм" сама всё сделает, и не имеющие ни малейшего представления о происходящем внутри. Да что там, просто не способные понять тест с multithreading. Помнится, на первом же полевом испытании их система впала в нирвану...

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

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

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

По сообщениям в прессе через несколько лет они имели много интересных проблем с качеством. Не смотря на современнейшие методики дизайна. (Я обнаружил в папке с документацией пару студенческих и аспирантских статей, которыми эксперт и его помощник научно доказали менеджменту полезность и огромные перспективы метода. Но кто же сомневается, что методика работает, если про её крутость написано в журнале.)

Естественно, при всём бардаке и бреющем полёте мысли большинства разработчиков они потом берут свои три девятки бесконечным тестированием или сотнями румын (или и тем и другим сразу). Но на то, что у этого софта внутри, лучше не смотреть.

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