vit_r (vit_r) wrote,
vit_r
vit_r

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

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



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

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

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

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

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

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

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

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

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

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

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

В этом свете очень крут небезызвестный питерский профессор из ИТМО, выдающий древние методики конечных автоматов за откровения свыше и этим убеждающий талантливых и перспективных студентов в том, что они находятся на передовом крае науки. По крайней мере, в любой области, вне зависимости от модности методологии производства, крутости названия, бюджета и сертификатов, качество определяется тем, есть ли мозги у пишущих код людей, и умеют ли они ими пользоваться.
Tags: business_tales, economics, freelancer, management, qa, quality, re, ru
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 5 comments