Как честный человек, публикую три закона Вейцмана

[beldmit]

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

Мое мнение по данному вопросу может не совпадать с мнением Бориса. А может совпадать.

© Борис Вейцман

Наиболее удобная форма дискуссий -- листы, можно с архивом в WWW. Наименее удобная -- ЖЖ. Но за долгие годы я сформулировал для себя три закона, которым я хочу дать своё имя.

Итак, три закона Вейцмана:

Закон 1. Если есть несколько способо решить какую-либо задачу при помощи компьютера, то люди неизменно выбирают наименее удобный, наименее надёжный и наименее пригодный к решению задачи способ. Когда речь идёт о компьютере, люди неизменно забивают гвозди отверткой, а шурупы вкручивают плоскогубцами.

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

Закон 3. Когда люди выбирают неудобный способ, они обычно ссылаются на лёгкость в обучении. Более удобный способ надо изучать час, а менее удобный -- десять минут. Однако вскоре выясняется, что без набора финтифлюшек из Закона 2 менее удобный способ использовать нельзя. Поскольку финтифлюшки писались как заплатки, без логики и понимания, на их изучение надо потратить куда больше часа. Появляются Маги и Волшебники неудобного способа, знающие Секретные Танцы С Бубном, Которые Иногда Работают. Преподавание неудобного способа (т.е. Танцев С Бубном) становится важной отраслью компьютерной промышленности.

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

Comments

[balagur.livejournal.com]

Алекс, ты не прав.

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

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

Собственно, мне кажется, что в описании ты смешал зеленое со сладким. Методика разработки и методика внедрения - разные вещи.

[alexkuklin.livejournal.com]

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

[balagur.livejournal.com]

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

[alexkuklin.livejournal.com]

Сложность их решения уже сравнима со сложностью изменения системы работы больших неповоротливых структур.

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

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

кто бы спорил, но это нужно в любом случае.

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