[nilkn]

If the majority of code is shit, then it's not really a very useful observation to make repeatedly. So I think this goes back to the author's point that this is really a cultural or attitude issue.

It's like the friend who complains about everything all the time: constantly complaining about traffic, about the weather, about how the city is losing its charm, about his job, about his classes, about his parents, about his car, about his apartment, about politics, about how stupid people are, etc. etc., with nothing positive to say. Maybe it's all correct from some perspective, but it's not a very useful perspective and it's definitely an annoying one to be around.

[Jach]

There is at least one useful implication to the observation, and that's that most (or all) software is shit. Yet people still use and buy it. The implication is a nice three-edged sword. You're guarded against crippling perfectionism, you're striving to get out of the shit as much as you can, and for developers you will always prefer having the source if you want to fix some shit. This article made me remember this from my quotes file:

"All software sucks, be it open-source [or] proprietary. The only question is what can be done with particular instance of suckage, and that's where having the source matters." --viro

[RogerL]

That is not my experience. There is a ton of good to extremely good code out there. I'm rather dismayed by the amount of "well, what can you do" hands-thrown-up attitude here.

I've always found clean code to be faster to develop. I find that developers that produce lower quality code tend to spend their days debugging, fighting their code, reading and trying to figure out what they wrote 5 months ago, and so on. They are just not very productive. There are the outliers - people that have instant recall of all their code and elaborate mental models of really poorly structured code - but by and large I find that people that generate low quality code are quite slow performers.

I've worked in very good code bases, and very bad ones. In the good ones you can easily figure out what is going on, quickly make changes, confident that you aren't breaking 5 things because things are decoupled. You can produce new code quickly because you aren't fiddling with code nested 6 if statements deep, which is just about impossible to model correctly in your head. You aren't in endless compile/run/debug (or REPL/run/debug) cycles because your first try is usually just about right, because you can understand the surrounding code. I recently requested a simple feature, and was told it would take a week. I was dubious. Then I looked at the code, and decided that they were being conservative, if anything... for something I thought would reasonably take a few hours.

This is just an impassioned plea, not to Jach, but to the profession, to cast a critical eye on code. You can produce high quality code quickly. Not "nuclear reactor" quality, but pretty close. Bad code always costs you. Always. Don't write that way, don't allow it in your code base, or in your teammates.