Я думаю, что то, чего не хватает большинству комментаторов, на самом деле довольно важно для вашего вопроса - идея, что вы работаете с экспертами в предметной области, чтобы создать реализацию их модели для проверки их теорий.
Большинство программных разработок не касаются этого режима - и, как вы говорите, он просто качественно отличается от реализации какого-либо бизнес-процесса или создания сервера, который должен реализовывать RFCxxxx.
Есть люди, работающие над этим с обеих сторон - пытающиеся научить ученых основам ответственной разработки программного обеспечения (например, Software Carpentry Грега Уилсона) и обучить специалистов по разработке программного обеспечения крупномасштабным вычислениям. наука (например, очень интересный блог Стива Истербрука , из которого этот особенно уместен). Почему вещи столь же примитивны, как и на этом фронте, я понятия не имею. У обоих есть ссылки на своих коллег по блогам.
В этом режиме есть ряд важных отличий от того, чему вас, возможно, учили. С одной стороны, общая структура научного программного обеспечения, как правило, довольно проста, но тонкость довольно высока - каждая строка чисел может быть результатом 10 лет научной литературы в ряде областей. Во-вторых, вся идея спецификаций вроде бы перевернулась с ног на голову - спецификация «точно моделирует реальность», и у ученого есть модель, которая, как они надеются, делает это. В некотором смысле, разработка научного кода - это реализация проекта спецификации и поиск реальной спецификации.
@ vfilby имеет правильную идею - постоянное участие клиентов - но это немного больше, чем это. Чтобы это сработало, вы попадете в научный цикл - вместо того, чтобы быть ученым & rarr; теория & rarr; тест & rarr; интерпретация & rarr; обновить теорию, это будет ученый & rarr; теория & rarr; вы код & rarr; вы и ученый оба истолковали свои собственные части & rarr; обновить теорию и / или реализацию. Ученые в области не узнают так же хорошо, как и вы, как наилучшим образом реализовать то, что они хотят, или как отделить результаты своей модели от результатов вашей реализации модели; с другой стороны, они гораздо лучше, чем вы, поймут значение модели и узнают, как обновить теорию.
Это сложный баланс, чтобы понять все правильно. Чтобы это сработало, обе стороны должны (а) уважать другие области знаний, (б) узнать немного об этой другой области, и (в) инвестировать в проект в целом, работая. Подобные междисциплинарные проекты разрушаются чаще, чем успешны, но они жизненно важны. Я действительно хотел бы иметь несколько простых, гарантированных для работы советов для вас.