Software Development

I'd take #1 every time. Guess why! With #1, I know what I'm getting. With #2, it's rolling the dice.

What I'm saying is that I'll take code I understand over code I don't any day of the week. I can fix the first one and can easily tell what they were going after. This is true because in order for me to know code is crap, I have to understand it. And crap code is usually understood as such by everyone immediately. I'll likely end up replacing the whole thing, but at least I know what the goal was. Most code, believe it or not, is simply devoid of any indication of what the author's intentions were.

So is crap code preferable to undocumented code?

You know how DVD's come with commentary? I wish code was like that. I'd have manuals come with all of my code if I could do so. I would write you the history and religious background from whence that code came.

Once there was a man that walketh the Earth with a vision... He had a dream that his computer was not so damn stupid. He is still dreaming today. But his quest for a brighter future lives on. That is why the following code is crap. Not for lack of effort, but because such a stupid machine deserves code made in its image.