[bcrl]

I think there's a difference between companies that build software for the market versus those that build software for a contract. The former tends to be driven by a team that believes in the product that they're trying to deliver, has a management team that has at least some vision for the software and investors that believe in the company's approach to the market. They want to make software / a product that represents the organization well and has long term value.

In the latter case, like so many government sponsored engineering projects, the company has no real long term incentive beyond what is written into the contract. Management isn't driven by the software being produced so much as meeting the contractual requirements that result in payments. In my experience, software contracting houses are a lot more likely to hold schedules over the heads of developers, and that's purely driven by the terms of the contract (billable hours). In contrast, even when I have been a contractor for a company that is building the product for itself, they tend to push for the goals of the project while ensuring it meets the needs of the company. The difference in pressure as a developer is quite substantial.

[SpicyLemonZest]

I think you'd be surprised to see how much of the roadmap at a typical "build for the market" company is driven by specific contracts. In my experience, the proportion is high even in consumer tech, and easily clears 75% for even the most commoditized of enterprise software. The stereotypical contract shop is distinguished more by poor planning and an aversion to shared architecture than any real difference in incentives.