:: metarz :: blog

37 Noise

Ideology and branding go hand in hand. They inhibit intellectual honesty.

During his celebrated startup school talk dhh said that the few examples of extremely successful VC funded companies are brought up over and over to brainwash. It played out even better since he went (right?) after Greg McAdoo who had the great analogy of the surfer on the big wave with and the slides to go with it. Dhh had a point, though. And a very good one at that.

Whenever I realize there is some brainwashing I look for the ulterior motive. In the case of the seed fund/VC crowd it is easy to see why they would want crops of entrepreneurs trying to make the next youtube: that's how they make money. That's the most likely ulterior motive -- welcome to sociology 101 ...

And, of course, there is nothing wrong with that. It just brings out the Dr. Skeptismo in me whenever I hear what they say. [1]

37 Signals is the underdog calling the brainwashing out. Cool!

Recently, however, the noise to signal ratio has been high.

Either they've turned stupid or there is an ulterior motive. I can argue why each of those posts is stupid, and so I thought it was that. But no. 37s is a brand. They sell basecamp and books. Their sales go down when less people subscribe to the "getting real" ideology. And out the window goes intellectual honesty.

And, of course, there is nothing wrong with that. It just brings out the Dr. Skeptismo in me whenever I hear what they say.

Oh and by the way: why kick the shit out of the old guys when the old guys want to pay you a lot of money for 2 years of work and the ability to make money with you? The first x million are not about mojitos. They are about the freedom from having to work to sustain yourself. Valuation is only one component of the vector; I'm not sure how many components the vector has, but certainly at least one more: the amount of cash you get. Investment is (hopefully educated) betting.

Everyone worth reading regularly should understand those things.

Running a startup is about tradeoffs and making decisions without enough information. The -- err ... A way of dealing with that is to leave all possible options open, exposing oneself to good risk and mitigating exposure to bad risk. Committing (ideologically or otherwise) yourself to do it without investment or to build a company that can only go VC -> acquisition is stupid. The only valid ideology for a startup is pragmatism.

Notes

[1] Yes. I take pg's essays with a grain of salt. You should, too.

posted by rz at 06:34 p.m. tags:

Undermining the Design Process: Thinking Outside the Black Box

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.

posted by rz at 02:57 p.m. tags: design, software, web

RTFM? FU!

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.

posted by rz at 12:47 p.m. tags: documentation, rtfm, software, stackoverflow

Why I Hate the Stack Overflow Podcast

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.

posted by rz at 03:35 p.m. tags: podcasts, web

Forget Silicon: How to Be Steel Valley -- Can Web Startups be a 'burgh Thing?

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.

posted by rz at 08:38 p.m. tags: economic development, pittsburgh, startups

Gradschool is no more

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.

posted by rz at 08:35 p.m. tags: grad school, life, startups

Web 2.1

Startuping has been on my mind a lot as of late and as a result there were over 600 unread items on my google reader. So, I finally sat down and started marking things as read without reading them, un-marking the ones that seemed more interesting, starring, reading the ones that were short enough to be quick, and that sort of a thing. Annoying. Why doesn't the reader do this for me? It should know by now what I like. It is a good friend of mine. I go see it every day. But wait, this is a meta-problem: why doesn't do this? It should know how I use it and organize my data accordingly.

The web 2.0 bubblevolution seems to be about two things: putting applications on the web so that they are accessible from anywhere and put users' data on the web and organize it in some naive way. Continuing with my reader example, this is exactly what it does: keeps me from having to download and install a news reader and it is available anywhere I go. Secondly, it organizes my feeds into categories of my choosing (I have to tell it which feed goes where when I subscribe to it) and it presents my data to me in some naive ways: organized by date and by feed or by date in the "river of news" format. The web 2.0 has been a good thing, but it seems that it is largely done. It is difficult to come up with truly new products that aren't just mashups of variations of existing ones.

Introducing web 2.1. The name of the game is not to figure which applications and data to move to the web, but rather to drastically improve the services that already exist. Come to think of it, that is what gmail did. When gmail launched in 2004 everyone, their mothers and grandmothers were using hotmail, yahoo mail and handful of other web-based email services. M$ had been the owner of hotmail for seven years! And in came gmail and taught everybody how email should be done: search, conversations by subject, lots of space, filters & tags and spam block. Bingo.

In a nutshell, dramatically improving a service means keeping more data about the user and the ways she uses the product, and do intelligent, non-evil things with it. Make smarter things, not new things. Automatic and dynamic customization. Oh yeah, and web 2.1 is never beta.

Most of what is in this post came from a conversation with Walter, but I had already posted in that style. Sorry dude.

