А в каком документе прописано, что сторонняя фирма-разработчик компонентов ПО отвечает материально за потери, возникшие при их неправильной работе? Это каким-то образом письменно оговаривается при покупке компонента?
Думаю, не очень-то просто будет заставить разработчика компонентов выплатить компенсацию.
Практика управления рисками показывает, что для сложных задач первоначально оцененное время для разработки необходимо умножить на 3. Это и будет более или менее адекватное время разработки.
Если программист слишком часто употребляет слово fuck это указывает о скудности словарного запаса и ограниченности. Мне кажется, такому программисту сложно будет сложнее пробиться в менеджеры проектов.
Турбо-паскаль… Ностальгия )) Я учился программировать на Паскале. Осваивал с его помощью базовые понятия языков программирования — массив, переменная. Даже сейчас, при более чем 10-летнем опыте программирования на С++, Java и других си-подобных языках, считаю паскаль довольно неплохим процедурным языком.
Верно подмечено про написание велосипедов при разработке ПО. Вообще большая тема для обсуждения, часто с этим сталкиваюсь. Во фреймворке, особенно большом, часто необходимый функционал уже реализован, а программист даже понятия об этом не имеет. Как результат такого подхода — увеличение стоимости продукта и ухудшение качества.
Grails — действительно очень удобный фреймворк, активно его используем в разработке. Действительно, он основан на вышеупомянутых технологиях. Отличие в том, что разрабатывать веб-приложения на нём гораздо быстрее, чем на связке «Java + Spring + Hibernate». Он и позиционируется как средство для agile-разработки.
Хороший сервис, я пробовал воспользоваться бесплатным вариантом(одновременно до 50 пользователей) для оценки производительности моего веб-сайта, написанного на Grails
Думаю, не очень-то просто будет заставить разработчика компонентов выплатить компенсацию.
Интересно, какой именно мат. метод они используют?
Заранее спасибо!