I've seen quite a lot of debate with hard lines of what defines "good" code. In my admittedly limited experience, I've found that the definition of "good" varies with the situation in which the code is written. "Good" in my opinion is not something that has a concrete definition. It's entirely dependent on the requirements of the project, and how the developer meets them.
-Sometimes this means a programmer can drop into the style already in use on a project, even if it's not the 'best' approach. That way his changes are low-impact and can be easily understood by the people who have worked in the system for years.
-Sometimes this means the programmer needs to architect a complex solution to a hard problem. (Though I think this is an assumption we make far too frequently.)
-Sometimes this means the programmer should spend some time understanding the constraints on the project, and express them in code. If a constraint is acceptable at least until the next major version of a piece of software, then why not focus on making it simple to alter the assumption, rather than adding complexity to avoid the assumption completely?
-And sometimes, this really does just mean "Ship that mess by next Friday", regardless of the cost. Sometimes it's just more important to get a poorly architected version in the hands of users that just does what it says on the tin, especially if their input could drastically change your requirements.
-Sometimes this means a programmer can drop into the style already in use on a project, even if it's not the 'best' approach. That way his changes are low-impact and can be easily understood by the people who have worked in the system for years.
-Sometimes this means the programmer needs to architect a complex solution to a hard problem. (Though I think this is an assumption we make far too frequently.)
-Sometimes this means the programmer should spend some time understanding the constraints on the project, and express them in code. If a constraint is acceptable at least until the next major version of a piece of software, then why not focus on making it simple to alter the assumption, rather than adding complexity to avoid the assumption completely?
-And sometimes, this really does just mean "Ship that mess by next Friday", regardless of the cost. Sometimes it's just more important to get a poorly architected version in the hands of users that just does what it says on the tin, especially if their input could drastically change your requirements.