If we as software developers want to both build great products and have fun doing so, we must be able to focus on the task at hand. Thus, our code should always compile. Our unit tests should always pass. We shouldn't have to battle a ton of misleading warnings and errors as our code is executed. In short, we must hold ourselves and our teammates to a high standard.
Why is all of that important? It's because writing software, and doing a good job of it, is hard. It's difficult enough just to implement a single new feature; it becomes a truly monumental task when, in addition to implementing the new feature, you have to figure out why the code no longer compiles, the database scripts error out, and why this one unit test, written 2 years ago, causes the build server to spit out a bunch of logs in Afrikaans and then burst into flames. Everything besides that feature is a distraction that will keep you from doing a great job on the task at hand while frustrating the lederhosen off of you.
I don't think any of that was a shocker to anyone. (If it was, you have my sympathy.) What's interesting to me is that this idea of keeping all of your working materials in line all of the time actually applies to a lot of different professions.
Check out this great example, from a seriously delightful book:
"As a cook, your station, and its condition, its state of readiness, is an extension of your nervous system - and it is profoundly upsetting if another cook or, God forbid, a waiter disturbs your precisely and carefully laid-out system. The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm's reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you'll quickly find yourself spinning in place and calling for backup.
I worked with a chef who used to step behind the line to a dirty cook's station in the middle of the rush to explain why the offending cook was falling behind. He'd press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped down with a moist side towel. "You see this?" he'd inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef's palm. "That's what the inside of your head looks like now. Work clean!" - Anthony Bourdain, Kitchen Confidential![]()
The great thing here is that working cleanly is just accepted in the world of cooking. You can Google for hours and I'm confident that you'd never find a thousand post thread on the culinary equivalent of StackOverflow, asking, "Should I keep my mise-en-place clean? What if I clean it right before I need something? What if I just move to a new kitchen for each meal?" They get it, just like we need to get it. (And since I'm quoting Anthony Bourdain here, I feel like he is now obligated to come to my house and make me a grilled cheese sandwich.)
I get tempted, once a month or so, to just hack something together and check it in. I know this is happening when I say a line that's as evil as non-dairy creamer: "I don't have time to do it right!" When I do check this code in, almost inevitably, something will come up shortly thereafter. A feature, quite possibly something I didn't even touch, isn't working right. I start investigating and I see, "Oh, it's this function." I dig a little deeper, "Oh wait, it's the crappy code I did last week." I go further still, "Hang on, maybe it's not this crappy code. Or maybe it is that crappy code, and I just happened to break a whole lot of stuff without realizing it." It's a painful lesson over and over again that there's no such thing as a shortcut in the world of development.
During times like that, I wish someone would press their palm onto my spaghetti code and hold it up. Then they could say, "You see this? That's what the inside of your head looks like now!" They'd be right.

Here's another great take on the same issue, from the legendary Uncle Bob: http://www.artima.com/weblogs/viewpost.jsp?thread=51769
Don't let Bourdain fool you I've worked in enough kitchens to know that no matter how well organized you begin the night it becomes a riot by closing.
Cooks have their own term for spaghetti code its called System D which Boirdain also writes about in The Nasty Bits.
The difference between a good chef and a bad chef is when they choose to use System D; a good one will use it in a jam, a bad one will use it whenever its convenient.
I think developers could learn a lot about how chefs organize their team and delegate work.
Great read, love the site.