Does good code make good software?

(what is "good" code and "good" software?  See my previous post.)

In most areas of life, using bad materials results in a bad product.  Cheap lumber?  Your deck will look warped and/or need to be replaced in 5 years.  Bad ingredients?  The meal isn't going to taste good (though I imagine a skilled chef could mitigate that somewhat).

However, over the years I've been very surprised at the connection (or lack thereof) between code quality and software quality.

• I worked on an ASP.NET project which discouraged the use of the ViewState, and instead stored everything in the Session.  This resulted in bloated memory usage, poor performance when marshaling the session to / from the state server, and a myriad of hidden (and untestable) dependencies among classes which required certain Session data to be set or updated at certain times, by other classes.
   
• Once, my development manager forbade the use of common, re-usable helper classes / functions; he wanted all logic copied into every function that used it, because he "didn't like looking all over the code for the implementation".
   
• Another project was composed of two completely separate systems (even though both systems were being developed simultaneously by the same team).  Almost every operation required multiple communications between the two systems.  Each system retained its own copy of data; if the data ever became out-of-sync between the systems, it caused numerous subtle errors.  There were no automated or periodic checks to ensure data was in sync.  Out of sync data could only be repaired by one of the system experts manually adjusting the data using SQL.  But that's ok because "the systems will always work perfectly, once we pass QA".
   
• I worked at a company that had a nicely-encapsulated software platform... then started every new client project by copying the entire codebase.  Bugs fixed for one client never made it to the other clients' systems - unless / until those other clients complained about them too.  Platform enhancements were very slow to roll out, as they had to be implemented for each client individually.
   
• On one very "enterprise-y" project, the home-grown framework required creation of 4 classes, 3 config file entries, and 3 database entries - just to implement a simple "are you sure" dialog.  It took several seconds to execute, as it necessitated two postback operations to open the dialog.  The same behavior could be achieved with sub-second execution time and 1 line of javascript code; however use of the home-grown framework was mandatory.

The above approaches would be considered laughable in any conversation among experienced developers, and would probably result in a failing grade on any professional certification test. Yet all of the companies above are successful, have been in business for years (in some cases, decades), have a large following of loyal customers, and have products which are widely regarded as effective and reliable.

In other words, in all of the cases above, bad code and development practices have produced good software.

I'm not so jaded as to believe that code quality has NO impact on software quality.  Every one of the systems above could have been improved by well-crafted code and better methodologies and design.  However, as much as I wish it weren't true, it's clear that very good software CAN result from very bad code.  This is even more true when you measure software quality by the only metric that truly matters to a company: profitability.