Июнь 14, 2009

Супер Идея как фетиш

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

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

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

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

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

Представье провинциальную Америку середины прошлого века – все эти патриархальные небольшие городки, в которых жизнь плавно течет со скоростью полуденного зноя (аналоги наших Мышкиных и Мухосрансков). Совершенно провальная, на первый взгляд, идея создания в таких городках полноценных супермаркетов с полным ассортиментов сделала Сэма Уолтона одним из богатейших людей мира. Значительно позже было немало попыток клонирования сети Wal-Mart, но превзойти Сэма пока не удалось никому.

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

Не уверен, что кто-то видел какое-то серьезное будущее за компанией Microsoft, которая начала свой бизнес с реализации языка программирования Basic для одного из первых микрокомпьютеров. По жалобам самого Билла Гейтса, в то время они со вторым основателем работали фактически на энтузиазме, получая всего 2 доллара в час (сейчас обычный наемный разработчик приличного уровня получает около $50). Если бы Билл вместо того, чтобы действовать, ожидал снисхождения Гениальной Идеи для бизнеса, он бы не стал к настоящему моменту самым богатым человеком планеты, бессменно руководя компанией с оборотом под 300 млрд. долларов.

А помните потрясную идею нового транспортного средства Segway? В начале 2000х о нем восторженно писали даже в России. Тот самый Стив Джобс (основатель и директор компании Apple) признался в интервью Time, что ожидает от этой штуковины такого же прорыва, какой в свое время сделали первые персональные компьютеры. Увы, прошло без малого десять лет, а продажи “сегвея” буксуют, ежегодно продается не более 10,000 единиц (продажи даже нашего АвтоВАЗа составляют значительно более полумиллиона единиц автомобилей). Увы, ожидаемой революции так и не произошло.

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

Таким образом, отличная Идея не только не гарантирует, что ваш проект в итоге “выстрелит”, она даже не гарантирует вам быстрого старта и скорой прибыли. Пока конкуренция в России практически во всех нишах еще далека от западной, и проекты, не приносящие десятки и сотни процентов ROI, явно не в фаворе у наших предпринимателей. Однако вскоре рынок насытится, и побеждать будет не тот, кто придет с хорошей идеей, а тот, кто сможет долго и планомерно осуществлять ее в жизнь.

Основная проблема людей, которые ищут Супер Идею, заключается в том, что она может НИКОГДА не появиться! При этом очень многие упускают действительно хорошие шансы на то, чтобы создать свое дело. Сегодня вы отбрасываете мысль о новом начинании, как не особо перспективную, а завтра (или через десять лет), кто-то другой пожинает плоды и прибыль, а вы все еще находитесь в поиске.

Большинство успешных предпринимателей стали успешными не потому, что открыли золотую жилу. А потому, что продавали лопаты. Шутка :-) Они стали успешными только потому, что не ждали своего принца в высокой башне, как в классических сказках для маленьких девочек, а решительно спустились на землю и нашли просто “достаточно хорошего” спутника жизни. Поверьте, для успеха в бизнесе, так же как и для семейного счастья, важно найти не “идеального” спутника или идею, важно просто сделать это вовремя, а в дальнейшем строить свои отношения, несмотря на обязательные разногласия или неудачи. Дорогу осилит идущий.


Похожие записи

ВенгерскаяНотация-ЭтоЗло




