Приветствую всех.

Ситуация следующая. Пригласили поучавствовать в проекте. Пригласил один профессор, доктор. физ-мат. наук. Человек действительно очень грамотный и в своей области профессионал. Суть заключается в том, что нужно запрограммировать один алгоритм(упрощённо, на самом деле всё сложнее). Сложность конечного продукта весьма велика. 

Профессор, как программист(в понятии, включающем всю широту данного занятия) не силён. Он решает свои проблемы, может запрограммировать алгоритм на фортране, написан огромную функцию, понятную лишь ему. Кроме меня? в проекте учавствует ещё один неопытный программист-студент(опыт работы в команде == 0), пишущий на делфи потому, что последний предусмотрен ВУЗовской программой. Когда я пытаюсь говорить в терминах ООП они делают круглые глаза, я решил пусть каждый мыслит в терминах удобных ему, лишь бы код был качественный(хотя неясно, как мы потом будем в команде писать). Люди не понимают почему нельзя начинать писать код до этапа проектирования. Я должен объяснять почему функции объёмом 500 строк - зло. 

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

С ув. 

Не совсем. Но и не совсем нетактично. Постарайтесь объяснить разумному человеку (а вы его отрекомендовали именно так), что задача, которая решается текущими методами, неможет быть решена качественно. Если вы его не сможете убедить, то выбор за вами. Такой вам мой совет студента (я бы сделал так). 

а какая твоя роль в этой команде ?

Добавлено @ 15:43

хмм... а есть ли команда ? и он ли - тим-лид ?
руководство должно во первых быть руководством, т.е. быть СПОСОБНЫМ сказать делать "так-то" или "сяк-то".

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

если проект будет большим и долгим - писать его через зад - это закапывать его.
кстати не недооценивай 500 строчные программы на фортране ;-). особенно если они делают свою работу, и алгоритмически не страшны.

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

Вообще проблема, наверное, встречается часто.

Как вариант - попробовать объяснить это профессору, пусть он выскажет им, что в плане проектирования главный - ты, и с тобой надо считаться.
Если нет... тогда надо думать.

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



Да в общем-то была поставлена задача превратить в код большой и сложный мат. алгоритм. Я был приглашён в качестве программиста. 



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



Ну Вы, наверное, представляете как пишет программы математик? Переменные i,j,k,m,n и вперёд  Дело не в этом. Я боюсь некачественного кода, в котором придётся потом разбираться. В частности, эта функция представляет из себя нехилый алгоритм, который будет одним из частей ядра системы. 
На прошлой встрече я убедил всех начать с выработки требований. В итоге мы пришли к выводу, что, т.к. система проводит весьма долгие вычисления, а число ядер в процессорах будет только расти, необходимо включать в список требований мультипроцессорность. А это значит, что придётся разбираться с мат. алгоритмами на самом низком уровне, чтобы предусмотреть возможность работы параллельно, а когда перед глазами шмот кода в 500 строк, написанный понятным только автору образом, то это слегка тревожит.  
Возможно, я слегка утрирую и в нашем случае всё будет не так страшно, но интуитивно понимаю, что подход не очень-то перспективен.



Нет, коммерческий. А вот подход точно академический.

Добавлено через 11 минут и 43 секунды


Пример с прошлой встречи. Проф решил, что пока я займусь проектированием, другой программист на Delphi будет писать ядро системы, т.е. функционал, который в любом случае в проекте будет, в каком виде он будет мы, конечно, не знаем, ибо проектирование ещё не проведено. Я сказал, что не следует приступать к коду, ибо рановато ещё. Убедить не удалось, хотя я привёл веские аргументы, что этот код в итоге придётся переписать под нашу конечную архитектуру, сказали: "перепишем, не проблема". В итоге на след. встречу пойду с чётким обоснованием и доказательствами того, что Delphi для реализации этого алгоритма не приемлем(нет поддержки SIMD и OpenMP + он медленнее в этом случае на 35%, ибо я сам в итоге этот алгоритм нашёл, подправил, собрал 3мя компиляторами(2 С++ и 1 delphi) и протестировал на 7ми разных процессорах), ну а программист, который всю неделю писал код - потратил время зря. Жаль конечно. 

Да уж...

Кстати, боюсь, что ты сам сможешь написать проект лучше (а, возможно, и быстрее), чем ваша разношёрстная группа.

W4FhLF, А зачем вам на данном этапе тот студент? Только проблем огребете. Если продукт коммерческий, надо подходить соответственно. В первую очередь, написать документ с требованиями, потом описать продукт с точки зрения пользователя (функциональная спецификация). Далее, создать выскокоуровневую архитектуру системы исходя из требований, известных на момент начала проекта. 

Далее нужно трансформировать спеку в план работ и начинать писать код. Думаю, в неделю можно уложиться с первым этапом (до начала кодирования).

Потом надо бы предложить профессору свой алгоритм описать словами. Код на Фортране - это хорошо, но это всего лишь концепт-прототип (proof of concept prototype). Этот код ни в коем случае не должен попасть в продакшн    

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

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