Фатальный недостаток.

Есть у программистов черта, отличающая их от представителей других видов деятельности. А именно жуткая неприязнь к работе, выполненной другими программистами. Я уверен, у любого из вас, как и у меня, имея дело с чужим кодом возникал непреодолимый соблазн удалить все и переписать заново. Для этого есть даже специальный термин - "Фатальный недостаток" (недостаток чужого кода в том, что он чужой).
Благодаря склонности разработчиков видеть "фатальные недостатки" в уже существующих проектах, программные системы часто переписываются "с нуля", что является распространенной в индустрии ошибкой, ведь не меняя подходов к разработке и условий, новый код никогда не будет лучше старого.

http://lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA

Чему чебуречная "Советские времена" может научить разработчика?

То ли из-за фантомной ностальгии по временам, которых никогда не было, то ли из-за отсутствия добротных едален в центре Москвы повадились мы с коллегами посещать чебуречную "Советские времена". Кормят там сносно, да и чебуреки добротные. А если не обращать внимания на лики вождей и стены кумачового цвета, то и вообще можно отдать звание лучшего места для обеда за свои деньги.
Так вот в чебуречной этой довольно элегантно решена проблема нумерации заказываемых обедов. Первому человеку кассир на чеке пишет, например, номер 20, второму 21, третьему 22 и так далее. Иногда двум идущим подряд людям достаются одинаковые номера, но так как люди эти скорее всего из одной компании, при выдаче обеда они могут легко разобраться где чей.
Дело все в том, что кассир выбирает какой номер присвоить заказу просто взглянув на количество минут на электронных часах! Так как человек в процессе выбора блюда, оплаты тратит около минуты, коллизии случаются относительно редко и не столь критичны, люди могут легко получить информацию о готовности обеда, а главное не написано ни единой строки кода!
И вот вроде бы все прекрасно, система работает, на разработку и внедрение не потратили ни рубля, не хороший ли это пример для проектировщика программных систем? Ну разве что для тех случаев, когда код писать не хочется (не успевается), а показать что-либо нужно. А вообще, конечно, принцип единой ответственности придумали не просто так, и часами должны пользоваться для получения времени, а для заказов нужен отдельный каунтер.

О чем спорят программисты?

Мир разработки программного обеспечения многополярен. В нашем распоряжении сотни языков программирования, десятки виртуальных машин, фреймворков и библиотек для решения всевозможных задач, несколько методологий и ворох операционных систем. Все это вызывает огромное количество пересудов между адептами тех или иных технологий, что ведёт к сильной технологикоцентричности большинства споров разработчиков. Их можно понять, ведь на изучение очередного фреймворка нужно потратить иной раз огромное количество часов собственной жизни, что не может не приводить к некоторой привязанности, но не стоит забывать, что действительно важные аспекты разработки это чистая архитектура, грамотное проектирование и расстановка четких границ между компонентами, а споры должны отвечать лишь на вопрос: помогают ли ваши средства добиться этих целей?
Также нужно уметь иногда отвлекаться от программирования и сидя в пятницу вечером в баре в компании друзей выбирать для споров более приятные темы, вроде актерского мастерства пассии Бергмана в каждом из его фильмов или, например, вкусовые качества тайваньских улунов по сравнению с южнофундзянскими.

О чем кричит ваша архитектура?

Посмотрите на структуру вашего проекта. О чем кричит организация модулей и пакетов? В подавляющем большинстве будет что-то такое:
- контроллеры!
- сервисы!
- репозитории!
- я проект на Spring! (Node, Django, Grails нужное вставить)
А должно быть так:
- я система банковских транзакции!
- я социальная сеть!
- я почтовый сервис!

Заставьте вашу архитектуру кричать о своем предназначении.