I understand that time to market can sometimes be a differentiator and its acceptable to build a quick and dirty MVP. Version one of a startup's codebase is going to be messy because you are constantly making tradeoffs to survive. Once the startup leaves crunch mode, engineering leadership should be allocating at least 10% of engineering time to refactoring. Otherwise the bloated, unstructured codebase could be holding the organization back from building the next market defining feature in time to beat the competition.
Certainly plenty of people thought so at the time (including myself, as well as Microsoft's execs, or they wouldn't have done it), but although without the underhanded tactics they would have had a somewhat smaller market share and correspondingly smaller profit margins, in hindsight they would still have been the dominant platform vendor for desktops, office suites, and back office servers.
It turns out that Microsoft's strategy of sucking customers in with 'Better Together' all-MS integrated offerings, never making a customer have to consider another vendor because some custom in house software they rely on won't run anymore due to an upgrade (no matter how poorly), and as a distant second, introducing breaking changes for competing vendors' offerings wherever they could (eg. 'Windows isn't done until Lotus won't run', and even that tactic was eventually abandoned due to the overhead it introduced), was all they needed in order to maintain and grow their early lead.
> This book seemed convincing when I read it in college. It even had all sorts of studies backing up what they said. No deadlines is better than having deadlines. Offices are better than cubicles. Basically all devs I talk to agree with this stuff.
> But virtually every successful company is run the opposite way. Even Microsoft is remodeling buildings from individual offices to open plan layouts. Could it be that all of this stuff just doesn’t matter that much? If it really is that important, how come companies that have drank the koolaid, like Fog Creek, aren’t running roughshod over their competitors?
The answer is in another recent post (http://danluu.com/sounds-easy/#fn:S):
> For a lot of products, the sales team is more important than the engineering team.
Put another way, every measure of engineer / software quality and project success (including the qualitative ones that are harder to measure) like delivering on time / under budget, correctness of implementation, system performance, uptime / reliability, number of bugs, ease of maintenance, minimal technical debt, etc. etc., are very often only nice-to-haves. Not necessarily all of them at all times, but often enough most of them except one or two (not the same one or two, though).
Which is a good thing, or startups would never be able to trade off covering edge and corner-cases, or scale, or 'standard' feature-completeness, etc. in favor of new and game-changing capabilities (or business models) & incumbents could never be disrupted.
But as it happens, we know that 'worse is better' in lots of ways and in lots of circumstances. So companies that 'drink the kool-aide' and focus on developer productivity and happiness may produce 'better' software by any and all measures you care to use as a developer, instead of focusing on only the most important ones that directly relate to optimizing the customer acquisition funnel and subsequently reducing customer churn.
At the level of the corporation, programming is a competitive sport, but companies are not scored on software quality, or developer productivity, or developer happiness. Companies are only scored on 'getting and keeping customers' and 'making a profit' (which may require paying attention to some quality measures, just not all of them all the time).
Put yet another way: If you're doing Lean Startup / Customer Development right, the customer decides what 'quality' means, not you.