Комментарии [20] - на пост “ВенгерскаяНотация-ЭтоЗло”

  1. cactusinside

    Так почему же все таки зло? Только из за того что для вас NameZeroString лучше читается? Для меня например хуже(в вашем примере мета-информация ZeroString, UnsignedInt, … занимает больше места чем само имя). Вы просто придумали свою нотацию, когда описание типа помещается в конец, причем сильно раздувая имя. Да и мои “здравый смысл и некоторый опыт говорят”, что венгерская нотация это добро.

    Насчет талмудов – надуманная проблема. Та же студия мне выдаст подсказку какого типа данная переменная, после этого произойдет состыковка префикса с типом. И, к тому же, если я не помню точное название переменной, то просто набрав m_dw и нажав Ctrl+SPACE я полу список только DWORD переменных, а в вашем случае я должен бегать по всем.

    Есть еще аргументы?

  2. frost

    Привет Сергей. Давно не виделись.
    Венгерская нотация….когда я начинал программировать я даже не знал что это такое….абсолютно случайно, из соображений удобства начал приписывать префикс к названиям переменных. По случаю выпуска твоей заметки я произвел опрос, и оказалось венгерскую нотацию используют практически все рядом расположенные программисты. Дело в другом, тут главное не дойти до маразма. Так например я в своем коде далеко не у каждой переменной ставлю префикс, и при этом код читается хорошо, по крайней мере мне так говорят. Вот мой рецепт: я обязательно использую префикс, когда задаю имена компонентам (btnOK, fmMainForm, slMain и т.д.), далее если переменная локальная и используется в рамках данной процедуры то префикс не обязателен, для типов данных я так же использую префикс…. Не буду оспаривать твою точку зрения, в конце концов если ты пишешь и твой код больше никто не просматривает и при этом ты сам в нем разбираешься по прошествии года или двух, ты можешь называть переменные как душе угодно. Если же ты работаешь в команде, там как правило существуют общи правила написания и оформления кода. Короче правда мне кажется, где-то посередине, как всегда :) . Удачи…и жду с нетерпением новых заметок!

  3. Сергей Гоцуляк

    2cactusinside: Я вообще никогда не указываю информацию о типе переменной в ее имени. Во-первых, это излишне, во-вторых, это нарушает, на мой взгляд, принципы прозрачного программирования, особенно в ООП-стиле.

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

    Что касается поиска нужной переменной по ее типу… “ну это вообще песня” :-) Понимаете, мне не приходится ЗАПОМИНАТЬ имена переменных – я в любой момент времени могу сказать, как называется переменная в программе, потому-что даю им ОСМЫСЛЕННЫЕ имена, не отягощенные абракадаброй из венгерской нотации.

    Подход прекрасно работает – библиотека VCL написана ясным стилем, венгерской нотации там отродясь не было. Похоже, Microsoft также отказывается от своего изобретения – весь .NET Framework написан в том же прозрачном стиле, что и VCL. Более того, в документации они НЕ РЕКОМЕНДУЮТ пользоваться венгерской нотацией при разработке программ под .NET. Комментарии излишни.

  4. Сергей Гоцуляк

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

    А что касается программистов, расположенных рядом… вот у меня все сотрудники, находящиеся в комнате – мужчины. И какой я должен из этого сделать вывод ;-)

  5. frost

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

    PS. Иногда девушка в коллективе может значительно повысить продуктивность работы…..или наоборот, забрось девушку в коллектив и наблюдай :)

  6. Softwarrior

    И все-таки, если не ошибаюсь, как раз в той самой статье Джоэль поясняет, что МС (или кто другой) извратил изначально придуманный принцип венгерской записи поскольку ее автор в опесалове сего метода употребил слово “тип” имея ввиду не тип данных, а смысловой тип переменной. Тем не менее, все поняли, что имеется ввиду именно тип данных. Так и родились правильная венгерская запись Apps- и неправильная System- Hungarian. Последняя сплошь и рядом встречается в Win API, делая для меня – делфи программера – непонятным как название, так и тип переменной (хотя в последнее время я вроде уже выучил сишные типы). :-)

    Apps Hungarian – вешь вполне даже привлекательная, но никто не заставляет ее вставлять куда надо и куда не надо. Я лично постоянно приделываю префиксы “or” (original) и “en” (ending) как к индексам при парсинге сторок, так и к координатам X, Y. Потом в коде однозначно понимается, что orX, orY – это начальная точка, а enX, enY – это текущая (конечная) точка. Также индексы символов в строке: orI, enI.

    Впрочем, использовать или не использовать – дело вкуса.

  7. Anton

    Венгерская нотация превращается в зло только в случае ее злоупотребления (любую хорошую идею можно извратить и довести до маразма). Если же использовать subj только для встроенных типов, глобальных переменных, а также некоторых наиболее распространённых типов (string, vector …), то результат будет только положительным. Код станет более единообразным: вы не спутаете char *szString с std::string strString, а переменная iVar (int iVar) своим названием будет говорить о возможности принятия отрицательных значений. А при грамотном выборе префиксов программирование не превратится в написание сочинений на полуестественном языке с именами переменных счётчика цикла в 10 символов.

    Я считаю венгерскую нотацию хорошим приёмом оформления исходного кода, и последовательно использую его во всех своих программах.

  8. Alexander Mazuruk

    NameZeroString, NamePointer, OKButton, MainForm

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

  9. Сергей Гоцуляк

    Александр, сколько времени вы тратите на чтение художественной литературы? Может стоить заменить ее на краткий язык смс-сообщений (в английском уже есть такой диалект) ;-)

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

  10. Alex Dybenko

    Я так думаю, что если пишешь сам, и сам ошибки ищешь – то вообщем-то по барабану как именовать переменные. Тут лучше – как привык. А вот если надо, чтобы другой человек прочитал твой код – то лучше использовать префиксы, это здорово помогает. вот пример – MainForm – всретив такую перменную в середине процедуры совершенно не понятно – это ссылка по объект формы, или имя формы? приходится лезть к ее определению

  11. Alexander Mazuruk

    Сергей, для меня исходный код в первую очередь – код,
    и сравнивать его с худ. произведениями не вполне корректно,
    моя точка зрения относительно использования интуиции при беглом просмотре исходного кода, базируется не только на моем личном мнении, но и на простой природе человека,
    мы(люди) склонны упрощать все и везде, причем на подсознательном уровне! если дело касается политики, все многообразие информации сводится к банальным цветам – оранжевый и синий, такое различие полезно тем, что нормальный человек различает цвета даже не задумываясь о том какой это цвет, соответственно, система осмысления не задействована – это прямая экономия времени. Вы думаете зачем в софте используются иконки? для красоты? нет, потому как система распознания визуальных образов работает быстрее чем система чтения слов, пользователь быстрее ориентируется в интерфейсе если в нем присутствуют уместные и логично подобранные иконки. Для программиста система префиксов для имен идентификаторов – это те же самые иконки что и для пользователя, понятно к чему я веду? Например! одним из огромных преймуществ файлового менеджера Total Commander перед его конкурентом FAR – есть возможность отображения иконок к файлам, распознавать типы файлов становится очень легко, за щет того, что не нужно “читать” ни расширение, ни имя самого файла. Но если Вам так нравиться идти против течения, против своей собственной природы, пожалуйста…

  12. Сергей Гоцуляк

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

    Взять пример с идентификатором MainForm – я сходу и не отвечу, что это такое: ссылка или имя формы. Вот только на определение смотреть точно не буду, потому-что это лишнее :-)

  13. Banzay

    Венгерская Нотация Ч. Шимони, широко используется самой Microsoft. А применять ее, дело вкуса. Не нравиться такой стиль, придумайте свой, что из-за этого шум то раздувать :)

  14. _Andrey_

    У Total Commander нет ни одного приемущества перед FAR. А для определения типа файла есть подсветка имени файла, которая воспринимается существенно быстрее, нежели распознавание образа мелкой иконки (которые зачастую слабо различаются, или вообще не ясны).

    p.s. Я за венгерскую ноттацию – это весьма удобно. Все сказанное мое ИМХО.

  15. Всеволод Лукьянин

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

    Вот основные из причин, по которым я не использую В.Н.

    Что же можно использовать для читабельности вместо В.Н.? Стараться сузить область действия каждой переменной, упрощать код, разбивать по возможности длинные функции на несколько мелких, каждая из которых делает маленькое, но четко определенное действие (идеал – то, что влазит целиком в окошко), и самое главное – вставлять комментарии (!!!). Вот что главное в читаемости, а не то, чтобы видеть какого типа переменная. Я абсолютно не против использования префиксов вообще, но венгерская нотация, в том виде, в котором она используется и чуть ли не канонизируется, мне совершенно не нравится. Нормальное, с моей точки зрения, использование префиксов, это, например:

    name – имя
    pName – указатель на имя
    ixName – индекс колонки/поля с именем
    rName – ссылка на имя
    m_name – член класса, содержащий имя
    gl_name – глобальная переменная
    s_name – статическая переменная
    и т.п.

    Для переменных-счетчиков цикла, вообще, лучше, чем i,j,k и т.п. трудно что-либо придумать :)

  16. _Andrey_

    Про переменные-счетчики полностью согласен, с небольшим дополнением правда ;)
    По поводу “много раз меняется тип переменной” – это как? Не знаю, что я пишу? Пробовали предварительно проектировать на бумаге, а только потом кодить? Сильно экономит время.

  17. axedeveloper

    2 Всеволод Лукьянин

    >> … идеал – то, что влазит целиком в окошко …

    Ээээхххх, батенька, это далеко ещё до идеала. Я со своих ребят в команде всегда требовал 5-7 строк максимум!!! Сперва плакали, потом благодарили. Также есть такое понятие как “цикломатическая сложность”. С нею тоже надо не переборщить.

    >> … и самое главное – вставлять комментарии !!!

    Во-во, однозначно. У нас в особо тонких местах на одну-две строки кода есть и 20 строк комментария :)

    2 _Andrey_

    >> По поводу “много раз меняется тип переменной” – это как? Не знаю, что я пишу? Пробовали предварительно проектировать на бумаге, а только потом кодить? Сильно экономит время.

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

    А что, Вы когда проектируете на бумаге, то даже ниразу не стираете ? Не пробуете разные варианты ? Так и в коде: вот он есть класс/метод – вот он уже не он, а вот его и не стало :) – его обязанности распределились по другим классам, например. И т.п.

  18. Хмельницкий Денис

    Каждая вещь может быть полезной, бесполезной или вредной. Молоток полезен, если им забивать гвозди, вреден, если им стучать по голове и бесполезен, если им причесываться.
    На мой взгляд ВН появилась в результате несовместимости объемов кода с развитием на тот момент программных сред. Когда разрабатываешь большие проекты в команде на асме или С++ в среде 3.1 то ВН – это одно из лучших средств решения проблем с читаемостью кода и поддержки культуры кодинга в комманде. Но для проектов, написанных в .NET или C++ Builder Visual C++ 2007, такая проблема неактуальна, так как сама среда разработки имеет встроенные фичи для упрощения читабельности (начиная от шаблонов и заканчивая динамическими подсказками). Поэтому в таких проектах использование ВН является как минимум бесполезным, а зачастую и вредным.

  19. Андрей

    Комментаторы в основном напирают на то что IDE имеют всякие средства для облегчения читабельности, и это типа решает проблему. У меня есть два аргумента против этого утверждения:

    1.Оригинальная статья называется “Как заставить неправильный код выглядеть неправильно”. Автор формулирует цель так: при вгляде на неправильный код должно быть сразу видно что он неправильный. Всплывающая подсказка возникнет если вы наведете на переменную курсор. То есть получается что нужно водить по текусту программы курсором и читать всплывающие комментарии, так чтоли?
    2. Никакая IDE не отличит индекс массива от разницы индексов или от длины того же массива. Ну или пример из моей жизни: почему то в библиотеках для работы с трехмерными объектами для обозначения точек в трехмерном пространстве и векторов используется один тип (какой нибудь Point3). Это совершенно разные типы, которые в жизни ведут себя по разному. Использование префиксов перед именами переменных типа Point3 позволит четко различать вектора от точек и соответсвенно одного взгляда на строку кода будет достаточно чтобы выявить ошибку. IDE при этом никак не поможет, она не сможет отличить точку от вектора.

    Я думаю нет смысла придумысать префиксы для всех существующих типов данных. Достаточно только для самых ходовых, особенно для тех типов, неправильное использование которых может оказаться критичным. Хроший пример из оригинальной статьи с “s” и “us”.

  20. БОННИС

    Здравствуйте,Уважаемый Сергей. Имеется реальная и несложная в реализации Супер-Идея,
    продавать спички по одной штуке и при такой инновационной концепции (по рентабельности)
    и долгосрочному коммерческому потенциалу,всегда можно будет “переплюнуть” любой в мире
    негативный “Лас-Вегас” или позитивный проект,типа “кубиков-Рубика”.

    С уважением,Николай Сергеевич. Ищу совместимого единомышленника,с организационными
    (практическими) ресурсными возможностями.

Ваше мнение?