Lost GMs

"House of Cards" is not correct, it implies a level of organization and structure that software development can not meet.  Agreeably, any given piece of code is many times more stable than any single card.  Also agreeably, stacks of code are generally many times more stable than stacks of cards.  But some stacks of code fall down over and over and over and are darn well impossible to correct.  Like stacking cards in a wind tunnel.  That's the strength and weakness of software in a nutshell.  So many young developers seem to think that a completed function will always "just work".  They don't realize how many pieces of code that have been around for decades still don't work as they are supposed to because no one ever tested them extensively or got priority (from management) to fix them when told they were broken.  These legacy issues create mountains of cascading "work arounds " and bugs and then if "corrected" create mountains of fixes to the fixes.  Of course, all that is hidden behind a massive complex of coders, 60 hour workweeks and "patches".  Management addresses this by seeking the lower and lower cost "mythical man month" coder (as you move up the pyramid) and the whole thing stumbles on in mediocrity as advancing hardware hides the inefficiencies .  That, in a nutshell, is 90% of the software industry today.

The trouble is, software is a non-linear system of exponential complexity and there are no quality metrics and no way to perform a mathematical stability analysis.  It's a crap shoot with the short term odds in your favor and the best tool available is usage based quality control.

Not reviewing and classifying  every "identified" flaw in a system is a mistake.  Likely a little mistake, potentially a big mistake, but there is no system to differentiate.  Yes, professional quality control would reduce the number of flaws the developers need address (that should be a job at Illy) but they "can't afford that".  Sure, spelling errors are trivial, unless they are in a DB and some dev starts matching things based on spelling.  How do you classify petitions as "important" or not unless you review them and identify the cause (or at least identify the likely underlying functions).  Maybe you have 500 petitions, all looking obscure and different but all floating over some very common code that you're depending on for your new "big thing".  What exact methodology let's you determine if a petition is "important" or not?  How exactly (that word is the rub) do you know that you can ignore 90% of the petitions unless you look at 100% of the petitions?  If your quality control system sucks that bad, then you need a new quality control system.  If the petition system isn't part of quality control, then what is it?  If you can ignore 90% of the petitions but you don't have a system to identify that 90% then you should probably ignore 100% of the petitions and eliminate or re-tool the petition system.

Personally, not fixing a simple spelling mistake is just lazy.

Llyr wrote: In my 30-year career our unofficial motto was "there's never time to do it right, but there's always time to do it over".

again, i'm certain that the suspension of time and resource constraints would result in much more solid software.  (actually, i am not, because much software suffers from a failure to identify correctly its purpose at the outset, or to build with change in mind, but the *management* impact on quality would disappear with the elimination of time and resources as considerations.)  this is a bit like saying that getting uphill would be easier without gravity, though, so i don't see it as a very fertile topic.  if one is preparing appetizers for said party and they aren't quite up to one's usual standard, i would argue that quality is best served by delivering them in time rather than better the next day.  i wonder how the workers in any of the companies in which you served would have reacted if management had decided to put off a product release for month with the announcement:  "we understand your priorities.  we won't be able to pay you for August, but the product will be something of which you can be proud."

Llyr wrote: You can get away with providing an inadequate product or service only if you're the only one who has it and customers are willing to overlook the problems because they really want the benefits.

i've no idea in what sense you're using "inadequate".  if you mean that the product or service does not satisfy *all* of a customer's needs, inclusively, then all products and services are inadequate--else you would need only one.  if you mean inadequate in the sense that it does not deliver benefits that outweigh the disadvantages (including time to learn, to implement, etc.), then it is not applicable here, since customers would not continue to purchase or use it (and we wouldn't be "getting away with providing" it.)  if you mean "inadequate" in the sense that customers' expectations are not met, that is as easily a problem with marketing as it is with quality.  products can only be inadequate *to* some standard, and their inadequacy is usually considered proven or disproven by the market.  in the case of illyriad, the player base is deteriorating, which might indicate inadequacy, but i think it has little to do with petitions going unanswered.

Llyr wrote: Not caring about minor problems will be viewed as not caring about major ones either (the "broken windows" principle).

if this is the theory to which you refer (http://en.wikipedia.org/wiki/Broken_windows_theory), it would seem to be applicable only to the builders' attitudes about the product, as customers cannot break more windows.