Все что будет написано ниже - всего лишь мои наблюдения и никак не абсолютная истина.
Заметил я, что большинству софтописателей невыгодно писать качественный софт не зависимо от масштаба и типа.
Предположим мы пишем софтину на заказ. Если мы напишем все идеально и качественно, то софтина работает, багов нет, саппорт не нужен. И заказчику смысла платить нам нет. Пусть даже его бизнес будет меняться и нужно будет дописывать фичи. Но если будут еще баги и т.п, то денег из заказчика мы вытянуть сможем больше. Деваться то ему больше не куда. Мало кто наш код дописывать будет. Главное не переусерствовать, что б не завалился проект.
Тоже если пишем коробочный. Не зависимо от того, это маленькая сотинка-шараварка за копейки или какой-нибуть монстроподобный САПР или Винда. Если нет багов, и идеальный интерфейс и все такое, людям не нужно будет покупать новые версии, и денег мы вытащим больше при посредственном какчестве.
Сразу понятно почему миром правят индусы и китайцы. Пишут они много, дешево и с посредственным качеством. Именно то, что и нужно современным софтостроительным комбинатам, которые тоннами выливают террабайты говнокода в сеть.
Но разве такая концепция софтостроительства не есть пережитками прошлого (для некоторых) индустриального века. Или никакого информационного века не существует?
Loading ...
июня 10, 2007 в 12:58 am
я незнаю откуда у Руслана такие мысли. Может, в разработке корпоративных систем это имеет место, но например веб на том и живет только что постоянно нужно переделывать и улучшать.
и осоновной мотив в вебе - если работает то пусть работает, похуй как. И бабки большие крутятся. и 95% веба - редкое говно или спам
вот такие дела
июня 10, 2007 в 1:31 am
В общем-то я примерно об этом и писал... Что не выгодно с точки зрения бабла писать качественный софт.
июня 10, 2007 в 1:34 am
Руся, качественный это какой?
имхо качественный это то который решает задачу. Если говновеб решает задачу, то он качественный. И постоянные переделки не отрицают а только это подтверждают.
июня 10, 2007 в 11:26 am
Качественный - это с продуманной архитектурой, с минимальным количеством багов, продуманный с точки зрению UI, я бы сюда еще автоматическое тестирование всех видов добавил, но многие будут сопротивляться и спорить. Качественно в нем все закодировано без индусского кода. ) В общем-то о качестве можно еще отдельный такой пост написать. В некотором роде можно сказать совершенный.
Скажем так, и жигули и феррари решают задачу - они ездят. Чувствуешь разницу в качестве? )
июня 10, 2007 в 12:16 pm
феррари кста часто ломается на наших дорогах, все профессиональные автомобилисты считают такие автомобили говном
июня 10, 2007 в 1:08 pm
Это потому что у них нет денег, что б его купить )))...
июня 10, 2007 в 7:01 pm
А я думаю, дело в другом
- просто "идеального софта" принципиально и быть не может 
- иначе индустрия софтописания не существовала-бы... - все время надо повышать уровни абстракций; следовательно, многие алгоритмы менять на принципиально другие... Если есть что-то "идеальное" - стоит помнить, что оно "сиеминутное" - как Ньютоновская физика была идеальной до прихода физики Эйнштейна. + тут работает негласный закон сохранения хаоса... 
июня 11, 2007 в 10:55 am
небольшое лирическое отступление...
на счет индусского кода я согласен, а вот с китайским не все так однозначно... Я видел довольно таки много китайского кода и в своей массе он очень качественый.
Даже больше - китайцы очень внимательны к мелочам и за счет этого их код получается более надежный чем тот который пишут наши.
По поводу основной мысли статьи я тоже не могу согласиться.
Пример 1:
Мы пишем код "на коленке" отдаем клиенту и он доволен так как все что он хотел мы реализовали.
Через некоторое время клиент просит нас добавить новую "пимпочку" в то что мы написали. И тут начинаются проблемы. Так как изначально код писался похабно то оказывается что проще переписать все сначала чем дописывать то что есть. Но ведь клиент об этом не знает (а кто ж ему скажет!) и он платит только за небольшое изменение. В итоге даже если мы все переписываем и клиент снова доволен мы "попали на бабки" так потратили намного больше рессурсов чем было оплачено.
Пример 2:
Мы сново пишем "как попало", отдаем клиенту и клиент НЕ доволен. Начинается длинная фаза баг-фиксинга, рефакторинга и т.д. В итоге мы опять таки тратим намного больше запланированного и клиент, как правило, больше с нами дела не имеет.
Т.е мы упустили возможность работать с этим клиентов в будущем плюс приобрели плоху славу среди партнеров клиента.
июня 11, 2007 в 11:54 am
Помоему говнокод это не стратегия, а историческая необходимость. Думаю, что в любом софтостроительном комбинате будут рады заполучить качественный, эстетичный продукт. Другое дело, что не в каждом комбинате есть кодеры соответствующего уровня.
июня 11, 2007 в 12:44 pm
Обычно аутсорсеры договариваются на время и оплачивается время работы команды, поэтому чем дольше работает команда и чем больше в ней народу, тем больше платит клиент, и больше получают "дяди" на которых пашут простые кодеры. Да, действительно, важно что б клиент был доволен, и багов не было очень много, тут есть грань при которой клиент уходит. Если не уходит мы можем сказать: "Дядя, у нас нет ресурсов на фиксинг багов к сроку, нужны еще люди, а следовательно и бабло". И лидеры рынка хорошо эту грань знают. Причина такой ситуации кроется в отношении к ИТ, как к расходу (а расходы надо сокращать), чем как к инвестиции (которые наоборот надо увеличивать и получать за счет них конкурентные преимущества).
Когда договариваются насчет пимпочки тут скорее просчет руководства, которое не понимает специфики отрасли.
Хорошие кодеры долго в комбинатах не живут. )
июня 12, 2007 в 9:55 am
В мире общая тенденция понижения качества всего, причем это именно тенденция последний лет 20, так что индустриальный век тут как раз в шоколаде, а суперпуперинформационный.....
Причем даже намеренно делать все удовлетворительно не сразу чтоб выбить больше бабла не является какойто уникальной особенностью софтописания.
июня 15, 2007 в 9:00 pm
Автору:
пригласите меня в мир идеального кода? с удовольствием поью чайку и понаблюдаю за безошибочно работающими програмами
имхо, нету "идеально" софта без глюков
июня 18, 2007 в 10:46 am
Я вот все пытаюсь понять каким боком сюда пришел "идеальный софт". Смысл был в том, что никто к нему даже не стремится. И что это не выгодно с экономической точки зрения.
июня 18, 2007 в 5:28 pm
...а следовательно - где заканчивается качество и творчество - начинается бизнес
вот и идёт ломка НАШЕГО сознания - хочется и писать красиво, и оптимально, и быстро - как на одном дыхании, и получать за это большие бабки.
иногда чтобы заработать больше денег надо создавать гавно, а создавая гавно ты деградируешь
иногда хорошую идёю никто не оценит
советую посмотреть Ашманова (его выступление на рит)
июня 18, 2007 в 5:53 pm
к тому, что написать идеально работающую программу невозможно. и всегда будут глючки и нужна будет поддержка. а тем более если проект будет развиваться.
имхо, писать код хорошо гораздо выгодней.
июня 18, 2007 в 7:36 pm
Вопрос больше риторический... Думаю, Памела, Вы просто не работали в больших конвейерных компаниях.
Писать код хорошо выгодно для кого?
июня 18, 2007 в 7:56 pm
работала
(назвать компанию не проблема, если нужно)
хорошо для всех
я всегда пишу на макс. своих возможностей в зависимости от отведенного времени на выполняемый проект, хотя бы потому, что этим буду пользоваться такие же люди как и я. Я человек, и ошибки в программе в любом случае будут -хочу я этого или нет. для поддержки продукта зачастую выделяються отдельные люди, а программисты олучают новый проект.
тем более у каждого проекта есть дедлайн. и если он не будет написан качественно - тоесть не будет отвечать поставленным задачам - то его просто не примут. и место того, чтобы получиться финансовую оплату зданного проекта, получу выговор и разбирательство почему не успели.
ровно как и компании в которой я работаю - потому как она не получает во время продукт и несет убытки.
получить некачественным продукт = неполучить продукт. оценкой качества продукта занимаються тестировщики.
вот приблизительно так
это из моего опыта. Вы можете соглашаться или нет
июня 18, 2007 в 8:51 pm
А что Вы подразумеваете по понятием "качественный софт"?
Об этом я тоже писал.) "Но если будут еще баги и т.п, то денег из заказчика мы вытянуть сможем больше. Деваться то ему больше не куда. Мало кто наш код дописывать будет. Главное не переусердствовать, что б не завалился проект."
Вы описали ситуацию, когда переусердствовали и завалили проект. Пока мы выше грани провала, качество значения не имеет. Чем оно ниже, тем выше прибыль.
июня 18, 2007 в 10:44 pm
филосовствовать можно долго и упорно.
если Вы считаете, что это метод принесет Вам больше материальных благ - Ваше право
о качественном софте тоже можна спорить и думаю у каждого свое понимание и спор превратиться в "на вкус и цвет ...."
июня 19, 2007 в 2:05 pm
С философии все начинается... Я к тому это говорю, что у меня есть мысли, как можно создавать софт быстро, дешево и качественно... Но это не год и не два работы в этом направлении. С другой стороны как раз успеет рухнуть рынок аутсорсинга разработки ПО.) Хотя пока рынок еще жив, попробую еще успеть на нем поживиться... Нужно успеть впрыгнуть на волну пока пузырь пост-советских дот-комов еще не лопнул...
июня 20, 2007 в 8:15 pm
Мне интересно, а будет ли заказчик платить за исправление багов? Т.е. в том случае, если программа не выполняет того, что от неё требуется или выполняет некорректно?
Естественно, если заказчику нужна новая фича, то он за неё должен заплатить... А как в случае багов в программе, за которую он уже заплатил и ждёт нормальной работы?
июня 20, 2007 в 9:39 pm
Если с заказчиком не правильно заключен контракт и криво описаны обязанности, то заказчик, конечно, вытянет из вас все соки. Как уже удачно было замечено создать программу без багов невозможно в принципе.
Обычно, контракт на аутсорсинг заключается как количество человек и количество времени. Если заказчик хочет получит достаточно качественный релиз, а для этого не хватает совсем немного ресурсов, конечно, заказчик эти ресурсы оплатит. Если нужно очень много ресурсов, заказчик скорее всего закроет проект.
июня 21, 2007 в 10:34 am
единственный правильный выбор в таком случае - наличие грамотного менеджмента со стороны заказчика, который может контролировать как сроки, так и качество разработки.
при грамотном менеджменте и организации труда возможно создать качественный продукт ибо программеры - они такие лентяи, которые в свою очередь могут хорошо работать. главное правильная мотивация, и зачастую это не деньги. поэтому всё зависит от руководящего состава, а именно от менеджера который работает с разработчиками напрямую
июня 22, 2007 в 3:56 pm
я думаю, что все подобные ходы уже были изучены и как следствие устранены, илбо будут устранены в ближайшее время.
июня 28, 2007 в 5:10 am
1. любая точка зрения имеет место быть
2. любая политика, которая работает и приносит прибыль - эффективна
3. индустрия ПО это не краеугольный камень и тут работают любые правила любой индустрии (часто после процесса адаптации правила)
4. менять правила и мир допустимо и даже необходимо
5. любые рассуждения имеют смысл, если в них есть вывод
Личные выводы:
надо писать то, что работает и выполняет требования
писать надо интересно, подходя к работе творчески
профессионал отличается от дилетанта тем, что может простую и рутинную работу превратить в творческую и интересную
Правило, которое я вырабатываю в компании:
1 человек работает на 3-4х проектах, за счет постоянного переключения между ними доля рутины исчезает
июня 28, 2007 в 6:55 am
Все-таки, как я вижу тема затронута актуальная. )
>Профессионал отличается от дилетанта тем, что может
>простую и рутинную работу превратить в творческую и
>интересную.
И выполнить ее не за 1-2 дня, а за 1-2 недели.) При этом, конечно, выполнить красиво, творчески и качественно, но мало какой софтостроительный комбинат будет так увеличивать свои издержки. Я не говорю, что нет коипаний, которые подходят творчески. Они слава богу есть. По крайней мере в Москве я знаю одну такую. В Черкассах и Киеве, к сожалению, таких не встречал.
Интересно, а я всегда думал, что профессионал - это тот, кто за работу деньги получает.
>Правило, которое я вырабатываю в компании:
>1 человек работает на 3-4х проектах, за счет
>постоянного переключения между ними доля рутины
>исчезает
Я бы повесился работать на 3-4х проектах. Я на 2-х работал, и это мягко говоря напрягало. Хотя, конечно, это вопрос масштабов. Если человек эти 3-4 проекта делает меньше, чем за месяц, то почему бы и нет. А когда только первоначальное "вгружание" в проект проходит с месяц, думаю, участие одного человека в более чем одном проекте не выгодно и компании, и человеку.
июня 28, 2007 в 9:36 am
3-4 проекта могут быть в нормальном режиме когда есть ритмичность поступления фидбека от заказчиков, и да если эти проекты не особо сложные.
По поводу красоты....эээ ну можно не передергивать
в природе все что красиво как правило рационально, конечно если уже есть нечто большое с одной идеологией(которая допустим уродливая) то вживлять туда свое сложно, но это крайности.
июня 28, 2007 в 4:44 pm
>И выполнить ее не за 1-2 дня, а за 1-2 недели.) При >этом, конечно, выполнить красиво, творчески и >качественно, но мало какой софтостроительный >комбинат будет так увеличивать свои издержки. Я не >говорю, что нет коипаний, которые подходят >творчески. Они слава богу есть. По крайней мере в >Москве я знаю одну такую. В Черкассах и Киеве, к >сожалению, таких не встречал.
бла-бла-бла
>Интересно, а я всегда думал, что профессионал - это >тот, кто за работу деньги получает.
Деньги за работу почучают все и дело совсем не в суме
>Я бы повесился работать на 3-4х проектах.
Ты - да
июня 29, 2007 в 10:55 am
>Деньги за работу почучают все и дело совсем не в суме
не факт... есть бесплатно работают
любителями называются....
июня 29, 2007 в 7:01 pm
нет case ты не прав, можно работать бесплатно какое-то время на преспективу (свой дело развивать к примеру)
июня 29, 2007 в 7:48 pm
конечно можно, Дмитрий, даже нужно...
июля 1, 2007 в 7:26 pm
Прежде всего, сенкс за ресурс, ребята (обнаружил недавно и случайно)...
По сути топика:
). Не качественный код можно обосновывать как угодно, но обычно это происходит из-за неумения написать лучше (т.е банальная попытка оправдать себя, любимого, задним числом). Код может быть осознанно не полным, не оттестированным в нужной мере (в случае когда речь идет не о конечном продукте а о пилоте, POC и т.д.) но не горбатым.
Написание плохого кода не выгодно из всех соображений (включая экономические и кармические
Отсюда, профессионализм - это не только получение денег за свое дело, к-сожалению деньги платят не только профессионалам, но профессионалам к-счастью больше (при нормальной ситуации). Профессионализм - это четкое осознание что, как и в какие сроки ты делаешь + умение доказать свою точку зрения менеджеру, заказчику и т.д. Т.е. (по выше приведенному юз кейсу) профессионал редко когда оценит 2-х месячную работу как 2-х недельную, хотя такое тоже возможно если речь идет о чем-то наукоемком, но в этом случае он(она) обнаружит это не в конце второй недели а гораздо раньше.
Что касается оцениваемости творческого подхода - это безусловно ценится, другое дело, что не всегда мнение творца не совпадает с мнением окружающих :), но это все приходит постепенно, главное не сдаваться.
Компании, которые подходят творчески есть и в Черкассах (по крайней мере одна - это точно
). Более того, этой компании нужны соответствующие люди (но об этом будет в другом топике)
июля 2, 2007 в 5:45 pm
сорри за оффтоп:
2Руслан Пилин:
>По крайней мере в Москве я знаю одну такую.
Luxoft?
июля 2, 2007 в 6:41 pm
Все правильно и хорошо пишете по поводу знаний специалиста.
Но case сделал очень важное замечание.
Профессионал в какой-либо отрасли - человек зарабатывающий на этом деньги.
При чем не важно какие деньги и насколько хорошо он это делает.
июля 2, 2007 в 7:36 pm
называть профессионалом человека однажды единожды удачно заработавшего на чем-то (к примеру путем чистого надувательства или манипулирования).
поэтому если уже идти на поводу у такого определения, тогда уже так: профессионал - человек постоянно зарабатывающий деньги используя свои знания.