I've been accused of undermining the design process. And yes, I do. Here's why.

Reason 1: I operate in an environment where most of the design choices have been made for me already. They have been made in sensible ways -- probably better than if me and my team would go and make them.

In Code Complete, McConnell goes in great depth into how spending time up-front designing the architecture, the sub-systems, and the components of each sub-system of a software project pays off handsomely because it costs less to change a design or design document than to re-write a chunk (or all) of the project. Well duh.

If I were writing the avionics system for an A330 or the first version of an accounting software package for a large corporation I'd probably be inclined to have the whole thing fully specified before writing any code. The design process would be a very significant chunk of work. The team would likely be faced with a lot of choices for components, we'd have to make sure that all the components won't fail in some catastrophic way, we'd need to know what kinds of user interfaces to expect, etc, etc. And then yes, in that case McConnell is right and I agree with him fully and I'd be using the checklists and guidelines in Code Complete.

But I don't do that.

I write web applications. That severely restricts the problem space. Sure, I could be at the forefront paradigm-shifting and cutting the edge of web application technology (or what's worse I could've been writing web apps in the 90s). And then I'd be re-thinking the way we go about it. But I'm usually not. Most (all?) of the time it is a SQL db with urls, views and templates, and an admin interface on top. There may be some other data processing untied to the web-requests, but the ORMs work there, too. And then Django (or Rails, or webpy, or...) does the trick. End of story. The very-talented lot of Django developers have already made a lot of crucial design decisions for me. And it works.

As far as web applications go, right now we're late in the technology wave. Which, again as per Code Complete, reduces the amount of work that needs to go into design.

Writing mobile applications is equally constrained. And so is writing software on top of existing services (e.g. on top of the twitter or facebook APIs).

Reason 2: getting something coded up quickly may have costs later on when I have to re-write, but it also has benefits.

You can't get users on your design documents or your blackboard diagrams. But you can on a site with a poorly designed backend. Rewrite later. The users will provide a much better idea than the design documents about what the problems are.

An investor is probably more impressed by a live site that works and has users than by a very complete specification of the software you are going to write.

It is hard to talk to the client with "this will happen like that" statements. Much easier to say "take a look, is that close to correct? what needs to change?"

Of course, it is the nature of distributing software on the web that allows this. If I were shipping products shrink-wrapped this wouldn't be so. Like I said earlier, the fact that I write web applications takes care of a lot of the design process.

The best specification for the database schema is the app's models.py. You get a design document and a chunk of code written. Oh it is wrong? python manage.py reset_db (requires the django extensions :-).

I'm not advocating going from 0 to code here. No. Having a Jason Fried style functional spec is a bare necessity. But keep it minimal. Keep things as close to their final form as possible. Keep things real. Sorry for the bad reference. I just reminded myself of Pierre.

Reason 3: software is always written in a broader context.

People tend to talk or write about software design as if it happened inside a black box, for its own sake, without any other moving parts. And yes, if you are in charge of designing infrastructure for the next google data center maybe you get to operate that way. Best practices everywhere. You can take your time to plan. Groovy.

In more mundane cases everything is a tradeoff. Including time spent designing. Sure, now that you've designed your app properly it will be a breeze to scale it. But maybe you won't get to the point where you need to scale it because you spent too much time designing it.

I think this is the same reason DHH counts on Moore's law to keep him from sharding: lazy evaluation. The design process is a form of strict (anti-lazy) evaluation. It is trying to mitigate risks by virtue of foresight. I suck at foresight. So I'm fundamentally lazy.

I was trying to debug an apache configuration a couple of days ago. On some forum someone was asking what was the cause of a certain warning/error message and what to do to fix it. The first answer was (almost verbatim) "There is something wrong with your apache configuration. Go read the documentation." Gee, thanks. How useful. I feel so enlightened. I couldn't have figured that out on my own.

