mrbrooks, ты об этом?

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

гы. что-то типа этого. 

Давайте все-таки не будем отвлекаться на организационные проблемы 
Тема "Как поссорился главный разработчик с главным менеджером" всем известна неплохо.

Фигня какая-то. Этот малограмотный в вакууме что ли работает?  В маленьких фирмах как раз я соглашусь, что такое возможно. Сидел человек ад разработкой, развитием и поддержкой своего проекта годами. Ушел и выясняется, что код - сплошая "лапша", изменения  вносились методом "заплаток"  итд. 
В больших фирмах  над проектом обычно работает команда,в которую  входят несколько программистов. Что же все они малограмотные?  Или тим лид стесняется своего подчиненного подправить? Кроме того в нормальных фирмах в процессе работы над проектом сделанный код обычно отдают на ревью другой команде. И ревью делается не от балды, а в соответствии с документом по конкретному языку, где описаны  возможные ошибки с указаниям их рейтинга.  

зависит от методики работы, если в команде каждый работает над своей частью и code review проводить не принять, то всякое может быть =)

Vyacheslav, тебе видимо всегда везло, я видел полную противоположность. При обязательности ревью код просто ужасен,  и еле держится.

все перечисленные, кроме :

и

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

Это сообщение отредактировал(а) Torsten - 26.1.2009, 13:58

ага, и зависнуть на полгода, предугадывая все моменты которые могут поменяться в будущем =)

Добавлено через 4 минуты и 9 секунд
как правило у любого кода есть ограничения, они накладываются сроками и возможностями, какую-то одну вещь бывает иногда дороже сделать чем весь остальной проект целиком. 

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

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

Мне интересно, что вам будут отвечать 

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

Довелось мне работать с одним предугадывателем... после того, как его уволили, одному из наших лучших разработчиков пришлось переписывать ВЕСЬ функционал, написанный этим телепатом.

Давайте вспомним процесс разработки ПО для тех, кто его не помнит из институтского курса.

При любой модели жизненного цикла ПО у нас должны быть следующие процессы:
1. Анализ
2. Проектирование
3. Кодирование
4. Тестирование

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

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

Это сообщение отредактировал(а) ida - 26.1.2009, 17:21

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

отучит народ использовть глобальные переменные?  

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