Coding Horror

In Screwdrivers versus Couture, Ed Stroglio nailed the real difference between PC enthusiasts and Mac enthusiasts:

One might think case modders or overclockers [or developers] in general might be more prone to the Mac outlook, but that's not really so. What such people are proud of is not mere ownership of the equipment, but what they've done to it to make it what it is. It's a much more hands-on sense of accomplishment: what has been done rather than what it was out of the box.

PC enthusiasts are all about the D.I.Y. aspect of the PC. Sure, Dell's designers are laughable, but that's not the point. We make the beige box what we want it to be:

PC case modifications
Apple G5 case

I'm not saying one is inherently better or more aesthetically pleasing than the other. They just come from very different places. Apple's G5 systems are the product of a world-class design team and stamped out by the thousands; custom PC builds are the highly individual result of dozens or even hundreds of hours of personal investment.

This same D.I.Y. ethic also extends to PC software. Specifically, open source software. I know there's nothing that ties open source development to the PC platform in particular, but certainly Linux was born on PC hardware and the entire open source ecosystem is built primarily on PC hardware. Isn't building custom software a little bit like hot-rodding your automobile?

I read this [Edmunds] article and was struck by the similarities between this and the open source vs COTS model.

COTS (Commercial Off The Shelf) software is equivalent to a stock automobile. They're built by professional engineers, and tested as a whole. But you don't get to mess with the system.

On the other hand, open source gives you the ability to join the software equivalent of the tuner/modified market - you can tweak the system to your hearts content. You may make it go faster, but you're not totally sure what it's going to do to the overall quality of the system.

In fact, I constantly read that that's one of the huge benefits of open source - on an open source project, if you don't like how something works, you can just step in and fix it, while with COTS you don't have that ability.

Tinkering and tweaking isn't limited to open source projects; it applies to COTS software, too. I'm a COTS Windows user, but I have a dozen different utilities and tweaks I have to install before I'm happy with my build. I know plenty of users who go even further and retrofit the entire GUI using WindowBlinds.

While I certainly appreciate Apple's ability to box up elegant hardware designs with an elegant UNIX GUI makeover, that just isn't for me. I have more fun when I do it myself.

In an era of instant online worldwide connectivity, protecting users from themselves is a lot harder than it used to be. For one thing, full trust can't be trusted. And then there are all those dancing bunnies to contend with:

What's the dancing bunnies problem?

It's a description of what happens when a user receives an email message that says "click here to see the dancing bunnies".

The user wants to see the dancing bunnies, so they click there. It doesn't matter how much you try to disuade them, if they want to see the dancing bunnies, then by gum, they're going to see the dancing bunnies. It doesn't matter how many technical hurdles you put in their way, if they stop the user from seeing the dancing bunny, then they're going to go and see the dancing bunny.

There are lots of techniques for mitigating the dancing bunny problem. There's strict privilege separation - users don't have access to any locations that can harm them. You can prevent users from downloading programs. You can make the user invoke magic commands to make code executable (chmod +e dancingbunnies). You can force the user to input a password when they want to access resources. You can block programs at the firewall. You can turn off scripting. You can do lots and lots of things.

However, at the end of the day, the user still wants to see the dancing bunny, and they'll do whatever is necessary to bypass your carefully constructed barriers in order to see the bunny.

Here's hoping Longhorn (aka Windows Vista) is the first Microsoft OS to default users to non-administrator accounts. Because users can't help themselves-- they just have to poke the bunny.

I think the real solution, if there is one, is high-speed virtualization. The user will always play in a sandbox that looks and performs exactly like their current installation, but is in fact a Virtual PC style image. If something bad happens, you just ball it up and throw it away.

I picked up a copy of The Best Software Writing I: Selected and Introduced by Joel Spolsky. It's essentially just a collection of Joel's favorite blog entries from the last few years. But it's Joel, so you know they're going to be good ones. In the introduction, he explains why he's so enthusiastic about blog writing: it encourages the simple, but powerful use of show, don't tell:

The publisher wanted to get a quote from me to put on the back cover talking about how wonderful his book was. Normally I'd be happy to do that; I'm a complete publicity slut and will do just about anything to get my name in front of the reading public. My hope is that if I do this enough, telemarketers who call me at home will be able to pronounce my name.

The book started out looking promising. It filled a real need. I remember several times standing in bookstores desperately trying to find a book on the very topic, but there was nothing to be found. So I started reading the manuscript full of high hopes.

Bleah. I could hardly bear to keep reading. The author kept saying smart and interesting things. He even wrote clearly. But the book was thoroughly, completely, boring. And worse, it was completely unconvincing.

The author had violated the number one rule of good writing, the "Show, don't tell" rule. There was not a single story in the book. It was chock full of sentences like "A good team leader provides inspiration by setting a positive example." What the eff?

Pay attention. Here's the way to say "a good team leader provides inspiration by setting a positive example" without putting your audience to sleep:

For a few months in the army I worked in the mess hall, clearing tables and washing dishes nonstop for 16 hours a day, with only a half hour break in the afternoon, if you washed the dishes really fast. My hands were permanently red, the front of my blouse was permanently wet and smelly, and I couldn't take it any more.

