I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

My lyrics are bottomless

It’s a pretty amazing feeling to be walking to work, listening to one of my favorite podcasts, and hear the cast completely call me out personally (fourth bullet) for a flame post I wrote last week. (And to do it with a song I’ve coincidentally had in my head all week.)

Jeff Atwood and Joel Spolsky complained that I didn’t cite any examples and wasn’t constructive. I agree, and I regret that, so I’ll try to rectify that now.

I wasn’t specific enough about my criticism, because honestly, I’m a lazy blogger and don’t like to put much time into research when I’m spouting off my opinions. Most bloggers are like this — at least I’m honest about it.

But you’re right that such a strong criticism deserves some elaboration. So here’s a brief list of only what comes to mind right now that has bothered me:

As I understand it, Stack Overflow will use OpenID as the sole account authentication mechanism. The process of obtaining an OpenID is so confusing and overly complex that this will discourage many people from registering, and it really isn’t necessary (although my preferred registration form is too simple for their needs). It sounded like Jeff just wanted a reason to play with OpenID. That’s fine, but make it a secondary option. The tiny handful of nerds with OpenIDs can use that, while the rest of the population can just type in an email address and password.

A few episodes back, Jeff mentioned that nearly every possible action on the site could be executed via GET calls to URLs. This is a massive violation of standard HTTP usage: all actions that change data, perform actions, or have permanent effects (basically, any writes) should be behind a POST request, not a GET. (Joel pointed this out in the podcast.) This created problems when the Google Web Accelerator was first released (remember that disaster?) because it automatically prefetched GET URLs in badly written software for actions like “delete post”. This is something that any decent web programmer knows, and something Jeff would know after even a few months of experience making web apps.

The insistence of using .NET technologies annoys me, but I know that’s mostly because it’s not my platform of choice, and they’ve chosen it because they’re both most familiar with it. This isn’t a fatal flaw, but it’s going to be a hindrance. The majority of consumer-facing web apps out there are written in PHP, and many new projects are started in Python and Ruby, because these languages (with their tools and communities) are simply easier and cheaper to develop, deploy, administer, and scale web apps with. There’s certainly value in using what you already know, especially if you already have a large codebase in it (like FogBugz).

But there comes a time when you need to realize that the platform you’re most comfortable with might not be the best solution for a new project of a different type. Even though the languages I know best are PHP and C, I know that if I wanted to write a Windows desktop app, it would be worth learning the C# language and the .NET library.

Jeff and Joel are both smart enough to know that a good developer can learn a new language’s syntax very quickly, and then it’s just a matter of becoming familiar with the libraries over time. (Two months ago, I didn’t know Objective-C or the Cocoa framework. Yesterday, I shipped my first iPhone application. And there are many developers better than me out there.)

Using MVC architecture is very smart. But from what some of Stack Overflow’s commenters have said, the ASP.NET MVC framework is very young. You really don’t want to use a very young framework. The predominant web platforms have far more mature libraries and MVC frameworks relevant to this sort of app.

Starting a new consumer web app in 2008 with .NET and MS SQL on Windows Server seems more like programmer laziness than an informed decision.

In Podcast 11, Jeff and Joel had a long discussion about storing and rendering Markdown-formatted input text from users. Jeff insisted on a few pretty horrible offenses including storing multiple formats of the data in the database, refusing to convert Markdown to HTML on page renders, and serving Markdown as plaintext and leaving its HTML conversion up to the Javascript (!) on the page.

Joel’s rebuttals were very good, but Jeff’s reaction when he’s wrong is always the same: the adult version of “I’m doing it my way and that’s that.” That’s a fatal character flaw to have in a project leader making technical and architectural decisions. That’s my main criticism. I’m sorry that it’s so personal, but I really can’t think of a way to candy-coat that one. The way to improve is the same way anyone improves their character flaws: admit their presence and actively push yourself away from that sort of thinking and behavior. Everyone needs to do this for something.

And finally, I have concerns about the scope of Stack Overflow’s community mechanics. The podcasts lead me to believe that this is combining many features of wikis, forums, Q&A sites, and social rating/aggregation systems (e.g. Digg). I don’t think Jeff or Joel fully appreciate the difficulty that they’re going to have — not just technically, but in social mechanics, rules, algorithms, and human moderation. They’re tackling some problems that nobody has solved particularly well before. This would be incredibly difficult even with the best, most experienced team working on it — which only magnifies the flaws of the current design process.

Furthermore, as far as I can tell, they’re trying to do all of this at once instead of a staged rollout with rapid iteration. They’re unnecessarily applying a desktop-software release method to a medium which doesn’t require (or appreciate) it.

That’s all I have for now. I hope this convinces you that:

Thanks for the mention on the podcast, Jeff. I’d gladly record this and send it in, but it would be longer than 90 seconds even if I had the Micro Machines guy read it.