posted by rz at 08:32 p.m. tags: startups, technology, web

(the) Need to Know

I'm not half as cool as to have Greek heroes and turtles, so I'll introduce Steve in their stead. He is a real person. He goes to graduate school with me. But, otherwise he is my diametrically opposite evil twin. We've had almost-heated arguments on things like public health care, US foreign policy, ethics, economics, and we always seem to take opposite sides. Maybe I exaggerate. Whatever.

Steve: May I ask you a philosophical question?

rz: Are you talking to me? Oh dear lord. Only as long as you promise me that I'll be done "answering" before tomorrow morning.

Steve: So I was tutoring this girl for one of her engineering classes, right? CS 111, I think. She was having problems implementing a list in C++ which grew in size if you stored beyond its capacity. And frankly, I wasn't really sure how to do it either because I always just use a vector and be done. Why do they teach stuff like that?

rz: Did that stop you from charging her? Wait. Don't answer that. Well, assuming you are asking me why isn't she learning more about practical, real-world, off the web-shelf, open-source library based programming, it probably has to do with the CS department's need to balance between teaching practical tools and teaching computer science in the "it is as much about computers as astronomy about telescopes" sense. It is a mighty difficult challenge because both tend to be called "computer science" for undergraduates, but both are fields in which you can do research in and they are quite separate from one another. In any event, it is probably good for her to understand how to build such a thing because a) you learn by examples and b) it is good to understand the most common tools to use them properly. By having her do it the teacher accomplishes a) and b) in one fell swoop.

Steve: Whatever. This girl is an industrial engineering major. She'll never have to program again in her life. Why should she have to deal with such mundane stuff as pointers and memory allocation to implement something that is in the standard library?

rz: First off, why is she even in the class if she is sure she won't ever need to program again? If it is required there probably is good reason for it. For example, if you are engineer you'll probably program at some point in your life. Secondly, she should learn in as much detail as possible. That's what we mean by "education". Maybe by doing that she will learn that she likes programming better than industrial engineering. Maybe to learn how to write elementary programs will save her a ton of time later in life. Maybe she should just do it for the joy of learning and broadening horizons. Which I thought was the other reason people came to college, by the way.

Steve: Whatever. I take a more practical approach: figure out what I need to know and move on.

rz: Uh... If you think like that why do you need to know anything? Why do you study physics? You could get by (and probably make a lot more money) without finding this higgs thingie you'll spend the better part of the next five years looking for. Of course, the only real proxy for what to learn in depth and what not is your interest, but for someone who is in the first couple of years of her education it seems important enough to try subjects even without having interest in them just for the sake of finding what she is actually interested in. Heck, exploring is probably good even for people at the stage we are at and even later on. I think a fundamental problem with the education system is that education is treated as if it was a mean to an end rather than a self-exploratory adventure of its own worth.

Steve: Pointers in C++ are not that deep.

rz: Sure, sure. I like practicality as much as the next guy. Well fine, maybe that's not true. Anyways... practicality has its place. I'm not suggesting that she goes to learn about functional programming when she has a multi-part project due in two days for the joy of exploring, but in general learning new things just to know them or just to try them is half the reason to go to college or pursue any type of education. Let me rephrase that. Learning new things for their own sake is one of the things we mean by education. Wait. One more time.

Learning new things for their own sake is one of the things we ought to mean by education.

posted by rz at 08:15 p.m. tags: college, education, life

NSF: National Software Foundation?

It is that time of year when google starts taking applications for GSoC. The Google Summer of Code is a neat idea, really: pay a bunch of students enough to live on for the summer in exchange for them contributing to open source software. While the aim is very different, GSoC remindes me of how REUs work. This got me thinking...

Consider how science and technology work. Some talented person(s) is passionate enough about his science to pursue it at great costs. I'd even venture that most of us would do it "for free" as long as we had some way to get by. Secondly, companies realize that advances in science can turn into profits and so they fund research. Finally, the government also appreciates -- well maybe not as much as it should -- the value that science holds for the general public and for the government itself and thus funds research through agencies. The role of the agencies is to determine what is the overall direction that science should be taking and to administer the funds. Researches write proposals and get grants. People go to work.

Open source software isn't much different. Some talented hacker(s) is passionate enough about her hacking to pursue it at great costs and in her spare time. I'd venture most hackers would do it "for free" as long as they had some way to get by. Companies realize the value of this and they fund open source development (GSoC, IBM and eclipse, MySQL, etc). Finally, the government -- oh no, wait, the government is largely missing from the picture.