Somehow, I managed to get out of the mess hall into a job working for a high-ranking Sergeant Major. This guy had years of experience. He was probably twenty years older than the kids in the unit. Even in the field, he was always immaculate, wearing a spotless, starched, pressed full dress uniform with impeccably polished shoes no matter how dusty and muddy the rest of the world was around him. You got the feeling that he slept in 300 threadcount Egyptian cotton sheets while we slept in dusty sleeping bags on the ground.

His job consisted of two things: discipline and the physical infrastructure of the base. He was a bit of a terror to everyone in the battalion due to his role as the chief disciplinary officer. Most people only knew him from strutting around the base conducting inspections, screaming at the top of his lungs and demanding impossibly high standards of order and cleanliness in what was essentially a bunch of tents in the middle of the desert, alternately dust-choked or mud-choked, depending on the rain situation.

Anyway, on the first day working for the Sergeant Major, I didn't know what to expect. I was sure it was going to be terrifying, but it had to be better than washing dishes and clearing tables all day long (and it's not like the guy in charge of the mess hall was such a sweetheart, either!)

On the first day he took me to the officer's bathroom and told me I would be responsible for keeping it clean. "Here's how you clean a toilet," he said.

And he got down on his knees in front of the porcelain bowl, in his pressed starched spotless dress uniform, and scrubbed the toilet with his bare hands.

To a 19 year old who has to clean toilets, something which is almost by definition the worst possible job in the world, the sight of this high ranking, 38 year old, immaculate, manicured, pampered discipline officer cleaning a toilet completely reset my attitude. If he can clean a toilet, I can clean a toilet. There's nothing wrong with cleaning toilets. My loyalty and inspiration from that moment on were unflagging. That's leadership.

See what I did here? I told a story. I'll bet you'd rather sit through ten of those 400 word stories than have to listen to someone drone on about how "a good team leader provides inspiration by setting a positive example."

True enough. And even if you don't entirely agree that Joel's choices are "The Best Software Writing"*, they're still pretty darn good:

1. Style is Substance, Ken Arnold
2. Award for the Silliest User Interface: Windows Search, Leon Bambrick
3. The Pitfalls of Outsourcing Programmers, Michael Bean
4. Excel as a database, Rory Blyth
5. ICSOC04 Talk, Adam Bosworth
6. Autistic Social Software, Danah Boyd
7. Why not just block the apps that rely on undocumented behavior?, Raymond Chen
8. Kicking the Llama #4, Kevin Cheng and Tom Chi
9. Save Canada's internet from WIPO, Cory Doctorow
10. EA: The Human Story, ea_spouse
11. Strong Typing vs. Strong Testing, Bruce Eckel
12. Processing Processing, Paul Ford
13. Great Hackers, Paul Graham
14. The Location Field is the New Command Line, John Gruber
15. Starbucks Does Not Use Two-Phase Commit, Gregor Hohpe
16. Passion, Ron Jeffries
17. C++ - The Forgotten Trojan Horse, Eric Johnson
18. How many Microsoft employees does it take to change a lightbulb?, Eric Lippert
19. What To Do When You're Screwed, Michael "Rands" Lopp
20. Larry's rules of software engineering #2: Measuring testers by test metrics doesn't, Larry Osterman
21. Team Compensation (pdf), Mary Poppendieck
22. Mac Word 6.0, Rick Schaut
23. A Group Is Its Own Worst Enemy, Clay Shirky
24. Group as User: Flaming and the Design of Social Software , Clay Shirky
25. Closing the Gap, Part 1, Eric Sink
26. Closing the Gap, Part 2, Eric Sink
27. Hazards of Hiring, Eric Sink
28. Powerpoint Remix, Aaron Swartz
29. A Quick (and Hopefully Painless) Ride Through Ruby (with Cartoon Foxes), why the lucky stiff

You can save your $22.49 with a few deft mouse clicks, but I think it's reasonable to have these entries in book form, with Joel's typically insightful introduction for each entry. The book works quite well as a survey overview of the outstanding blog content that most people still don't even know is out there.

* For example, I couldn't even bring myself to finish reading Paul Ford's rambling, incoherent novella Processing Processing. Good Lord. I'd also drop the last one with the foxes on Ruby. It was neither funny nor particularly instructive. I don't mean to be overly negative; these are definitely the exceptions. The rest are quite good..

It's funny because it's true:

A Software Engineer, a Hardware Engineer and a Departmental Manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt, scraping along the mountainside. The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?

"I know", said the Departmental Manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals, and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

"No, no", said the Hardware Engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it, and we can be on our way."

"Well", said the Software Engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again."

In all seriousness, I can't recall a single week that I haven't done this exact thing at least once: Geez, I dunno, just run it again and see if the problem recurs. I don't know if it's a sad indictment of the state of software engineering or a not-so-subtle hint that software engineers deal with thousands of variables in even the simplest of programs.

Via Scott Hanselman:

I've been reading as much as I can on how to be an effective manager lately. For a number of reasons, mostly internal, but also because in a recent lunch Chris Sells said (something like): "If you're not getting slapped by your boss at least twice a year, you're not pushing the envelope enough."

He then links to a set of management rules, specifically highlighting number three:

If you are not criticized, you may not be doing much.

There's a fine line between pushing and pushy, but you have to push. You may get slapped, but so what? Anything is preferable to indifference or, worse, the same old cliches.