Як (не-) розповсюджуються нові технології

Чому розробка іде так довго? Чому дійсно нові технології не розповсюджуються як пожежа?

Paul’s Pontifications " Blog Archive " New Software Technology: Blockage On Line

Every company has a few eccentric engineers who try to explain why this or that new technology would be a great investment. Sometimes they are even right. But they are almost never taken seriously. And so great technologies that could actually save the world a great deal of money on software development (not to mention improve quality a lot as well) languish on the shelf.
Пол дуже добре пояснює чому більшість розробників все ще ммм.... розробляє на мовах, що засновані на концепціях 60-х років. Так, я маю на увазі C та C++, Паскаль (що вічно живий через запити на доробку програм під Дельфі) і, так, Джаву.

Ось чому на нас дивляться, не розуміючи, коли ми пропонуємо розробити проект на питоні, не згадуючи вже і про інші, менш розповсюджені технології. Так, Ruby-on-Rails останнім часом набув певної популярності. Але це ж єдиний приклад.

Отже, чи є шлях компанії з оффшорної розробки ПЗ підвищити свою продуктивність не виконуючи наступний вебовий проект в J2EE/ Struts/ Oracle/ що-б-ще-такого-вліпити?

Стратегічно, є тільки два шляхи, яким така компанія може досягти успіху:

1. Майте хорошу службу продажу, виконуйте обіцяне вчасно і вклавшись у бюджет. Низький ризик, мала маржа.
1. Мати хороший продукт. Величезний ризик, величезна маржа (згадайте Skype?)

В будь-якому випадку, компанія має відображати потреби своїх замовників. Але вибір інструментів на першому шляху здебільного робиться замовниками.

То де ж знайти таких розумних замовників? Читайте допис Пола.

Єдиний життєзднаний вихід для усталеної структури керівницта перевірити нову технологію — це сформувати стартап. Внутрішній чи виділити цілком окрему компанію несуттєво.

Тому, якщо ви хочете розробляти не-мейнстрім для когось — шукайте саме таких людей. Знаходьте стартапи. Станьте відомими в не-мейнстрімній спільноті вашого уподобання і слухайте уважно.

Ви вирішили іншим шляхом — розробити продукт? Мої поздоровлення, ви схильні до ризику. І ви будете винагороджені. Коли-небуть пізніше. Можливо. Якось. Просто не кладіть всі яйця в один кошик :)

Варіант англійською.

  • Популярное

10 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

склалось враження, що автор тільки титоріал зробив на стратс/оракл і то без нагляду старших товаришів) програмування це не тільки технологія це ще ком’юніті і тд. що спрощує життязгідний що на пітоні писати легше але й мануалів по ньому менше — ІДЕ — приємні тузли типу maven2 (21 століття) p.s. до чого тут оракл? стратс — mvc контроллер юзай якухоч базу (модель), а ще краще якийсь універсальний адаптер типу hibernate

akhavr Says:

А “вагомі причини” і так відомі — “всі так роблять”.

В аутсорсинге это ЗНАЧИТЕЛЬНО снижает угрозы и убирает некоторые риски. И не только в теории, но и на практике. Для этого вида бизнеса других вариантов быть не может. В других вариантах разработки ПО — совсем другая ситуация.Поэтому статью нужно немного переименовать, добавив " в условиях аутсорсинга". Или разделить статью на две части, с раздельным анализом ситуации — для аутсорсинга и интеграционных проектов, для всех остальных случаев.

akhavr, я написал, что Заказчики выбирают технологию в аутсорсинговых (ты это имеешь в виду под офшорной разработкой ПО) проектах. И иначе делать — самоубийство. А раз заказчики выбирают — то видимо у них есть веские причины выбирать “J2EE/ Struts/ Oracle/ що-б-ще-такого-вліпити”...Если ты про какие-то другие офшоры, тогда я совсем не понял, о чем твоя статья...

  1. Перепутана курица с яйцом. Точнее смешана и запечена вместе с перьями...Заказчики выбирают технологию? а) В аутсорсинге — КОНЕЧНО. Иначе они нарушат основной принцип аутсорсинга — вынесение за рамки компании ресурсов, но не идей.б) В интеграционных проектах? А как иначе? Они ведь хотят минимум риска (и так бизнес рисковый), вот и уменьшают за счет проверенных средств, отказываясь от новых фич/функций/возможностей.в) В Web-проектах? Само собой. Ведь поддержкой сайта через год может заниматься другая компания, и для УЖЕ распространенных технологий есть больше шансов найти людей.г) В новых административных проектах, в новых решениях «под ключ» для нового бизнеса? А вот и нет — не выбирают они технологии. Потому что некомпетентны, и в этом больше полагаются на девелоперов. Но таких проектов не так уж много. Но есть:) д) -я) вариантов масса, но первые три распространены больше всего, и в них нет причин рисковать:) Это бизнес...2. Я немного не согласен с термином «новые», которым метят питоны и другие инструменты для Web-разработки. Принципы хостинга, разработки и внедрения эти технологии не меняют. Меняют лишь некоторые нюансы разработки/тестирования. Это эволюция, и она не может распространяться как пожар. Вспомните развитие Internet. Вначале появлялось много новых технических решений и удачных идей, но каждая распространялась очень и очень постепенно. Потом БАЦ! и Internet стал доступен обычным людям, малому бизнесу, и произошла революция. С упомянутыми «новинками» история ведь другая:) 3. Новая технология и новый продукт — далеко не синонимы. Статья начинается вопросом — почему ТЕХНОЛОГИИ не распространяются, а заканчивается рекомендацией создавать стартап для ПРОДУКТА... В чем однозначная связь? Ее нет:) Продукт можно (и часто так и есть) создавать на С (даже не С++), и он станет популярным. Или не станет. Но от технологии это зависит в последнюю очередь (или почти в последнюю:)).

Чому дійсно нові технології не розповсюджуються як пожежа?

и потом:

Ні, звичайно нові технології не є самоціллю. Але занадто часто ми не використовуємо їх можливості без об’єктивних причин.

there you go.

Странно, но компьютеры построены на концепциях сравнимых по времени) Да и Lisp не сегодня и не вчера придумали.Добавлю, что пишут сейчас и на том, что было раньше C++, Pascal, C...Новые технологии — это конечно хорошо. Но они не являются самоцелью...//собственно концепция функциональных языков программирования тоже не сегодня появилась...//CSP — да, в последнее время много нового и после C.A. R. Hoare, «Communicating Sequential Processes, » Communications of the ACM, Volume 21, Number 8, August 1978, pp:)

Java побудована на дуже старих концепціях, про що й сказано у статті.

Я это к тому что джава не 60-х годов. Ей всего то 15 лет.

Java technology was created as a programming tool in a small, closed-door project initiated by Patrick Naughton, Mike Sheridan, and James Gosling of Sun in 1991

що засновані на концепціях 60-х років. Так, я маю на увазі..., так, Джаву.

Чушь!

Подписаться на комментарии