RTFM is a stupid answer to any question. If you think the question is not worth answering because it is in the documentation just move on with your life. The world is not a better place because you posted RTFM. Doing so strikes me as pathetically saying "Oh I read the book and I want credit for that. Please?" Take a literature class or something. You can get college credit for reading books that way.

On the other hand, I ask questions whenever I can instead of RTFM for the same reason stackoverflow is great: it saves time. Come to think of it, that's the same reason people W comments, documentation and TFM in the first place: all the information is contained in the code, but we need a more efficient way of navigating through it. It is not about all the information being somewhere. It is about being able to extract the relevant parts quickly. Having someone who has RTFM point you in the right direction is a lot more efficient than RTFM.

Or what I wish everyone who makes podcasts would keep in mind.

I really could do without Joel's "anecdotes" about bad service at hotels and Jeff's ill-conceived off-the-cuff off-subject remarks. Sometimes these things take up most of the hour! Perhaps I should just quit my whining and just unsubscribe. And I would. But then I wouldn't hate it -- I simply wouldn't care.

The reason I don't unsubscribe is that then I would miss out on the 20 or 30 minutes of priceless insight into software development that's in there. I find Joel and Jeff's discussions about software development not only worth their while but worth the while of all the other crap. This doesn't make me like the other crap -- I wish it wasn't there.

I don't know when the council of the tubes got together and decided that the length of a podcast should be an hour, but they were obviously smoking something. Podcasts should be either ~20 or less than 5 minutes. Here's why.

First and foremost it is hard to do pay attention to a podcast and do something else at the same time. Audio-only is not effective enough to warrant exclusive attention e.g. I couldn't teach you quantum mechanics exclusively via podcast. The result: podcasts are for the "down time". They are perfect while I workout, walk, cook, clean. Alright, let's not get crazy, I don't clean that often.

Second, I thought it was known that it is hard to retain someone's full attention for longer than 20 minutes.

Econtalk is wonderful. However, I find that it takes me quite a bit longer than an hour to listen to it and it even becomes a chore since I can seldom listen to the whole episode in one go. I have to context switch -- rewind.
Planet money, on the other hand: perfect.

Seth sez: your blog is not about you, it is about your readers. Corollary: your podcast is not about you, it is about your listeners. Cut the self-indulgent crap and only leave the parts that are could be worthwhile for your listeners. Be brief. Keep it simple, they are probably doing other stuff as they listen.

Note: this post appeared originally on the Sonya Labs blog.

--

Of all places, I never would've expected to build my startup in Pittsburgh. I moved to the 'burgh from Chicago when Sonya Labs got a seed-stage investment from AlphaLab. It is not so unfathomable that I'm here, though, it actually makes quite a bit of sense. Even Paul Graham, a Pittsburgh native, who is famous for advising that startups go to Boston or Sillicon Valley says so!

Pittsburgh has the opposite problem: plenty of nerds, but no rich people. The top US Computer Science departments are said to be MIT, Stanford, Berkeley, and Carnegie-Mellon. MIT yielded Route 128. Stanford and Berkeley yielded Silicon Valley. But Carnegie-Mellon? The record skips at that point. Lower down the list, the University of Washington yielded a high-tech community in Seattle, and the University of Texas at Austin yielded one in Austin. But what happened in Pittsburgh? And in Ithaca, home of Cornell, which is also high on the list?

...

Rich people don't want to live in Pittsburgh or Ithaca. So while there are plenty of hackers who could start startups, there's no one to invest in them.

Well, maybe Paul doesn't quite say so, but he does try to explain why there isn't a startup hub here. It simply makes sense for one of the top CS programs in the country to turn its home into one. His explanation is a bit flawed, though, no rich people in one of the steel capitals of the past century? Maybe there is no young money, but there has got to be money somewhere. Not only that, but Pittsburgh is close to all of that east coast money.

On the other hand, if all the hackers that study here are happy to leave and there is nothing to attract hackers to come, money doesn't count for much. Pittsburgh seems to have more of that problem than a lack of money.

