a) too long (in terms of development cycle duration) to recode all the components to a certain industry standard (i.e. by the time they have the next development cycle published it is already semi obsolete and surpassed by the competition).
-or-
b) too expensive to contract out or purchased from 3rd partys.
Depends on the underlying software structure. If you don`t cut corners, define meaningful and clear interfaces etc., refactoring existant and exchanging old for new code are pretty simple.
HTC has the advantage of knowing his way around his code easily.
With bigger teams, a lax enforcement of software development rules results in a growing mess of code which *noone* can modify before delving deep into the workings of the given code.
When you have a magnitude of change not bearable with the old software, rewriting it from scratch should be easy (as in 10 times faster than building the old software from scratch), because you already know the general workings of the solution.
So, the problems you pointed at are entirely avoidable. Note that even in professional business software developement, they *aren`t avoided generally* !
Now if you reach a point where the incoming money can't bring the new or improved software to produce more money, you loose. You either have to rush an unfinished product, or fold up the project.
So for the cases you mentioned:
IL2/Maddog: They`ve got a well coordinated team, and probably adhere much to good software design guidelines. Also, qualified Manpower is very much cheaper in Russia than in the US/Euroland
WB: A show of particularly bad software design. Lots of developers, where the left hand doesn`t know what the right one is doing. Look at all the inconsistencies in their FM....
HTC: At the given time, getting more manpower is futile, because the candidates would have to learn the workings of the old software (taking
*away* from HT's already sparse time) before they could be productive.
OT: Let HiTech hack away and wait. There's nothing more annoying to a programmer than guys asking "when is it done" while he's got his mind a few thousand lines of code up a problem. Even answering such a question usually costs me my concentration for 10 minutes or so before on the problem at hand again.