Subscribe to AMTTI!

• Recently Written

  • Memo #15 — Blodget says: Online Display Ads Will Fall Sharply In 2009. I say “Good”
  • Memo #14 – Get your war on is now animated
  • Memo #13 – I’m doing it wrong?
  • Memo #12 – Tackling the hard problems
  • Memo #11 – Why DPI makes me say WTF
  • Memo #10 – How not to design for security
  • Memo #9 – Launch early and launch often
  • Memo #8 – A quick note on website heatmaps

• Categories

  • Annoyances
  • Business
  • Internet
  • Internet Governance
  • Marketing
  • OPP
  • Personal
  • Startups
  • Uncategorized

• Archives

  • October 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008

• Blogroll

  • EveryDNS
  • OpenDNS

Henry Blodget things we’re fucked in his recent article: Let’s Be Serious: Online Display Ads Will Fall Sharply In 2009

I don’t think we’re so screwed.  I do think he’s right that display advertising will drop, but only for a while.

Chris Cummer, a guy with a blog that got linked in News.YC, thinks that he can tell when “You’re doing it wrong.“  Okay, I’ll bite.  If only because I worry that some of the smart-but-inexperienced YC folks might actually believe what he writes.

Not everything he says is wrong, but enough of it is. So without further ado:

He says that You’re doing it wrong if…

• You’re not building atop an open-source framework
• • Whatever, it’s okay not to use a framework. And if you don’t count Smarty as a framework, then you really don’t ever need a framework.
• You’re writing your own framework upon which to build
• • Agreed, that’s probably stupid.
• You’re not using an ORM layer
• • Wrong.  You do not need to use an ORM layer.  If anything, your life will be more painful later as you figure out that many of your bottlenecks are abstracted out of sight and are hard to uncover.
• You’re writing your own ORM layer
• • Agreed, but only because you don’t need an ORM layer.
• You believe you can write it faster or better or more efficiently than any available library
• • Chris has clearly never used a Ruby Gem or CPAN or PEAR. Much of it is slow, buggy garbage.
• You have more than one developer on your project and no written coding style guidelines
• • A style guideline won’t make up for crappy programmers.
• Your bug tracker serves as your functional scope or your development roadmap
• • A tool is just a tool. It’s how you use it that matters.
• You aren’t using source control
• • This is to vague to be useful.  There are also crummy forms of source control, sadly.
• You comment the what but not the why
• • If you have to comment the why, you are definitely doing it wrong.
• You tend to pass properties instead of instances to functions
• • Maybe in your language.
• Your “deployment procedure” involves any combination of FTP and/or drag n’ drop
• • Protocols are irrelevant, process is what matters.
• You write code in a manner that cannot be unit tested
• • If you rely on unit-testing, you are setting yourself up for a rude awakening.
• Your primary method of code reuse is copy/paste
• • If you spend half your time ensuring you DRY, you are wasting your time.
• You don’t read any development blogs focused on your primary and secondary languages or technologies
• • You are probably spending too much time reading blogs.
• You haven’t been to a conference or birds-of-a-feather meeting in the past year
• • Once you become the expert, the value of most conferences approaches zero, unless you use it as a recruiting tool.
• The only code you read at work is your own
• • Agreed.
• You worry that some day someone else will read your code and know it was written by you
• • This is not a problem.  Everyone has a coding style, it’s like a fingerprint.  Don’t try to avoid it.

I’m curious to see what you have to say. Agree with Chris? With me? Or maybe you disagree with both of us…

In a conversation with a friend yesterday, she made the generalization that the engineers at her small startup don’t seem obligated to tackle the hard or tedious problems even though they need to be tackled for company to succeed.

I’ve heard that claim before. In fact, I’ve heard both sides of it. I’ve heard engineers complain that the non-engineering side of the house isn’t doing anything to help the business and I’ve heard the non-engineering side complain that none of the engineers are doing anything to help the business. I’ve never seen a situation where either of those assertions was correct. I told my friend that whenever I’ve been confronted with this problem it has always been a symptom of a larger organizational problem relating to a lack of clear strategy and goals. I know this because I’ve been responsible for creating problems like this (and hopefully fixing them).

If you believe that people on your team generally want to do a good job and be successful then hearing people groan about other people not working is a good indicator that your team is unclear on the objectives or aren’t working on the right things. These are both management problems, neither of which is the fault of the employees.

Fixing these kinds of problems aren’t easy, but they are doable. I’ll see what I can write-up about this in a later memo. But for now, remember that if you hear people grumbling about other people not working, it’s probably a much more serious problem. Of course, if you do have people on your team who aren’t working out you’ve got to let them go as soon as possible. But that’s a problem every manager learns the hard way very early on.

Based on my own experiences, and what I see happening to some friends companies, I am now fully committed to the “launch early / launch often” strategy (at least w/ regards to Internet related ideas).

Here’s why:

1. When your only feedback loop is your board of directors and your employees you will never develop a product that your customer wants.  Nor will you ever feel ready to launch.
2. If there is a market need for your product, but your product doesn’t quite meet the market’s needs when you launch, you will get their faster by quickly iterating over customer feedback.
3. Related to #2, if you spend months or years developing a service, it’s easy to get lazy or burned out.  When your customers are demanding a better product, it’s puts the fire under your belly.  This may be one of the best reasons to launch early.
4. At any given time, someone else is building a product that will be better than your current one.  This is why you have to also launch often.
5. Revenue.  Regardless of how much money you have or how much you’ve raised, launching early gives you maximum run rate to start generating revenue.  And often times, launching will start to bring about buzz and inquiries about partnerships which may be revenue-producing.  You don’t know about those things until you launch.

37Signals is a company out of Chicago that has a popular blog where they encourage people to work less, grow slowly, etc, etc.  Except that they don’t do that at all.  They’ve raised money from Jeff Bezos, hired a team of “Internet All-Stars” and spend more time online than offline.  They aren’t really a startup in the classical sense, more like a lifestyle company who wants to be treated as a startup.

But a startup is about one thing — Big risk == Big reward. That’s why we are creating businesses.  That’s why we are changing industries.  That’s why we work our butts off.  If you don’t have health insurance (as they claim happens at a startup) you are working at the wrong company.  If you are destroying your family (as they claim happens at a startup) then you are working at the wrong company.

Bottom line:  37 Signals is full of baloney, spreading misinformation and I can only guess it’s to try and stem competition.  They don’t want to encourage innovation, they want you to stop innovating so they can take their time to innovate slowly. If you’ve ever used their apps, you know how weak-sauce they are.  So weak is their sauce that the first demo of Google App Engine was a quickly-made clone of their Campfire application.  37 Signals whined about and resulted in it being taken down.   What a bunch of jokers.

If the utility of your new startup is directly related to the number of users using the service, find a different hook to get people actively using it.  Unless you’re amazingly good at managing the customer lifecycle, I won’t come back after checking it out once and getting bored.  Find a way to for me to get value out of it as an individual first.