The puzzle goes a bit deeper. For a web startup made of cheap servers, ramen and young people, the main expenses to get started are rent and food. Pittsburgh then, being a lot cheaper than Boston or the Valley, makes even more sense. Here our AlphaLab money will last us at least six months and possibly even eight, whereas it would only last three or four in the other places.

Of course, this puzzle is a lot more complex than solvable with a single answer, but if I was a CMU hacker working on something startup worthy, there are just about enough incentives to stay in Pittsburgh; and if I was a mere mortal hacker there even seem to be enough incentives to come here.

Mike Madison hits closer to what I think is one of the main problems:

This puts the lie, I think, to the most famous and durable of Pittsburgh stereotypes, that this town and region are noteworthy for their honesty and work ethic. If you have a job, that stereotype certainly seems to fit -- but a big part of that job seems to be keeping it intact, and keeping others at arms' length. Is there a "Not Welcome" sign posted in the region's employment markets? It sure seems that way.

I think that more than a "Not Welcome" sign, Pittsburgh has no sign at all. At least when it comes to startup founders. Since landing here, I've noticed the vibe of reinvention just about everywhere I've set foot. The city is and has been trying to renew itself into being a startup hub among other things.

Whereas I could always feel the academic attitude of Boston, the entrepreneurial one of the bay area and the alterno-hipster culture of Portland from afar, it was only after a few weeks here that I felt anything about Pittsburgh. I've been thinking about startups for the last three years and never once had Pittsburgh crossed my mind as a potential place, but places like Austin, Seattle, Chicago (before I moved there) and even Portland had. There isn't enough noise!

How to go about hanging the right sign at the door is also tricky business. The first part would be a bit of a media campaign in the adequate parts of the blogosphere. I mean nerds and hackers blogging to nerds and hackers about nerdiness, hackery, and Pittsburgh. A bit of a catch-22, if they aren't coming or staying here in the first place, though. Maybe we can help. We're nerdy looking and we mumble "linux", "open source" and "python" enough to pass for hackers.

Programs like AlphaLab are also a good start. If the program is successful in a couple of years there will be a solid network of alumni founders in the city which will make their noise and attract more people in turn. Even more important than helping founders start is helping people who are already here continue, though. Ahem.

Self interest aside, another important piece to attracting founders is getting VCs to invest smaller amounts in more companies. Convincing VCs to invest angel-like amounts and angels to behave like VCs will be part of the next wave of web startups wherever it happens. The trend about the costs of startups are clear by now, so I won't go into why most startups that are a few months old don't need several million, but only several hundred thousand to move forward. If you want to give us a few million at the right valuation we won't object, though.

Finally whatever "Not Welcome" sign needs to be done away with. Duh. There is no room for anti-immigration attitudes. Letting Mike make my point:

Moreover, there are sizable communities in the Pittsburgh region that see potential increases in immigration rates as undesirable -- either because immigration of lower-skilled workers threatens existing blue-collar employment and depresses wages, or because in-bound higher-skilled workers compete for positions with people who already live here, or both. Somewhere in Pittsburgh, someone is asking why Sycor wants to raise the H1-B visa cap rather than hire skilled people who already live in Pittsburgh.

...

The problem, in other words, is that immigration is perceived by many as a threat to the pie that we already have, rather than as part of a process of growing the pie.

That one is much more difficult so I'll let people like Mike work on that problem.

At least for a good while. I guess life is what happens to you while you make (or execute?) plans.

My spirits are similar to those experienced by fellow physics-grad-school-drop-out turned entrepreneur Andres from octopart when embarking in his new endeavor. Main difference is that I don't see my life as languishing in mediocrity because of being in grad school. In fact, I'm leaving with a heavy heart and a great deal of nostalgia to pursue what is obviously a better path for me for the immediate future.

I'll come back one day.