Так как достаточно много комментариев в теме http://www.prog.org.ru/topic_24027_15.html о том что необходимо работодателю от программиста и наоборот, я предлагаю обсудить это здесь.

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

Программист, считая, что от него требуют скорость работы, чаще всего предлагает быстрое "наколеночное" решение, так называемые "костыли". Можно даже умудриться сдать работодателю такую работу. Когда требования к программе меняются программист разводит руками и говорит, что все нужно переделывать. Таким образом умудряется одну и ту же работу продать работодателю по несколько раз. Бывает получается, что код написан так, что сопроводить его может только автор  (это верх совершенства работы "программиста").

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

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

Эти ответы как бы снимают с него всякую ответственность за качество.

Таким образом, вопросы к обсуждению.
 - Что на самом деле нужно работодателю от программиста?
 - Что на самом деле нужно программисту от работодателя?
 - Как и за что должен отвечать работодатель перед программистом?
 - Как и за что должен отвечать программист перед работодателем?

Интересная тема, но почему в "Говорилке"? Ладно
С этой точки зрения обсуждать особо нечего. Конечно работодателю нужен хороший код как можно быстрее. Конечно программисту надо чтобы платили прилично и вовремя. Вот собственно и все.

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

Беда только в том что готового-то НЕТУ и/или найти его непросто. Освежив в памяти законы Ньютона Вы вероятно обнаружите что здесь они никак не помогут. Открыв физику жидкостей Вы вероятно тоже уйдете ни с чем. Через 4-5 дней гугления Вы начинаете понимать что топчетесь на месте. А время идет..  

Так происходит с большинством моих задач. Проблема-то может и простая (с теми же каплями - да наверняка), но она достаточно редкая - вот и нет готовых решений заточенных для немедленного использования. Выбрать (а иногда и придумать) алгоритм у меня часто занимает не меньше, а иногда и больше времени чем "реализовать".

Вы всегда берете "слишком широко"  Нет, движения не требуется, нужно только деформировать капли так чтобы они свисали под действием силы тяжести (ну как красивые сиськи). Наибольшая трудность - учесть что капли могут сливаться друг с другом. Ну и у пользователя есть параметр gravity (мять сиськи больше/меньше). Конечно никакой научной работой здесь не пахнет, рядовой 3D эффект.

я то полагал тут про потребности заказчиков и разрабов. А тут про сиськи Когнитивный десонанс наступает.

Нет ничего плохого в использовании выразительной аналогии. А если уж умничаете, то пишите правильно "диссонанс" 

У игровых программ другие цели/задачи, и вряд ли там уместно создавать hi-resolution капли. Там и на character полигонов кот наплакал, абы шустрее бегало. А здесь качество/разрешение нужны довольно высокие (на аттаченной картинке они явно недостаточны). Чего-то там "подмазать текстурой" не выйдет, это не ширпотреб.

По другому вопросу
Судя по этому (и другим) высказываниям Вы вступили на (ой нелегкий) путь нанимающего Да, именно так все и происходит. В этом смысле с контрактором легче. Разбиваете оплату на 2 части. Первая (бОльшая) выплачивается за "ходящую" бету. Вторая по истечении периода бета-тестирования (месяц-два). Да, не все удается отловить за это время, но результаты обычно очень положительные, и недоразумений не возникает. А вот если штатный работник "застрял" в пучине багов - намного хужее. Возможно есть смысл переключить его на др задачу.

Конечно нет.

На капли не действует сила земного притяжения? Или физика жидкостей это фейк? Или вы просто не умеете готовить эти знания?

У большинства на этом форуме такие же проблемы.

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

Ну это наши тяжелые будни.

Нууу, а какой закон описывает силу тяжести?

Не пропал, просто слишком бурное вначале обсуждение обычно быстро затухает, поэтому есть смысл делать паузу - да и мысли придут как чего лучше сказать.

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

Ладно, рассмотрим как сделать "просто капли" которые могут сливаться (пока без всякой гравитации). Здесь используется фундаментальный алгоритм "marching cubes". Форма задается ф-цией Surface(х, y, z). Если ф-ция возвращает положительное значение - мы внутри поверхности, иначе снаружи. Отлавливая нули ф-ции мы строим полигоны/модель. Об этом был диссер еще в середине 80-х. Ф-ция может задаваться всяко-разно, для простоты полагаем что множеством точек в пр-ве + радиусами для каждой капли. Псевдокод

C++ (Qt)
float Surface( const Point & pt ) 
{
 float sum = 0.0f;
 for (size_t i = 0; i < points.size(); ++i) {        // цикл по всем каплям
  float distance = (pt - points[i].mCenter).length();  // расстояние от точки до центра капли
  float factor = 1.0f - distance / points[i].mRadius;    // относительный радиус
  if (factor < 0.0f) continue;   // точка снаружи капли 
  sum += factor;                 // накапливаем              
 }
 return sum - viscosity;  
} 
 

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