I think the trouble is that with software, if you can properly state the problem you can usually state the solution in code. It means once you've properly identified a weakness you'll already be halfway to planning the solution. Would you prefer to own up to something people might not even have pinned on you? Or would you just rush to fix it and enjoy the praise for innovation when it's done?
e.g. One of the supposedly inevitable aspects of databases used to be that a lot of locking must occur. What's the solution to too many people and processes reading and altering the same bits of data? Err...don't.. At least find ways to make transactions really quick then keep your fingers crossed. READ UNCOMMITTED is what many still dangerously resort to because of this and even READ COMMITTED doesn't guarantee you consistent data from a given instant in time. Before 2005 do you imagine Microsoft were thinking 'Well, a mostly good solution would be to do like some other DBs and build snapshots in the background and query those". Of course they did but they didn't come out and make a big noise about how the paradigm was fundamentally flawed for high transaction environments. They bided their time till they could get Snapshot Isolation Level implemented. You'd do that yourself if it was your own program and you had pride in it. In a community of eagle-eyed users, you'd be desperate to fix quickly rather than do all the criticism for them.
Adam