[dheera]

I think there are a lot of conflicting ideas at play here. As a coder, yes I can write good code. But however, everyone I know in the valley tells me "just shut up and launch, it doesn't have to be good. You should have launched yesterday, that's what they would have told you at YC". This advice have a lot of truth to it, because you need to get feedback, validate your project, and perhaps have the first-to-market advantage in the highly competitive world of technology today, with investors and customers hounding you on both sides. However, this hasty, rushed culture necessarily will result in a lot of poorly-written code being deployed (followed by a lot of rewrites), even by decent coders, because they simply aren't given the time and runway.

[bgoerdt]

The situation is very different when creating software for internal use in large corporations, which I think was the case with this study. With a startup, launching early can get you the advantages you mentioned, and your code quality does not necessarily have to be high because you generally will not have many users at the start. Large internal software must be highly functional and performant from the first deployment because it will immediately be used by the whole company and will often affect revenue streams. This allows low quality to have a huge impact from day 1.

[mikekchar]

If you write code that solves a people problem and allows your project to move forward, no matter how stinky that code is, that code is "good code".

By nature, we programmers often judge our code on its technical merits. But a stinky piece of crap that I might write that shows me clearly what I need to build, or demonstrates the techniques that are required, or shows that something isn't going to work early, etc can have immense value.

Writing stinky code is a tool that every programmer can use. The trick is to know when you should use it and when you should not. If done properly, you can solve some intractable problems dealing with requirements gathering, design, or even political problems. When used improperly it can have exactly the opposite effect -- it pushes requirements gathering back, or defers important design decisions until it is too late, or creates conflict within the team.

I know some people in the industry who are pretty good at this, but I know of nobody who is a master at it. Not only do you need to be good at it personally, you need to be able to influence the team to coordinate their work in a way that is not destructive. This requires you to have impeccable taste, amazing technical ability and sublime communication skills. It is a skill that I wish more programmers would value and work towards.

[nandemo]

If the code is stinky, it's bad code. It can still be have business value, which is why somebody coined the term "technical debt".