Действитеьно, всё зависит от того, как мерить будем. :)
Для мнея проект в 100 тыс. строк сейчас считается средним и на него уходит от полугода до года. Когда-то это был "Большой" проект. А если всё нормаьно получится с организацией толковой команды (несколько человек уже есть), то для нас это будет уже маленький такой проектик. :)

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

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

:) На счёт "втрое больше", это зависит от того, как заключался договор. Часто сроки выполнения проекта специально занижаются, чтобы заключить договор. А потом уже заказчику деваться некуда будет. Время потрачено, деньги какие-то тоже, да и какая-то часть работы будет сделана.
Хотя, я знаю случаи, когда по прошествии отведенного времени исполнитель приходил к заказчику, говорил: "ну не смогла я", и сваливал! Правда, после этого ему во многие места вход оказался закрыт, но было и такое.

Vdimas, а почему на C++? Я в своё время попробовав и то, и другое остановился на Delphi. Может код получается и чуть-чуть побольше, зато отлаживать и поддерживать проект проще. Object Pascal язык более строгий, чем C++ и многие ловит ошибки, которые тем же C++ будут пропущены (в следствии особенностей инвариантного синтакиса).

Хотя, в принципе, сам когда-то начинал на C и даже несколько несложных проектов на C++ в своё время сделал. Но когда некоторое время назад предложили работу на C++ под MFC, я отказался даже не смотря на хорошие деньги, которые обещали заплатить. Поставил себе Microsoft Visual C++, попробовал, и понял, что слово Visual там ради понтов тоит, а возвращаться во вчерашний день не хочется.

В C++, конечно, есть множественное наследование классов, которого иногда в Object Pascal не хватает, но при решении практических задач, которые реально встречаются, мне имеющихся возможностей вполне хватало. Особенно если учесть, что первые программы я начинал писать на ассебмлере для 8-разрядных машин с 64 Кб памяти... :)
Кстати, очень хорошая школа. Многому учит, особенно экономии ресурсов и оптимизации кода.

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

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

Ага. Проблемы, как я понимаю, у всех одни и те же. :) Особенно с орг. вопросами. Как говориться, мало быть хорошим програмистом, нужно ещё уметь своё мастерство первращать в твёрдую валюту. :)

Кстати, на код хотелось бы взглянуть. Я в своё время тоже себе соорудил подобную библиотечку, только на Delphi. Правда, не могу сказать, что она очень компактная и оптимизированная. Но мне пока для своих коммерческих проектов хватает.

Только сразу предупреждаю, что всё бесплатно и никакого поиска ошибок и всяких там "cde review' не будет. :) Но если что придёт в голову интересного, то поделюсь (тоже, кстати, бесплатно).

Я так понимаю, что имеется в виду то, что в Delphi делается с помощью ключевых слов virtual и ovveride.
То есть, использование механизма позднего связывания, когда адрес вызываемого метода (вложенной в класс процедуры или функции) определяется не компилятором, а вычисляется по таблице адресов виртуальных методов того класса, к котрому реально принадлежит объект. Это удобно, когда система классов достаточно развита и вышестоящие уровни описывают только общие свойства и методы, а их потомки реализуют то же самое для более частных случаев. При этом, когда выполняется метод из класса-предка, то он будет в нужных местах не свой метод вызывать, а тот, который позже будет у потомка описан.
При обычном же наследовании можно и в предке, и в потомке объявлять методы с одинаковым названием (перекрывать). Но в этом случае предок ничего не знает о методах потомка, которые были написаны (объявлены) позже, а потому из его методов будут вызываться только его же методы.

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

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