Совсем свежая история. Есть некий сервис, который изначально разрабатывался для работы только в защищенном окружении, причем не только программном, и т.с. человеческом. Для такого решения имелись все разумные основания, т.к. сервис делался для очень специфичных задач, работать с которыми должен был «отфильтрованный» персонал. Иными словами с самого начала было четко определено, что
— сервис будет работать только в отдельном сегменте внутренней сети, за всеми возможными защитами
— доступ с сети и сервису будут иметь только строго определенные люди, надежность которых принимается равной 100%
Это решение позволило сэкономить массу времени на дизайне и разработке, т.к. вся «защита» была сделана в виде простейшей парольной системы, смысл которой был не в самой защите от чего-либо злонамеренного, а в ограничении возможных действий пользователя. Просто как предохранитель, чтобы пользователь по недомыслию или из-за незнания не сделал чего-либо, что ему делать не надо. Все было отлично, заказчик был доволен, система работала несколько лет без всяких нареканий.
Потом в результате некоторых процессов проект перешел в другие руки, и новый руководитель захотел, чтобы система была видна снаружи и доступ к ней мог получить любой, у кого есть соответствующие логин/пароль. После чего он вышел с предложением (барабанная дробь) добавить к сервису модуль безопасности, чтобы его можно было выставить напрямую в интернет. Никакие объяснения, что для этого надо переделывать весь дизайн проекта фактически с нуля, понимания не находили.
Из моего личного опыта: наиболее далекий от ИТ человек, которого я выучил на программиста: медбрат с нулевым знанием (в момент начала обучения) английского. Кому-то, безусловно, программирование дается легче, кому-то сложнее, кому-то очень сложно, но после того случая я не верю, когда мне говорят, что "программирование не для всех", что "не мое" и т.п. Это - не так. Просто большинству придется прикладывать гораздо больше усилий, чтобы стать программистом. И они им станут. Да, не супер-звездой, но все равно обычным хорошим программистом. В СССР был тренер по спортивной гимнастике, который говорил: "Мастера Спорта я сделаю из любого, кто этого очень хочет, а вот чтобы идти дальше уже нужен талант."
Как было сказано в бессмертной классике: ничего личного, просто бизнес. Далее будет режим КЭПа
имеем массу не-ИТ народа, которая читает о уровне оплаты в ИТ. Причем уровни джуна и мидла пропускаются, а в голове остается оплата преимущественно на уровне сеньора
имеем массу народа, которая читает о дефиците кадров в ИТ
вышеупомянутый народ складывает два + два, и начинает искать способы тоже стать ИТ-шником с такими же суммами оплаты.
Далее приходит КЭП и начинает рассказывать, что если есть рынок спроса, то мгновенно образуется рынок предложения. Что заработать хотят многие, а квалификацию для этого имеют единицы (причины такого весьма подробно описаны автором), и что задача курсов (тут КЭП окончательно входит в раж) - не научить чему-нибудь, а продать курсы. Побочным эффектом, стимулирующим все вышеописанное, является весьма плачевное у многих знание английского языка, что не позволяет использовать огромный объем существующих англоязычных видео- и текстовых обучающих материалов, по которым можно научиться вообще без курсов. Поэтому результат другим быть не может по определению: человек приходит на курсы с представлениями о оплате на уровне сеньора после обучения за пару месяцев, и ему именно это там и рассказывают, т.к. именно это он хочет слышать, иначе он не пойдет курсы. Точнее пойдет но на другие, где ему расскажут то, что он хочет слышать.
Спасибо за мнение. Вы осуждаете читабельность и поддерживаемость кода.
Потому что читабельность и поддерживаемость кода важнее всего. Читабельный код можно отрефакторить, добавить новые фичи и т.д. В нечитабельном коде это ходьба по минному полю без миноискателя. У меня впечатление (возможно ошибочное), что вы очень недооцениваете фактор поддерживамости (по сути читабельности и понятности) кода. Никто не будет читать непонятный, переусложенный код. А уж копирование метода целиком ради одного инкремента — вообще за гранью. Есть множество проектов, которые поддерживаются и развиваются даже не годами, а десятилетиями. И видеть там такой код — это последнее, что хочется девелоперу.
Но не забывайте, заказчик особо обратил внимание на эффективность по производительности и памяти.
Тут сразу два момента:
— во-первых, не забываем старое, доброе правило за авторством Скотта Майерса (или Дональда Кнута? Точно к сожалению не помню): не проводите оптимизацию в ущерб качеству (т.е. читабельности и поддерживаемости) кода, пока тесты не показали явным образом, где и что нужно оптимизировать.
— во-вторых, предположу с вероятностью 99%, что под «не использовать много памяти и ресурсов даже тогда, когда в расписании задано много значений» подразумевалось не создавать в памяти 100500 объектов по одному объекту для каждого для каждого подходящего момента времени. Т.е. имелось в виду, что если вам нужно, например, создать расписание на день каждые 10 миллисекунд, то не городить в памяти 24*60*60*100 = 8640000 объектов, которые сожрут всю память., а при поиске подходящего момента в расписании, соответственно, проверять все эти 100500 объектов, что в свою очередь скорее всего сожрет процессор. Этот вариант с огромной вероятность напишет джун, и именно этот вариант кампания явно не хотела бы видеть в решении теста.
Пришлось идти на некоторый компромисс и кое где пожертвовать читабельностью. Я считаю, что читабельность пострадала не сильно. Но точно сказать это можно будет только при сравнении с другой реализацией.
Читабельность пострадала ужасно. Код вообще нечитабелен. Чтобы понять, что делает вся эта орда вложенных if-ов, нужно сидеть и минут 10 — 15 вникать в код. Если бы вы вместо этого написали а-ля что-то вот такое, код был бы читабелен. А пирамида вложенных if-ов нечитабельна в принципе
Почему на мой взгляд обозвали халтурой.
— такое количество вложенных if-ов невозможно нормально читать
— такое количество вложенных if-ов невозможно нормально поддерживать. Вероятность ошибки при модификации такого кода, написать не то и не в тот else крайне высока
— Методы NearestEvent и NearestPrevEvent различаются ровно в одной строке: millisecond--; и millisecond++; Т.е. имеем чистейшее, незамутненное Copy-Paste в методе на 64 строки к тому же еще и крайне малопонятного кода.
Т.е. скорее всего по мнению проверяющего автор наворотил код побыстрее, да к тому же еще и скопировал метод ради одной измененной строчки, чтобы не возиться. Выглядит, действительно, как халтура за 15 минут на коленке по принципу «лишь бы запустилось»
Почти мой недавний пример :) Баг воспроизводился только у заказчика, причем стабильного алгоритма воспроизведения не было, проявлялся случайным образом от одного — двух раз в день и до паузы в пару месяцев. Появлялся только на боевой системе, на тестовой системе не появлялся ни разу, конфигурация и т.п., разумеется, были проверены в первую очередь еще заказчиком и были абсолютно идентичны
Потратил на поиски больше недели. Фикс занял 6 строк кода. По KPI я получился бы лентяем, который вообще ничего не делал.
Если это действительно так, то получаются два полностью противоположных утверждения. С одной стороны есть заявление, что: «Строительство собственной станции обусловлено выходом России из проекта МКС, который, в свою очередь, связан с ухудшением технического состояния российского сегмента станции», а с другой на основе этого же самого сегмента будут строить новую станцию? Или сегмент в таком состоянии, что его нельзя использовать для будущей станции, или он в нормальном состоянии, но тогда получается, что первое заявление является враньем. Если я что-то не так понял, просьба меня поправить.
Первый пункт относится непосредственно к инфраструктуре и он вполне решаем.
Неверно. Оутсорс пишет для всех подряд, и его разработчики физически не имеют времени и возможности изучать производственное окружение всех заказчиков.
2,3 пункт относятся к разработке, за них ничего не могу сказать.
Задача оутсорса — продать проект. Не написать проект поддерживаемым, развиваемым и т.д., а продать как можно скорее. Поэтому любые решения в пользу времени и удешевления в ущерб качеству кода, поддерживаемости т.д. будут вынесены в пользу времени и удешевления. В результате у заказчика на руках то, что обычно называется говно-код. При этом переход на другой оутсорс / свою команду при работе с таким кодом требует переписывания проекта, т.к. разбираться в том, что там наворочено, получается по времени и затратам сопоставимым с написанием нового.
4 пункт — опять же плохой аутсорс, договор подписывается на берег и не меняется в процессе.
Вы не совсем поняли, что я имел в виду. Разумеется, договор подписывается на берегу. Но это хорошо, пока заказчику потом ничего не нужно развивать. А вот если потом у заказчика появляются новые пожелания, вот тут начинается цирк. Почему я и писал выше, что для прототипа и т.п. одноразовых проектов, где в первую очередь важны время и цена, оутсорс оправдан. А вот для долговременной разработки — нет, не оправдан.
5 — опять к разработке.
У меня такое впечатление, что вы отмахиваетесь от проблем с разработкой, как от чего-то маловажного. Это неверно. Если у вас есть проблемы с разработкой, они потом вылезут в проблемах со всем остальным.
Если вдуматься в причины, которые называет бизнес, когда сталкивается с аутсорс компаниями, то никто из них не может сформулировать конкретные поинты, из-за которых они не готовы сотрудничать с аутсорсом. Если, конечно, это не вопрос цены.
Это неизвестно не бизнесу, а автору статьи. У оутсорса (если только речь не о прототипах на коленке для проверки идей) вагон недостатков. Например:
незнание разработиками производственного окружения, для которого разрабатывается проект
отсутствие контроля качества кода со стороны заказчика
огромные пробемы с продолжением разработки при смене оутсорсера или переходе на собственную команду
зависимость заказчика от финансового положения оутсорсера и его аппетитов
проблемы с отладкой невоспроизводимых на стороне разработчика ошибок
Статья рекламная настолько (или понимание темы отсуствует настолько), что по другому быть не может. По линку на опрос первый же вопрос "Готовы ли вы отдать свою инфраструктуру на аутсорс?" Варианты ответов:
Да, я не вижу ничего страшного в аутсорсе, за ним будущее
— это 100500 макросов на горячие клавиши (я пользуюсь меню наверное пару раз в неделю),
— это дополнительные (и опять же настроенные под себя) внешние инструменты а-ля ReSharper, менеджер буфера обмена и т.п.
— это настроенное под себя расположение окон, иконок, меню, цветовая гамма, шрифт и т.д.
Если мне дать стандартную конфигурацию VS по умолчанию, и попросить там что-то сделать, я конечно что-то сделаю, но гораздо медленнее и с жуткими неудобствами для себя.
Это мне напомнило шутку студенческого театра при МФТИ «Мощность реактивного двигателя определяется формулой P = k … T, где Т — температура. Но у ваккума нет температуры — значит Т — время!»
Вы не поверите, но к сожалению это — ни разу не шутка. Мне лично как-то на полном серьезе доказывали, что в формуле зависимости расстояния / скорости / времени нет расстояния. С офигевшим видом пишу v=s/t и спрашиваю, где же здесь нет расстояния, а если нет, то что же такое s? Ответ был настолько гениальным, что я не нашел, что на него возразить, но навсегда запомнил: «V — это velocity, S — это speed, T — это Time. Нет здесь никакого расстояния!»
дело в том, что формула e=mc2 очень похожа на форму площади круга, s=Pi*r2, возможно это просто совпадение, но мне так не кажется, правильней, на мой взгляд, было бы считать энергию по форму площади шара (сферы)
А если взять параллелепипед с одинаковыми шириной и длиной, которые мы обозначим как «c» и высотой, которую мы обозначим как «m», то нас ждет открытие мирового уровня: объем параллелепипеда с одинаковыми шириной и длиной вычисляется по абсолютно той же той же самой формуле v=mc2 Я требую немедленно выдать мне нобелевскую премию за это эпохальнешее открытие, т.к. только что доказал, что энергия вычисляется как объем параллелепипеда
Тут пропущена очевидная для многих фраза (я ее выделил) «Закрыть компанию по решению суда удалось...»
Полиция не имеет никаких прав прийти и закрыть кампанию, потому что ей так захотелось. Просто написано очень коряво, но имелось в виду, что полиция получила данные о возможной причастности кампании к наркоторговле, начала кампанию разрабатывать, получила доказательства, что кампания вообще и руководитель в частности причастны к этому, далее суд, арест руководителя и закрытие кампании по решению суда.
Вы путаете суд и оперативно-следственные мероприятия. Если полиция узнает через своего информатора / подосланного сотрудника и т.п., что Вася продает наркотики, то ни один вменяемый суд не примет обвинение на основании только того, что кто-то что-то где-то слышал. Но этой информации может быть достаточно, чтобы полиция начала в отношении Васи следственные мероприятия, действительно ли он торгует, или это были просто чьи-то фантазии. И только если в результате будут обнаружены доказательства, что Вася торгует, вот тогда Васю ждет разбирательство в суде.
Чтобы определить, является дискуссия оффтопиком или нет, нужно сначала дослушать выступающего до конца. А это уже отнимает время.
Смотря, что человек говорит. Обычно не нужно слушать совсем до конца, чтобы понять, что именно человек хочет сказать.
Роль модератора полезная, но недостаточная, нужно еще и само-модерацией заниматься.
В идеальном варианте — да, но не всегда получается. Если человек действительно увлечен излагаемой идеей, и считает ее важной, то он вполне может потерять контроль.
Отличный пример, почему разработчикам нужны так многими нелюбимые (если не ненавидимые) софт-скиллы. Тут надо еще отметить, что под софт-скиллами многие понимают только умение говорить — иными словами правильно донести свою аргументацию до противоположной стороны. Между тем в статье нагляднейше показано, что софт-скиллы — это не только умение говорить, но и не менее важное умение слушать, что тебе говорят окружающие.
Тут-то до меня и дошло – смысла поднимать эту тему на митинге не было вообще никакого, потому что обсуждавшиеся там планы лишь слегка пересекались с нашим техдолгом и мое внимание к ним просто зря потратило время всех участников
А вот здесь возникает вопрос, почему совещание не модерировалось. Нужен кто-то, кто будет жестко удерживать собравшихся в рамках заранее определенной темы. Почему человека не остановили в самом начале, сказав, что поднимаемая им тема не относится к заранее заявленной?
Опять же, при Warmmiete в 800 евро в Германии заплатить кауцион в 2800 никак не получится
Что интересно, согласно Гуглу (см. линк) в Австрии тоже не получится (выделение мое). Откуда взялась идея про фиксированный залог в 2800 евро — это надо спрашивать у автора. Там, вероятно, были какие-то особенности снимаемого жилья.
Wie hoch darf eine Kaution sein?
Grundsätzlich ist die Höhe der Kaution Vereinbarungssache. Marktüblich sind drei Bruttomonatsmieten. Bis zu sechs Monatsmieten wären jedoch auch zulässig. Eine höhere Kaution ist nur bei einem besonderen Sicherstellungsinteresse des Vermieters zulässig, ausschlaggebend sind hierbei die Höhe des Mietzinses, die Bonität des Mieters, die Ausstattung des Mietobjekts oder die Zurverfügungstellung von Einrichtungsgegenständen.
— сервис будет работать только в отдельном сегменте внутренней сети, за всеми возможными защитами
— доступ с сети и сервису будут иметь только строго определенные люди, надежность которых принимается равной 100%
Это решение позволило сэкономить массу времени на дизайне и разработке, т.к. вся «защита» была сделана в виде простейшей парольной системы, смысл которой был не в самой защите от чего-либо злонамеренного, а в ограничении возможных действий пользователя. Просто как предохранитель, чтобы пользователь по недомыслию или из-за незнания не сделал чего-либо, что ему делать не надо. Все было отлично, заказчик был доволен, система работала несколько лет без всяких нареканий.
Потом в результате некоторых процессов проект перешел в другие руки, и новый руководитель захотел, чтобы система была видна снаружи и доступ к ней мог получить любой, у кого есть соответствующие логин/пароль. После чего он вышел с предложением (барабанная дробь) добавить к сервису модуль безопасности, чтобы его можно было выставить напрямую в интернет. Никакие объяснения, что для этого надо переделывать весь дизайн проекта фактически с нуля, понимания не находили.
Из моего личного опыта: наиболее далекий от ИТ человек, которого я выучил на программиста: медбрат с нулевым знанием (в момент начала обучения) английского. Кому-то, безусловно, программирование дается легче, кому-то сложнее, кому-то очень сложно, но после того случая я не верю, когда мне говорят, что "программирование не для всех", что "не мое" и т.п. Это - не так. Просто большинству придется прикладывать гораздо больше усилий, чтобы стать программистом. И они им станут. Да, не супер-звездой, но все равно обычным хорошим программистом. В СССР был тренер по спортивной гимнастике, который говорил: "Мастера Спорта я сделаю из любого, кто этого очень хочет, а вот чтобы идти дальше уже нужен талант."
Как было сказано в бессмертной классике: ничего личного, просто бизнес. Далее будет режим КЭПа
имеем массу не-ИТ народа, которая читает о уровне оплаты в ИТ. Причем уровни джуна и мидла пропускаются, а в голове остается оплата преимущественно на уровне сеньора
имеем массу народа, которая читает о дефиците кадров в ИТ
вышеупомянутый народ складывает два + два, и начинает искать способы тоже стать ИТ-шником с такими же суммами оплаты.
Далее приходит КЭП и начинает рассказывать, что если есть рынок спроса, то мгновенно образуется рынок предложения. Что заработать хотят многие, а квалификацию для этого имеют единицы (причины такого весьма подробно описаны автором), и что задача курсов (тут КЭП окончательно входит в раж) - не научить чему-нибудь, а продать курсы.
Побочным эффектом, стимулирующим все вышеописанное, является весьма плачевное у многих знание английского языка, что не позволяет использовать огромный объем существующих англоязычных видео- и текстовых обучающих материалов, по которым можно научиться вообще без курсов.
Поэтому результат другим быть не может по определению: человек приходит на курсы с представлениями о оплате на уровне сеньора после обучения за пару месяцев, и ему именно это там и рассказывают, т.к. именно это он хочет слышать, иначе он не пойдет курсы. Точнее пойдет но на другие, где ему расскажут то, что он хочет слышать.
Потому что читабельность и поддерживаемость кода важнее всего. Читабельный код можно отрефакторить, добавить новые фичи и т.д. В нечитабельном коде это ходьба по минному полю без миноискателя. У меня впечатление (возможно ошибочное), что вы очень недооцениваете фактор поддерживамости (по сути читабельности и понятности) кода. Никто не будет читать непонятный, переусложенный код. А уж копирование метода целиком ради одного инкремента — вообще за гранью. Есть множество проектов, которые поддерживаются и развиваются даже не годами, а десятилетиями. И видеть там такой код — это последнее, что хочется девелоперу.
Тут сразу два момента:
— во-первых, не забываем старое, доброе правило за авторством Скотта Майерса (или Дональда Кнута? Точно к сожалению не помню): не проводите оптимизацию в ущерб качеству (т.е. читабельности и поддерживаемости) кода, пока тесты не показали явным образом, где и что нужно оптимизировать.
— во-вторых, предположу с вероятностью 99%, что под «не использовать много памяти и ресурсов даже тогда, когда в расписании задано много значений» подразумевалось не создавать в памяти 100500 объектов по одному объекту для каждого для каждого подходящего момента времени. Т.е. имелось в виду, что если вам нужно, например, создать расписание на день каждые 10 миллисекунд, то не городить в памяти 24*60*60*100 = 8640000 объектов, которые сожрут всю память., а при поиске подходящего момента в расписании, соответственно, проверять все эти 100500 объектов, что в свою очередь скорее всего сожрет процессор. Этот вариант с огромной вероятность напишет джун, и именно этот вариант кампания явно не хотела бы видеть в решении теста.
Читабельность пострадала ужасно. Код вообще нечитабелен. Чтобы понять, что делает вся эта орда вложенных if-ов, нужно сидеть и минут 10 — 15 вникать в код. Если бы вы вместо этого написали а-ля что-то вот такое, код был бы читабелен. А пирамида вложенных if-ов нечитабельна в принципе
— такое количество вложенных if-ов невозможно нормально читать
— такое количество вложенных if-ов невозможно нормально поддерживать. Вероятность ошибки при модификации такого кода, написать не то и не в тот else крайне высока
— Методы NearestEvent и NearestPrevEvent различаются ровно в одной строке: millisecond--; и millisecond++; Т.е. имеем чистейшее, незамутненное Copy-Paste в методе на 64 строки к тому же еще и крайне малопонятного кода.
Т.е. скорее всего по мнению проверяющего автор наворотил код побыстрее, да к тому же еще и скопировал метод ради одной измененной строчки, чтобы не возиться. Выглядит, действительно, как халтура за 15 минут на коленке по принципу «лишь бы запустилось»
Потратил на поиски больше недели. Фикс занял 6 строк кода. По KPI я получился бы лентяем, который вообще ничего не делал.
Неверно. Оутсорс пишет для всех подряд, и его разработчики физически не имеют времени и возможности изучать производственное окружение всех заказчиков.
Задача оутсорса — продать проект. Не написать проект поддерживаемым, развиваемым и т.д., а продать как можно скорее. Поэтому любые решения в пользу времени и удешевления в ущерб качеству кода, поддерживаемости т.д. будут вынесены в пользу времени и удешевления. В результате у заказчика на руках то, что обычно называется говно-код. При этом переход на другой оутсорс / свою команду при работе с таким кодом требует переписывания проекта, т.к. разбираться в том, что там наворочено, получается по времени и затратам сопоставимым с написанием нового.
Вы не совсем поняли, что я имел в виду. Разумеется, договор подписывается на берегу. Но это хорошо, пока заказчику потом ничего не нужно развивать. А вот если потом у заказчика появляются новые пожелания, вот тут начинается цирк. Почему я и писал выше, что для прототипа и т.п. одноразовых проектов, где в первую очередь важны время и цена, оутсорс оправдан. А вот для долговременной разработки — нет, не оправдан.
У меня такое впечатление, что вы отмахиваетесь от проблем с разработкой, как от чего-то маловажного. Это неверно. Если у вас есть проблемы с разработкой, они потом вылезут в проблемах со всем остальным.
Это неизвестно не бизнесу, а автору статьи. У оутсорса (если только речь не о прототипах на коленке для проверки идей) вагон недостатков. Например:
незнание разработиками производственного окружения, для которого разрабатывается проект
отсутствие контроля качества кода со стороны заказчика
огромные пробемы с продолжением разработки при смене оутсорсера или переходе на собственную команду
зависимость заказчика от финансового положения оутсорсера и его аппетитов
проблемы с отладкой невоспроизводимых на стороне разработчика ошибок
Статья рекламная настолько (или понимание темы отсуствует настолько), что по другому быть не может. По линку на опрос первый же вопрос "Готовы ли вы отдать свою инфраструктуру на аутсорс?" Варианты ответов:
Да, я не вижу ничего страшного в аутсорсе, за ним будущее
Другое
Сразу вспомнился известный анекдот про
Да, не возражаю.
Нет, не возражаю
— это дополнительные (и опять же настроенные под себя) внешние инструменты а-ля ReSharper, менеджер буфера обмена и т.п.
— это настроенное под себя расположение окон, иконок, меню, цветовая гамма, шрифт и т.д.
Если мне дать стандартную конфигурацию VS по умолчанию, и попросить там что-то сделать, я конечно что-то сделаю, но гораздо медленнее и с жуткими неудобствами для себя.
Вы не поверите, но к сожалению это — ни разу не шутка. Мне лично как-то на полном серьезе доказывали, что в формуле зависимости расстояния / скорости / времени нет расстояния. С офигевшим видом пишу v=s/t и спрашиваю, где же здесь нет расстояния, а если нет, то что же такое s? Ответ был настолько гениальным, что я не нашел, что на него возразить, но навсегда запомнил: «V — это velocity, S — это speed, T — это Time. Нет здесь никакого расстояния!»
А если взять параллелепипед с одинаковыми шириной и длиной, которые мы обозначим как «c» и высотой, которую мы обозначим как «m», то нас ждет открытие мирового уровня: объем параллелепипеда с одинаковыми шириной и длиной вычисляется по абсолютно той же той же самой формуле v=mc2 Я требую немедленно выдать мне нобелевскую премию за это эпохальнешее открытие, т.к. только что доказал, что энергия вычисляется как объем параллелепипеда
Полиция не имеет никаких прав прийти и закрыть кампанию, потому что ей так захотелось. Просто написано очень коряво, но имелось в виду, что полиция получила данные о возможной причастности кампании к наркоторговле, начала кампанию разрабатывать, получила доказательства, что кампания вообще и руководитель в частности причастны к этому, далее суд, арест руководителя и закрытие кампании по решению суда.
Смотря, что человек говорит. Обычно не нужно слушать совсем до конца, чтобы понять, что именно человек хочет сказать.
В идеальном варианте — да, но не всегда получается. Если человек действительно увлечен излагаемой идеей, и считает ее важной, то он вполне может потерять контроль.
А вот здесь возникает вопрос, почему совещание не модерировалось. Нужен кто-то, кто будет жестко удерживать собравшихся в рамках заранее определенной темы. Почему человека не остановили в самом начале, сказав, что поднимаемая им тема не относится к заранее заявленной?
Что интересно, согласно Гуглу (см. линк) в Австрии тоже не получится (выделение мое). Откуда взялась идея про фиксированный залог в 2800 евро — это надо спрашивать у автора. Там, вероятно, были какие-то особенности снимаемого жилья.
mietervereinigung.at/News/841/38065/Kaution-Die-wichtigsten-Fragen-und-Antworten