If google finds it worthwhile to fund REUs, why is it that the government does not find it worthwhile to fund open source at a larger scale? The general public -- whether they realize it or not -- benefits from the existence of open source projects. The internet exists because of open source. Secondly, the government itself will sooner or later wake up and adopt open source technologies for its own needs like those of Germany, The Netherlands, and Brazil which have already begun doing this. The potential agency should work much the same way the NSF does: determine overall direction and administer funds. Hackers write proposals and get grants. People go to work. The agency does not even need to be separate from the NSF. It just seems that there needs to be a way to make a proposal to build something and get the government to finance your efforts so long they are for "the greater good". Just like science. Only that hackers, unlike most scientists, don't need any expensive equipment other than a laptop.

posted by rz at 08:25 p.m. tags: open source, politics

The Materials and Plan

Materials

These are the learning materials I have and will be using. Since I've been studying this stuff for a little bit I know a little about them. In no particular order:

Aitchison and Hey, Gauge Theories in Particle Physics

For some reason I was intimidated by the title, but this is an excellent book to get your feet wet with. Focuses on the conceptual parts more than the math and therefore it often leaves you hanging as far as believing what you are writing. I'd say start any topic here and don't get hang up on anything that is not clear or not mathematically solid. You'll then be in a good position to understand the more rigorous texts. Aitchison also mantains solutions and errata on his site.

Griffiths, Introduction to Elementary Particles

If only everyone would write like Griffiths! This is a bit superficial, but it is also a good way to get your feet wet. Since it is an undergrad book it is a good place if you don't want to deal with some of the math.

Peskin and Schroeder, An Introduction to Quantum Field Theory

The industry standard. The canonical. Not too friendly, but friendlier than others. You have to read this.

Srednicki, Quantum Field Theory a draft available online

Excellent book. I think this will become the canonical and industry standard. Very friendly and in full depth.

Maggiore, A Modern Introduction to Quantum Field Theory

Also excellent. Not too friendly and very economical. This one reads slow but whenever you find lack of rigor somewhere come here. Its approach is first all the prereqs then the qft. As opposed to most of the others which try to bring in the classical field theory and group theory as needed along the way. Has all the solutions to the problems. This is my favorite so far.

Zee, Quantum Field Theory in a Nutshell

It has been recommended to me by many. I briefly tried to read it during the summer and didn't get very far. It seems like an excellent book, but don't let the friendly tone lead you to think that it is an easy one.

Polchinski's course at UCSB, he follows Srednicki. Fall (no winter!) Srping.

Plan (canal? panama? am I man enough?)

As for the plan, it goes as follows.

Before you open any of the above (except the first two) make sure:

You know special relativity inside and out. I read and these more or less from cover to cover, did most of the problems and can vouch for them: Rindler, Introduction to Special Relativity and Woodhouse, Special Relativity. If you are feeling more remedial, read the relevant appendix in Aitchison & Hey and the chapter in Griffiths.
You are comfortable with complex functions and know contour integration. I read most of the first 7 chapters of Brown, Complex Variables and Applications. Also made sure to do a few problems along the way. It is now one of my favorite math books.
You understand Green's Functions. I was remedial about this and only read the appendix in Aitchison and Hey combined with whatever I know from other places (which is not much).
You are familiar with the very basics of groups and representations. Probably Cornwell 1,2 and 4 would be good, but I just picked this stuff up by osmosis during my math major days.

After the prereqs the first part of the roadmap is more or less as follows:

Griffiths Cp 2,3,6,(7). You can probably do this in one or two sittings. Pay attention to chapter 6 to make sure you can at least evaluate Feynman diagrams when thrown at you. Speaking of that, peak into chapter 7, at least the first few sections of it.
Srednicki 1 and 2 doing all the problems.
Aitchison and Hey 1 - 7 doing most of the problems in parallel with Zee I1-I7. Chapter 9 of Maggiore may come in handy here, too.
Peskin 2 doing all the problems
Maggiore (1), 2, 3.1, 3.2 and 3.3 doing all the relevant problems
Zee I8-I11
Peskin 3
Maggiore 3.4, 3.5, 3.6, 4 doing all problems
Peskin 4 doing all problems
Maggiore 5 and 6 doing all problems
Zee II

The hope is that this will prepare one to study QED in gory detail and full rigor.

I know I want to also incorporate Srednicki and Polchiski's class. I think I will do this in parallel with all of the above.

I anticipate that all of the above will be a solid 2 to 3 months of more than half-time studying. I mean 20 to 30 hours a week for 8 to 10 weeks.

At the time of writing I've only executed the prerequisites 1,2 and less than half of 3 above. Most likely this plan will get revised, I will post something more polished in retrospect at some point.

posted by rz at 09:27 p.m. tags: books, physics, qft, science