What To Fix

Buy a Jeep, Fund a Startup

2010-03-03T16:18:54Z

Everyone comes up with this cockapoo about startups. It's not about being smart. It's about being around long enough - Marty Pinchinson, co-founder of Sherwood Partners

Ever have one of those moments when you see some new product being advertised and think: Hey! They stole my idea!

Lots of folks think up stuff in a bar talking to a mate one night, only to have the idea float off. Not many actually get out and work on products. I've been lucky because my job -- technology strategy consulting -- has constantly let me look at big and small businesses and how they develop and deliver products to market. So I've seen lots of other people develop products, spend lots of money, and try to get traction. Sometimes these products looked useful. Many times they did not. Some made money. Others didn't.

Many, many times when I was in my 20s or 30s I would be approached by people who had a great idea and were looking to team up for a startup. Being a hotshot programmer and architect, I never took the bait. Why should I? Consulting rates were great, most startups fail, and if I could pick winning startup ideas I'd be playing the stock market and not slinging code and training project teams.

But then I started seeing people I knew retire on money they'd made on startups, and my opinion started changing.

I became a startup junkie.

That was about ten years ago, and since then I've had the feeling of "That's my idea!" only about half a dozen times, but each time they were products worth hundreds of millions or billions dollars -- and each time they were products that I spent real time and money developing only to run out of money before they really had a chance to take off. Hey, maybe I'm able to spot these things after all.

Buy my Jeep and let's find out.

]]> One time I had the idea of integrating my social network into my desktop file system through a universal address, capability, and messaging network. My friends would update their address and status in one place, and the directory would keep track of how I could contact them at any minute, what their status was, and what capabilities their current communication gear had. So all my friends would appear as little icons, and by right-clicking on them I could chat, send a file, play a game, or email. This was super-Facebook/LinkeId/Live/MySpace using your computer's OS capabilities instead of a web browser. And it was years before all that other stuff. I had a working prototype, and a 40-page(!) business plan. But I ran out of funding.

Then I had the idea of customizing web pages from a site other than the site they were hosted in. So a blogger could drop one line of JavaScript on his blog and then go to our site where he could add all sorts of things to his blog without having to know html. Stuff like voting, ranking, cross-blog chat, best-of-the-web articles, etc. It was a one-stop blogging toolkit. I had working code and was able to stay live for a couple of months, and had grown to 500 users before I had to choose between working full-time on it or going back to consulting. Out of money again.

There were a couple others, but the point is to show that I actually can spot and work on trends ahead of time -- and I have the technical chops to make stuff happen. No whining or complaining intended. Each one of these were great ways to learn things: things that you could read in a book but wouldn't really sink in until you do them yourself.

Most startups that could succeed fail because the founders don't devote their whole efforts to them. That certainly accords with what I see out in the world. Most startups fail because they don't make something people want, and the reason most don't is that they don't try hard enough. - Paul Graham

So now I'm looking at Facebook and Twitter and the rest, and I'm asking myself: what are people using these things for? What parts of social messaging are underserved?

And the answer is: quoting. Quoting, where you take a paragraph or two from a larger work and send it to your friends, is something everybody has done ever since email. Heck, long before that editors would take a line or two from a magazine article and make the font larger and stick it in a box. It was a quote -- a short piece of a longer work intended to draw the user into engaging.

I've been quoting stuff for decades. Looking at Twitter, something like 10% of tweets (rough guess, it's probably higher) involve people quoting other people -- only they are restricted to 140 characters and there's no easy way to have a conversation around them. Even Facebook friends are quoting news articles as a way to start a conversation -- but that conversation is usually lost in the noise that is FB.

What if you had a one-stop-shopping for quotes? While you're reading the web (or your Kindle), you find something provocative that you would like to share. So you "capture" the quote, tag it, and pick which social networks you would like to share it on. When people reply, their response goes to a threaded comment stream where everybody can come by and offer feedback to your quote. Your quotes stay in one spot forever, and you're keeping a library of stuff you found interesting -- and what your friends thought of it.

That's the plan, and I'm about 10 weeks in on development on the basic product, which is late-alpha/early-beta. We're starting to get real users and looking for our pivot -- the place where we realize gee, quotes won't work here, but a job search could use the same machine learning code and be leaps ahead of what else is out there. Or gee, quotes from the web aren't working because organic search is killing the market, but video quotes could be awesome.

But like Marty says at the beginning, the kicker is being able to stay around long enough to make it happen, and that means funding. So I've got a great deal for you guys out there who love Jeeps: buy my Jeep and you can help fund my startup. You get a terrific Jeep for a good price and the great feeling that you could help change the world. I get a few months of running money, and it's good for everybody. Heck, maybe there's a way to structure the deal so it's partly a tax write-off: I don't know. It's definitely going to be a great feeling enjoying the Jeep and also knowing that you've given somebody else a chance.

Business is all about friends helping each other out, each getting something and each giving something. I really love my Jeep. Aside from health and family, I can't imagine something that has more sentimental value to me. There are only so many of them left in the world -- this model had a very limited run. But this is cool for everybody. It is a great chance for me to share the Jeep with somebody else who can enjoy it, and at the same time gain some more runway for my startup.

If you're not interested but know somebody who might be, please pass this article along to them. Also there's a purposeful typo in the email address. You should be able to figure it out. Thanks!

Feb 2010 New F# Compiler Bugs

2010-02-26T13:21:27Z

I have been playing around with F# for over a year now, and I really love it. I *think* I have most of it mastered, except maybe active patterns and workflows -- but I'm getting close to groking those. Recursion still makes me scratch my head for a bit, but I can recurse with the best of them once I get going.

What sucks is running into bugs -- not mine, but the compiler's. Here are two I ran into last week that's caused a lot of pain (and information about a possible third one)

]]> The app I'm working on has a couple of really large record types. The reason I would want to have a record with a huge number of fields is to pre-calculate and keep track of a Cartesian product of two other records. It's not something I wanted to rebuild every time I needed it.

What I found was that creating and manipulating large types in F# causes the F# compiler to crash. Once you get past 300 fields or so, somehow the stack has a tendency to overflow, no matter what you set the stack size to be.

At first I thought this was a property of having modules that were too big, but that wasn't it. Then I thought it might be that some of my code has long pattern matching in it.

I emailed Microsoft tech support for F# and within minutes I was in a conversation with an engineer. He thought it was the huge matching structures too -- turns out this is a known bug -- but that wasn't it. After scripting around a bit, he also determined that huge record types just aren't happening yet in F#. The workaround is to break your types up into two pieces. Ouch.

At the same time, I also noted that computing field values when you are creating the type has a tendency to make the compiler barf when you use really long types. So, for instance, if you have a type with 200 fields and each field is being created by some bit of code (instead of a simple assignment)? That's going to hose up the compiler as well. (I am not sure of the exact number of fields or what with this -- if you get this, you'll know it) The workaround here is to pre-compute the RHS of your field assignments before you create the type, then just refer to your precomputed types.

What hurts the most? The app was working and compiling fine in 2010 beta but is just a dead hunk of bits in 2010RC.

Answering PG'S Arc Challenge: On the Road to a DSL

2010-02-19T12:06:06Z

I'm building a new startup -- it allows people to collect and share quotes from books and web articles. As you add each quote, you tag it. When people vote up or down your quote (or comment on it), the system trains itself to learn which tags each user likes. I may like quotes from American History. You may never want to see any quotes about politics. Over time, the system learns this and acts accordingly. That way you can have a broad range of subjects with a large user base and the app still has the feel of a private forum.

A while back, Paul Graham wrote a language called Arc. After he wrote it, he challenged other languages to create a simple set of web pages in as few tokens as possible. In Paul's philosophy, the fewer tokens a language has (or needs) the more robust it is. Therefore the more likely it is to last a hundred years

I've been thinking about Paul's assertion for over a year now. I've programmed in lots of languages -- to me they're just tools. Old friends. I can't say I am crazy about one language or another, no matter how many tokens it has.

As I and others pointed out, you can make a computer language do almost anything in as few tokens as you like as long as you've set up a DSL (Domain-Specific Language) for the problem domain.

Since I'm building my product almost from scratch, I thought I would take you through a quick tour of how you end up with powerful "languages" that have maximum expressiveness and minimum tokens, no matter what tools you are using. For this discussion, we'll stick to a (mostly) .NET stack, with some major modifications, but the stack is really not important.

]]> First let's start with a design goal: I want to consume the fewest amount of processor cycles possible for a read as opposed to an insert or update. The ratio of casual readers to interactive ones is pretty high -- no point in wasting lots of CPU time displaying the same static page over and over again. So let's use regular html files to represent the state of the system for the casual user. Everything will have an URL, and the URL will simply be an html file. You want to see quote number 7 and the comments? Go to Quote7.htm. This allows us to use a CDN (Content Delivery Network) at some future point if scalability becomes an issue. It allows the site to work for non-javascript browsers. And it's more Google-friendly.

Second, I also want the displays customized for the registered user and updating immediately as new information comes in. This means we'll need to get data from the server back to the html file. I'll use JSONP for that. It's lightweight and easy-to-use. Delivering the JSONP to the html file will be a .NET aspx page. The ASP.NET part of this really matters the least: it's just serving up javascript. We could do the same with CGI on any platform. ASP.NET is just a handy tool.

Third, I want to use a functional programming language. You don't really learn something well until you build something with it, and this looks like a great project for F#.

Now let's get started. Here's basically how it went.

Create some mock-up screens: At this early point the UI sucks, but that's not the point. Let's sketch out some screens, then kick out some basic html, to see what we want the site to do. As a default, let's make Phase 1 functionality a lot like a standard forum, say Reddit or HackerNews. Send it out to some sample users and tweak. After these first non-functional mock-ups, the rest of the mock-ups will be working models

Create a persistence layer (Design): At first I thought I'd just keep everything in memory, maybe flushing the data out to a flat file. As I thought about it some more, however, I realized that something a little more structured has it's benefits, especially in sharding and replication. So I decided to go wtih SQL Server. I sketched out a rough data model (took about an hour), created the DDL. and wrote some sample code to update and retrieve one of the tables.

Create a persistence strategy (Generalize the DAL): Since reads are much more common than writes, and since I own the whole box, I'll just cache up everything in memory and pull from there. Every so often -- say once a minute -- I'll refresh the cache. Since the cache is always being updated on writes too, the information is always live, just the database isn't getting thrashed for a bunch of reads of the same data in different combinations. The database, in fact, is just a set-based persistence store, not a huge player in the system. This means that by rewriting the DAL I can target other persistence stores somewhat easily. F# is very close to OCAML. So without too much effort I should be able to switch to a linux environment, if necessary.

Template the DAL: This is what separates the pros from the punks. As my understanding of the problem domain increases, the data structures needed to solve the problem evolve. I want to make that evolution as painless as possible. Write up a script to take the Data Model, create a database, create a DAL in F#, and enforce the persistence strategy. This takes about 100 lines of code in CodeSmith, but represents all kinds of computational whatnot and eliminates huge swaths of typos and inconsistencies. As the data model changes, push the button and have the underlying library update itself. This reduces errors greatly and simplifies the underlying complexity

Create the client-server interfaces (Design): Take a few pages and send and receive data. I have some old JSONP code lying around from a previous startup, so this was easy to do

Generalize the client-server interfaces: As I do more pages, come up with a standard format for calls, how to handle long-format data, user errors, and data formats. This is also easy to do when you use functionality to drive out structure and keep on the lookout for re-factoring opportunities

Template the client-server interfaces: Create a general way of updating the screen that uses templates and tokens. This means less code and more power -- easy changes to the UI.

Template the html files themselves: Create a template for, say, the user's home page. Then when the user's information changes, run the template and update the page. This also allows easy RSS feeds -- an RSS feed is just another version of a template

So now we have a templated way of changing the data -- simply change some tokens in the UML model (or DDL), push a button, and the data structure is changed. We have a templated way of updating the live data on the page: simply write a template for the type of data to retrieve, then run the template through the javascipt engine. We even have a templated way to create pages: Create a page template and have the server update the template whenever the associated information changes.

This puts a lot of power and flexibility in the hands of the developer, but there's one final step: generalizing the tokens and writing the lexer/parser. This takes all of those generics we've been playing around with and creates a new language, a Domain-Specific Language, which addresses the problem of creating static web pages and updating them with dynamic data from the server.

This means creating a set of tokens on the server to represent common nouns and verbs. Stuff like top_user_list_by_karma, sort_by_age, or latest_quotes.

With such a DSL, you'd simply write something like "Update_Page (foo_Template) bind to User and Quote with latest_quotes and _current_user" which gets you a robust page with all kinds of controls and displays based on the current user and the latest quotes on the system -- all with dynamically-updatable data. The only piece that is missing from this code is the page template itself (foo) which can be a bastardized html with some custom attributes.

I remember reading "Founders at Work" where Paul was discussing being able to change ViaWeb almost instantaneously while customers were on the phone with complaints/feature requests. Having a DSL allows you do to this without having to recode or even program. This is where all this generalizing and such takes you -- to a place where your business can pivot easily to find and address new business opportunities as you see them, instead of being trapped inside a programming paradigm that makes even simple changes painful.

But here's the kicker: even though I used a functional language for this, all languages will evolve to this same spot given enough attention to the problem domain and how you're going to solve it. The pattern is even the same: Design, Generalize, Template, Tokenize. And no, this isn't some kind of crazy architect astronaut adventure on my part. I didn't spend a huge amount of time to reach this spot -- maybe six weeks? And I'm just a sole developer.

Once I'm done, all of that work becomes a language of it's own: a language with the fewest number of tokens required to fix people's problems. I know this because I'm not developing any tokens that aren't being used in the solution, and I'm constantly on the lookout for genericizing tokens. Since I'm not touching the code anymore, it's part of my "standard library" of tools to use. I can share this with other developers and, without programming, they can fix similar problems with minimum tokens and maximum expressiveness too.

Paul has included similar web functionality in Arc because he felt building web pages are a hugely important part of a library. He asks if other languages also have the same priorities.

They may not. Instead of easy-to-create web pages, many of them have easy-to-create generics, or easy-to-create scalability patterns, or sorting, or file translating, or peer-to-peer access, or myriad other things.

To me, however, the question isn't which DSL/library is included in a language, it's how easy it is to create your own DSL in that language. It's here where I think functional languages do much better job than OOP languages. For instance, F# comes with it's own lexer and parser, whereas with most OOP languages you'd have to pull something off the shelf. Also functions as first-class citizens bend themselves much easier to tokenization than objects do.

But at the end of the day, no matter where you start, you end up in the same spot.

So what your language can do easily, to me, isn't much of a useful question. More useful would be "what libraries can you easily access and how easy is it to create your own DSL for your own designs?" That's where the real difference is made.

Daniel (and sock-monkey) are current applicants for Y Combinator and are looking for Angels to join them in their venture E-mail them if you are interested in starting a conversation about this.

The Outsider

2010-02-10T16:15:58Z

I was reading John Graham-Cumming today -- he makes the case that amateurs have a long tradition of helping scientists. He uses several examples, including his own discovery of a data error in some climate data -- an error that was promptly acknowledge and fixed by the scientists involved.

Others have made the case that as science gets more and more complex, the amateur really has little to offer professional scientists. There's simply too much complexity nowadays.

I don't buy that, and here's why:

]]> As a solution developer and management consultant, I've worked with teams all over the spectrum of human endeavor. Programmers especially have to learn a new discipline every time they step into a contract and begin delivering a solution.

Many, many times -- too many to count -- I've seen ignorant amateur outsiders lead a group of people to a breakthrough in one area or another. Previously irreconcilable issues become easy to handle. Problems that seemed insurmountable suddenly become trivial.

As a coach and trainer, I see this even inside of delivery teams themselves. Teams careen off the rails and nobody knows why, yet everybody is very intelligent and acting in the best manner possible. Deadlines are missed even though heroic efforts are being made. Then suddenly an outsider comes in, asks the team to explain how things work, and everything gets better.

Why is that?

First there's the issue of simultaneous cognition. The human brain can only hold about 4 or 5 orders of complexity in it's head at the same time -- and that's genius level. And it's not a issue of knowledge, it's an issue of span of control. Although I may understand how electricity works, how a network card works, how a computer works, how the internet works, and how web pages work, I do not keep all of that in my head while I'm making a new web page. Instead I just work at the higher abstraction level, leaving the rest of it to "just work".

This means that to work at a really high level -- say cutting-edge science -- you have to work on lots of assumptions about what's true most of the time. Most of the time, of course, you don't have to worry about these things. But every now and then there's some coupling between a low-level detail and a high-level one and it's completely off your radar. A fresh face, which has to understand even the basics before they can get the advanced stuff, is the prompt needed to remember and apply the coupling.

Then there's a close relative, hidden assumptions. Technology teams are really good at this but it infects any group of specialists. A new effort begins, people begin to assume roles and help each other out using patterns from previous experiences. Quickly a lot of "rules" are made even though they may never be expressed: Joe is going to do builds, Sue is the person for user-interface design, we only make database changes on Tuesdays. These hidden rules can quickly get very complex and begin to hurt team performance. If you're doing it the wrong way, no matter how hard you try you're not going to suddenly do it the right way. It's just going to hurt more.

The outsider here simply asks why folks believe the things they believe. Why is Sue the person for UI work? Doesn't anybody else know how interface design. Sue speaks up and says she's actually an expert on database design. Suddenly we realize the team is out of whack. One of my favorite recurring examples of this is the team that does all the easy work first -- after all, it's important to get momentum! They quickly find themselves in sprint 7 with really tough problems and lots of refactoring to do. The unwritten rule was the team was so poor that they needed encouragement more than they needed to accomplish things.

Outsiders, amateurs, and ignorant people are extremely important in any kind of technical endeavor because they force us to unmask and deal with hidden assumptions. The more technical, the higher the level of abstraction, the closer and smaller the group involved, the more outsiders are needed. Companies that employ true consultants (and not just consultants as staff augmentation) understand this: they bring in people who are great facilitators, great designers, great people at handling and organizing complex systems, but mostly great people at asking stupid questions. Because it's the stupid questions that trip up the smartest of us.

Craigslist Spambot Attack

2010-01-26T15:25:33Z

A few weeks ago I put up my Jeep for sale on Craigslist.

Almost immediately I became a robot-magnet.

Robots were emailing me to tell me that I asked too little for my Jeep -- if only I clicked this link I could see how much it was really worth.

Robots were emailing me to tell me that there was another vehicle just like mine that was priced lower -- if only I clicked this link.

Geesh.

]]> Yesterday I renewed the ad with a lower price on it and within 5 minutes I got a new email.

"Hey man, do you still have that Jeep for sale?"

I emailed back "yes"

"I think you could get a much better price. Checkout this link"

Spambot.

A couple of hours later, the romantic spambots arrived.

Hows it going? nmy name happens to be Cristy

I looked at your post (rare jeep scrambler - $7000 (bedford)) on craglist and I'm located in roanoke too! I Wonder if its possible you are
on the dot the form of man I am have strong feelings for.

I 24 years old, clearly out ncomputer science school and not nattracted in anything nfast, just a nplayful friend ;).

You can catch my information and a ton of pictures on this date site I'm part of.
Few of them will show up some personal parts :-).

Somebody needs to set up a spambot dating site so all these robots can get together and sell each other stuff.

Finally this morning was yet another one

Hi,

Thanks for choosing our craigslist phone marketing program. In the next 2 days you will start getting telemarketing calls from our affiliates with some limited offers!

Maximum number of calls on a daily basis as opted by you :: 39

Preferable time opted by the applicant to get telemarketing calls: 12:15 AM - 5:45 AM roanoke

If you would like to unsubscribe from our list, click here.

You gotta give the last guy credit -- when I see I'm going to get 39 calls a day from somebody, you immediately have my attention!

Sadly, this is crippling Craigslist.I know guys who used to market using CL -- they were making good money everyday. But those days are over as now the goldrush has begun. Everybody and their brother are writing little bots to go out and try to sucker people into clicking a link.

Sigh.

The Existential Jesus

2010-01-18T22:18:05Z

What was the first-written book of the New Testament?

If you answered "Matthew", you might want to read up a bit on what scholars currently know about the bible.

Most scholars believe First Thessalonians was the first book in the New Testament written. What about the Gospels? Is Matthew the first Gospel written? Wrong again. The first gospel written is widely believed to be Mark. Mark -- without the extra verses tacked on at the end -- is considered one of the best sources we have of what early Christians had for a bible.

]]> Why didn't they just use a regular bible? Well because people didn't have bibles until almost 300 years after Jesus lived. Up until that point all that people had were letters that they shared and read.

So what was it like to live just a few years after Jesus was on Earth? You had the book of Mark written in Greek and perhaps bits of the other gospels. Probably lots of letters that aren't in the modern bible, like the Book of Thomas. Churches were informal groups of people without any of the church offices we have today. Some, maybe most churches hung on to Jewish tradition. One of the first things people had to figure out was: given this story of Jesus, what did it all add up to?

John Carroll, an unbeliever but expert in Greek, takes on the story of Jesus from this early perspective in The Existential Jesus

Going back far enough, you lose a lot of the current religious dogma surrounding the gospels -- for instance, the trinity was debated hundreds of years later. In Mark's Jesus there is no immaculate conception at the beginning, and there is no Christ ascending into heaven in the end. These things came in later books (sometimes decades later)

Instead you find a mystery. A mystery so deep that people have been striving for centuries to understand and expound on it.

I found this book to be very compelling and illuminating. Even for atheists, it's obvious that something very interesting and important to humanity happened in Judea in the early first century. I, for one, think that my atheist friends can admit that there probably was a person who filled the role of historical Jesus. Given that presumption, a logical question is what information early adherents had -- why was Jesus' story any different from any of the other apocalyptic preachers of that age?

For those friends, and for my Christian friends who are able to put aside dogma and strict rules of what to believe and not believe, I challenge them to read this book. In the end, I found a powerful story about existence, being, and purpose. Highly recommended.

Extreme Pair Programming

2010-01-08T00:13:40Z

People often ask me if I eat my own cooking. I thought this picture should prove that once and for all.

First, from the size of me you can obviously tell I've been eating somebody's cooking. Secondly, as you can see, pair programming is alive and well here. My partner and I work long hours making sure the code is exactly right.

I don't want to get into any kind of personality dispute, but my partner has a tendency to lose interest and fall on the floor quite a bit. He's obviously the brains of the operation -- the strong silent type. I figure after all these years of being both a high-level consultant and a code monkey, it was time to join forces with my logical ally, sock monkey.

And you can't beat the swank evening work area we have -- couch, TV, music, munchies, and pillows. Sock monkey doesn't talk a lot, but I can tell from the way he looks that he is really liking our coding crib.

You will fail

2010-01-02T20:03:46Z

I was talking to my good friend Jacques the other day and he asked a set of penetrating questions which all boiled down to -- do your realize that you're probably going to fail? Jacques and I have been studying and reading about startups for a long time and (I think) are getting pretty good at separating the BS from the real. Plus he's been helping me with my current effort, so he has a pretty good idea of what I'm up to.

So for all those entrepreneurs out there who are reading the self-help startup books and are excited about your new application, it's wake-up time.

You will fail.

I thought somebody should tell you that, because we don't talk about it enough. Odds are, you will fail. That's doesn't mean there's anything wrong with your team, your idea, your market, or any of that. Stats show that most teams -- even teams that are rated highly in all success criteria -- do not meet the expectations of founders and investors. In fact, most kind of fizzle out after a while. This is not my opinion, it's just stats.

This is why investing in startups looks so comically tragic from the outside: nobody really knows what will work or not, so at the end of the day it's intuition and gut feelings. Of course it's funny: at an early stage investors are writing checks for real money based on less information than the average horse better has. They just try to dress it up more.

But whatever you do, however, keep trying! The world needs you. Entrepreneurs in startups are going to change the future of mankind, and they're going to do it over the next decade or two. At this time in our history, being an inventor and innovator is the highest calling anybody can have in life.

Just be honest with yourself about the odds. And when you do fail, whatever you do, don't go on the internet and write a long tirade about how everybody else is to blame. Sure, it will feel that way. Worse than people not giving you an honest shot (which sucks if you are used to being a hyper-achiever) is watching other folks take your ideas and get funding and run with them. That kind of pain can last a long time, I know.

The best way to look at it? It's a numbers game, just like sales. Books and positive reinforcement and all of that exist to keep you motivated and playing the numbers. So try to fail quickly. Try to pivot from your original idea to something else. If you can fail at 40 different startup ideas in your life, you're going to kick-ass at one of them. Learn to laugh at yourself and others -- all while you're working as hard and as smart as you can.

Just thought I'd say that. I think a lot of times it's easy to lose track of reality in this business.

As for me and my startup? I'm going to keep plugging away. I'm in startups because I want to make the world a better place, I want to help people, and I want to create, not just consume. When I die I don't won't to look back on all the times I quit, I want to look back on all the times I tried. Sure, quitting is logical at some point. But lots of times I've quit before I even really gave things a chance, and I don't want to do that any more. I try because trying is good, noble, and honest. I'd trade a life full of trying as hard as I could any day for a life where I tried half-assed and hit it big on startup #1 and then never created another good thing for mankind. In fact, most guys I've seen that sold out successfully on a startup lost track of who they were, drifting from one half-assed investment to another, never able to devote themselves to any one thing again. After all, why pour yourself into anything? You might fail!

But I'm no fool, either. Life (and the market) is not a meritocracy, and simply because I work hard and am a good person doesn't mean that anything good is going to happen. I'm not doing a startup to cash out in five years. I'm doing a startup because that's who I am. You try hard, life kicks you in the ass, you learn more, and then you try hard again.

Just try not to do things you'll regret while doing it.

We must imagine Sisyphus as happy.

Logic Lunch Counter

2009-12-27T15:39:42Z

This post goes out to all of you logic junkies.

You know who you are: you're the ones with the list of fallacious argument types on a little index card beside your monitor. Heck, you might even have a web site dedicated to "clear thinking" or something like that. You're the people who make the first post under an article and allege "Ad Homimem!" or "Appeal to Authority" and then spend the rest of the day having people call you names.

It's gotten so prevalent that sometimes when I'm on a busy internet site I feel like I'm at a lunch counter where people are yelling out orders: "#15: Gambler's Fallacy!" or "#7: Red Herring!" or "#23: Affirming the Consequent!"

Boy do I feel your pain.

]]> I also am a logic junkie. As a programmer and somebody who is good at math and analysis, I see these fallacies, like the "No True Scottsman" one, used all the time on the internet.

But I have something to tell you.

Most of the time you have no idea what you are doing. Please stop.

Let me explain.

Your first mistake is viewing the English language as some sort of system of formal logic. "If p then q" does not match very well, or at all, to the nuances, slipperiness, and complexities of modern languages. Spoken languages are not formal, complete, or deductive in nature. Many times we yearn for statements like "All men are mortal. Socrates is a man. Therefore Socrates is a mortal"

Or to quote from the site I linked (which was picked at random):

Inductive arguments needn't be as rigorous as deductive arguments in order to be good arguments. Good inductive arguments lend support to their conclusions, but even if their premises are true then that doesn't establish with 100% certainty that their conclusions are true. Even a good inductive argument with true premises might have a false conclusion; that the argument is a good one and that its premises are true only establishes that its conclusion is probably true. [I disagree about the use of the word "probably" here, as I point out in the rest of this piece]

All inductive arguments, even good ones, are therefore deductively invalid, and so "fallacious" in the strictest sense. The premises of an inductive argument do not, and are not intended to, entail the truth of the argument's conclusion, and so even the best inductive argument falls short of deductive validity.

So you really can't "prove" anything in a conversation the same way you can prove, say, that the the relationship between a hypotenuse and the two sides of a right triangle is a^2 = b^2 + c^2. Natural language discussions are inherently about persuasion, not proof. This means when you're reading a text you're weighing various rhetorical devices, including logical fallacies, to come up with a reasoned opinion. You are not conducting a proof.

Does this mean that logical fallacies are pointless? Far from it! What it means is that every form of communication is going to be chock-full of these fallacies. Natural conversation by good, intelligent, open-minded, reasonable, and polite people has all kinds of logical fallacies peppered throughout.

I was reading an article the other day espousing an opinion I support. In it, the author made resonable claims and advanced a thesis by use of example, deduction, induction, and observation in a spirit of what seemed to be even-handedness. In the middle of it, however, he said something which basically boiled down to "and the people that support my opponents are idiots"

Almost immediately the logic mavens popped out of the woodwork, pointing out that this was an egregious Ad Hominem attack on his opponent.

That's all fine and dandy, except it wasn't. It was an attempt to impeach supporters of his opponent. It might have been an attempt to assassinate the character of his opponent by association (which is a subtle form of Ad Hominem), but it was definitely not a direct attack on the ability of his opponent to speak.

Steve Forbes posted a piece on net neutrality a while back. Steve propped up Google and Congress as his opponents, and then proceeded to explain why they were all corrupt, out to make as much money as they can, and stifle innovation.

Almost immediately folks started crying "Straw Man! Forbes is making a Straw Man argument!"

That's all fine and dandy except for this: when you're writing an essay and want to include the views of people you disagree with, you have to make some sort of assumptions that don't work about the motivations of your opponents. I remember reading Paul Graham talk about OOP programmers as something like "they're the type of people who like wiring little pieces together. That's fine if you're that type of person". I immediately thought damn Paul! Straw Man much? But he was honestly just trying to point out the views of people that had different opinions than him.That's how essays work. Good authors quote their opponents, at length, or say they don't know for sure. Bad ones make sweeping statements (as Forbes did in this piece, which I found atrocious for a man of Forbes' background) or dress up their opponents in garb that even their mothers would find offensive.

That's the way these things work: persuasion is full of varying degrees of fallacies strung together. Good persuaders lull you into a kind of trance where they can slide by all sorts of zingers. Bad ones just punch you in the nose with them. If you agree with me I can sneak in more zingers without your noticing. If you don't agree with me (and are logically inclined) you're going to spot each and every slip no matter how minor or related to the larger argument I'm making. All articles are guilty of bad reasoning -- that's the way it's supposed to work!

The way I use these lists of fallacious argument types is really as more of a commentary on the style of a piece, not the quality of the overall public discussion one way or another. If I say "That's obviously just an Ad Hominem attack" what I mean is "This author is so bad that they're just pulling out easy rhetorical tricks instead of actually doing any work to make a case" And I've read some awful tripe on the net. I've read 500-word articles that were just long streams of how stupid, bad, corrupt, ugly, dumb, fat, etc the other people are and aren't we so glad we're not them.

So for all you guys who have taken a logic or debating course or found the websites and essays that tell you about logical fallacies? Congratulations! You're beginning to learn how to think critically. Now get over the pointless and self-serving labeling already and move to the next step where we can all engage material critically from multiple points of view to see if there's anything of value in there for all of us.

Agile Startup Tricks

2009-12-16T15:53:47Z

I've been busy working on my startup for the last month, and as an agile-big-corp guy, many of you are probably wondering: how am I doing in the micro-team startup field?

Very well, actually.

Here's a brain dump of things I've learned over the last month. As always, take what you can use and leave the rest:

]]>

FlipCam standups - Like team members everywhere, I need somebody to report to, to make commitments to. I've found the best way of doing that is taking out my FlipCam each day and doing a "daily stand-up", 2 or 3 minutes where I explain what I did the day before, what I plan on doing today, and what kinds of obstacles I might have. This sounds so completely stupid that I'm amazed at how well it works. Every day I know I have to "report in" at some point, and it helps keep me on-track and motivated.

Find advisers - I'm very lucky in that I have about a dozen advisers, many from HackerNews, a place known for startups. These guys don't participate at all in day-to-day work, but every week or so I send out and email with status, demos, and asking for advice. It's a great feeling to have such expertise in my back pocket! And all I had to do to get them was just ask. Once again, the things that sound completely simple and totally obvious many times are the most profound.

I don't think it matters who your advisers are. Obviously people who do something like you want to do are great, but the point is having outside eyes look at your work. Quite a few times my weekly updates have kicked off discussions about how my project and product looks to somebody not programming it every day. You can't pay enough for that kind of good feedback.

You gain attention span by practice - The hardest thing I found when moving from Agile Coach at BigCorp to agile startup team at me.com was being able to focus. Even though I have a deep technical background, I find working with people intensely leads to "interrupt-driven-attention-span", where you're always hopping from one thing to another. This way of thinking becomes so ingrained that eventually you start interrupting yourself, moving from one trinket of activity to another. At first I had a very difficult time settling down and fully engaging mentally in a problem.

Oddly, it's not always an attention problem. The second half of this was being able to realize when my brain is stuck. Immature programmers usually just bulldoze through their code when confronted with these feelings. I've learned that when this happens I've learned to......

Get out - I make it a point each week to get out of the office for a lunch or two. This probably sounds strange to those of you in the city, but in rural areas it's possible to literally lock yourself up for weeks on end. And as fun as that sounds, at some point your brain needs time to digest what you're doing. What better way of doing that then having lunch with somebody? You get to make smalltalk, see the sunshine, and get immersed in interesting stories. Plus, as I said earlier, any outside eyes are a good thing.

Google Wave collaboration - I've been trying Google Wave as a form of collaboration. So far, results are mixed. Perhaps Wave just hasn't penetrated deeply into my circle yet. But it looks like an awesome collaboration tool, and I'm going to give it a year or so before I make a judgment one way or the other. For now, I think it's highly flexible and open to add-ons. Can't wait to see how it evolves.

Weekly drops - Each week I have something to show. My product does something of value it did not do the week before. Oddly, sometimes it does something completely different than I had planned, but it always does something new. Progress is always being visibly made. Not only does that give you a good feeling, it also gives you a sense of momentum. You begin to realize that no matter how big the problem, it's really only a matter of stringing together enough weeks with positive results.

Sharpen the saw - This past week I was feeling overwhelmed by cruft -- you know, the stuff that builds up in your code as you work towards a drop. So I decided to do something very anti-agile: I took the week and just worked on finding how cruft was getting in my code and eliminating it. As a result, I made more progress this week than in the two weeks prior! No matter how hard you work on sawing the tree, you get much more done not by sweat, but by sharpening the saw and letting it do the work.

Auto Code-Gen is good, up to a point - As part of my "sharpen the saw" week,. I pulled out my old standby code generator, CodeSmith. CodeSmith is the crack cocaine of architect astronauts. Once you start doing code generation, you can fall into this world where you spend more time on the code generator than the actual problem! It's a very bad place to find yourself, and it's all too common for architecture-minded coders. But, on the other hand, code generation also serves a very good purpose sometimes. I am working on the Microsoft stack, so there's a bunch of junk involved with getting things out of persistent storage and putting them back in there. This is the perfect thing for CodeGeneration, because all it's doing is being a code-writing monkey so you don't have to be.

At the end of the week I have a project that generates about a five-hundred lines of F# to manage persisting data. Not only is this mindless code, it's also code where people have a tendency to make lots of mistakes. Plus when I change my data structures all I do is push a button and continue working on the larger problem. So auto-generation is all good -- up to a point.

Keep an open mind - I think probably the toughest thing I'm learning is how to keep an open mind. I've found that action comes first, then motivation. What that means is that the more action/activity you spend in your project, the more motivated you're going to get about it. Especially in the beginning. This is a good thing because it keeps you working long hours, but it's also a bad thing because it can prevent you from seeing vital pivot points as you encounter them. However you see your app, the customers are going to have another, unexpected view of it. When that happens, you have to be able to hear the customers and respond quickly. My strategy to deal with this is to keep things as absolutely simple as possible I have a theory about the need for my product. My program should address that need and that need only. In this fashion I don't get attached to all the other little things that are not important

There's the brain dump from the past few weeks (unedited). Hope it helps some of you other guys out there like me leaping into the startup-world.

Happy Startup Holidays

2009-12-10T02:15:16Z

A Venture Capital fund called First Round Capital put together this neat video holiday card. It really reminds me why I like startups so much!

First Round Capital 2009 Holiday Card from First Round Capital on Vimeo.

Hamburger Casserole Recipes?

2009-12-08T14:45:16Z

Over the last few months my wife and I have been doing a bit of real-estate prospecting. It's not like the usual stuff, where you look at listings, do a lot of calculations, walk the site, and then start the financial work -- this has all been on the web. We've been investing in small web properties.

So, for instance, the next time you're looking for hamburger casserole recipes, hopefully you'll hit one of our sites. (If you go there you'll find there isn't anything salacious or untoward: it's just sharing some of the best recipes we have for hamburger casseroles to people who are looking for some)

This has been an eye-opening experience, so I thought I'd share a bit of what I've learned.

I've become a bit of a SEO (Search Engine Optimization) freak. Not a spammer or anything like that, but somebody who is beginning to understand how different pages get ranked different ways on different search engines. I'm starting to learn, for instance, how Google knows how to sort the results of your search.

I now understand why my blog will always be 3rd or 4th string: I have no focus. Or rather, I write like a normal person writes in their diary and not like a targeted money-making machine. There are guys who can do this: find a small niche and write the heck out of just stuff in that niche.

I am not one of those people.

I get bored easily, and the blog is mainly for me. So it's always going to be a mishmash of whatever I like. Cross out the plan for world-domination through blogging.

]]> Part of the trick in investing in web real estate is to create properties people want to advertise on. The web is a huge series of tubes, and unless you're on the right one nobody is going to want to put their billboard there, and it's all about billboards and eyeballs.

From looking at advertising lists, advertisers basically want to sell you insurance, houses, and have you file a lawsuit. So if you have an accident while looking at a new house? The web is your friend. And if you have a DUI on the way there and/or contract Mesotheliioma? Even better.

There's more than that. There's quite a bit of hosting services, lasik eye surgery, mortgage refinancing (yes, looks like still a bit of that going on), and of course, payday loans.

(And no, I am not trying to target those words in this article!)

But I was surprised at how big of a play lawyers are making in the keyword advertising business. There must be a really competitive market out there for them. Who knew? Lawyers are the door-to-door salesmen of the internet age.

On the search side, I have spent countless hours pouring over what the average person searches for. And it isn't pretty: as far as I can tell, people use Google to tell them everything except when to go to the bathroom. They probably use it for that, too.

Celebrities are big; really big. But mostly celebrities in trouble. When a celebrity gets in trouble, we want pictures. The old Jon Stewart joke about "naked famous people" is still very true. If you have a pictures of naked celebrites screwing up, you are going to have have lots of internet traffic.

Oddly, there isn't a demand for for advertising on those keywords. Or in other words, the traffic from those pictures probably isn't desperate to buy a lot of stuff in a competitive market. I'm not sure, but "Famous Naked People" is probably more of a volume play. In other words, it's more like watching American Idol than attending a time-share presentation.

Lots of folks are looking for jobs on the net. Or money. One popular search -- and I give this one away to anybody who can make anything of it -- is "free printable fake money." Lots of folks each day ask Google for free money.

Not sure how the Secret Service would feel about the site, but you gotta give people credit. They think Google can do anything.

Of course, my wife and I try to keep on the up and up, finding little pieces of information we can reshape, improve, and publish to people looking for it. Nothing spectacular. For instance, one of our sites, What Is Diabetes? presents lots of information that you can get elsewhere and from better sources, but we try to organize and rework the information in a much more accessible format for folks (and point them to authoritative sources as well)

So the question you're all asking: are you making any money off of this? After about ten sites, yes, we are. Would I recommend this as a hobby business for others? No, I would not. It's a freaking lot of work, to begin with, if you are really looking to provide useful and quality information. If you're just looking to spam, perhaps that's another set of criteria. I know an affiliate marketer who told me six months ago that after just a few months he was making over $3K per day, but that kind of stuff isn't the type of business you want to explain to mom. For what we do, it's beer money. I think most folks would find the time-spent/income ratio to be very painful.

It's also getting to be a highly-competitive business. Companies are using advanced algorithms to determine exactly which subject areas have the most lifetime value for advertising and creating lots of material around them. It really has the feel of the stock market when computers got in and changed everything. Yes, you can still have a very profitable niche. Heck, I have several ideas about moving up to the next level. But these guys play hardball over pennies-per-day. Any newcomers should know that before getting in.

There's also no guarantee -- you could work your butt off this month and have all your work wiped off the search engines next month because somebody better came along. Or even worse, because one of your competitors used a link-spamming program to promote your site, thereby getting Google to dump the entire site from the search results. And good luck trying to find somebody at Google with a sympathetic ear to explain that problem to.

Or Google could just change the way they rank results. Ouch.

Having said that, we're probably going to keep it up. Every week we get emails from people we have helped with our sites, and that's really neat. There's something about having recurring income that makes you go "Wow!"

It's a good feeling.

EDIT: For all of those folks who are ready with a knee-jerk response, like "You, sir, are what's wrong with the internet" -- hold on a minute. Write something lucid and engaging or don't comment at all. This isn't reddit.

There is only so much information in the world: most writers will tell you that there are a limited number of plot lines for TV episodes, for instance (which is why everything kind of looks the same after years and years of TV). There is, however, a very large subset of various audiences looking for information, and each audience needs information in a different format. You wouldn't tell a six-year old about weather in the same way you'd tell a college graduate, although the base information is the same.

We take information, lower it to a 6th grade level, mix in multimedia presentations, and target only that material that the casual user wants. This is different from, say, a organization's website which is targeting a different audience and providing information based on other factors.

I've seen spam sites, with invisible text, hundreds of keywords, the meta description loaded up with garbage. We are definitely NOT writing spam sites. The reader comes first. If we didn't believe we were providing something valuable to the web reader we wouldn't be doing these things. As I said, there are guys making thousands of dollars a day from trash sites. We definitely do not want to do this. And if you think this is what we're about you are mistaken.

Unethical Programming?

2009-12-03T16:58:17Z

The recent story about FaceBook's Farmville having more traffic than Twitter got me thinking: is there such a thing as unethical programming?
I know many of you will say that Farmville is harmless because it takes people away from boredom and provides them with entertainment. And, after all, they choose to do it.

But there is an undeniably addictive nature to these games. Each game not only competes with other games that a person might play when bored, but it also competes with stuff a person should be doing.

So -- where's the line? Would you write a game that "entertained" doctors in surgery? (Put another way, if you were designing medical software, would you add game-like hooks to keep people's attention focused on it as a way of competing with other medical devices?)

Would you write a program that people would rather play than have lunch? A game that millions of people spend 40-hours-a-week on, like Wow? FaceBook's games are using players to perform hours and hours of menial, mindless tasks as they market and sell to them and other FB users. At what point do you cross the line between simply entertaining people and harmfully manipulating them and using them?

Managing Technology Means Being Wrong a lot

2009-11-28T17:20:57Z

A friend yesterday twittered and posted into FaceBook a status update about Kanban and programming teams:

"list of electronic tools for lean and kanban teams http://bit.ly/6WW8cS #kanban"

(Kanban is a way of doing work where you use a board to show a "flow" of work and limit the number of activities in any one stage to a certain number)

To which a friend of his replied:

"Yeah, the whole idea of managing the pipeline in a structured way makes a lot of sense. In fact, strange as it sounds, I can see how you could apply the principles to a larger enterprise waterfall of iterative project[s]. You could use it to focus the team on the immediate pipeline...

Yikes!

]]> This reminded me so much of a friend of mine who is big into Scrum (He sits on the Scrum Alliance Board). To him, every problem is solved by some combination of Scrum. If you're running 20 teams on a program, you need a scrum of scrum. If your division has 120 teams you need a scrum of scrum of scrum. Got 500 teams in your huge enterprise? Well you need so many scrum-of-scrums that I lost count.

As technologists we are always looking for simple metaphors to handle complex systems. Simplicity is good -- we should always strive for it. The goal in creating a large system, whether a computer system or a system for managing programming, is to make it as brutally simple as possible, and not a bit more.

Of course, the very next question should be, how do I know when I've gone too far either making things too complex or too simple?

The answer to this is 1) small steps, 2) err on the side of simplicity, and 3) have a very responsive system that measures feedback and changes course

When I look at the ClimateGate emails, what strikes me the most is people actively trying to prevent the error-correction system -- open data and methods, honest peer review, critique -- from happening. This sets off big alarm bells. I got the same feeling from my Scrummy friend: whenever something didn't work using Scrum, his answer was always "well it wasn't being done right", not "we need to challenge our beliefs here"

Scrum just doesn't work that well at the program level. I'm not saying it can't work well at all, but I'm saying that you don't just take the way things happen on a co-located team of 5 and somehow "expand it" or blow it up like a big balloon and end up with something that can effectively track and manage 20 projects. It'd be nice if it worked like that, but it doesn't. (And don't take my word for it. Feel free to try it and find out for yourself. After all, the point of this article is that you have to take small steps and adapt, not that others can do your thinking for you)

The same goes for Kanban.

At Agile 2009 I went to a session on making better Story/Kanban boards. The guy started out with a simple board with a couple of columns. At the end of the 2-hour session, each of our teams had created this color-coded, post-it-tagged system from hell. It looked like something a serial killer would have created in the back room of his dank apartment -- if a serial killer wanted to build a new e-commerce application.

How did it get like this? Everybody worked in a vacuum and we all used intuition as to what might work or not. And intuition will commonly fail you when working with technology.

I'm going to repeat this in case you missed it: Intuition will commonly fail you when dealing with technology.That's why good technologists are also good scientists: looking for patterns, forming hypotheses, and coming up with reproducible tests.

That ResizeableArray that worked so well dealing with 400 people at your school is not going to scale to 400K people. The functional programming style used by you and three other guys probably won't scale to 50 off-site developers with varying degrees of competence. The offshore system that worked wonderfully well on your last project isn't going to work at all on this one -- even though it's basically the same type of project. The state management system you used when running on one box is going to flake out on you when you've got 100 boxes. I could go on. And on.

So we take little steps, we measure, and we adapt quickly. Whatever we do, from creating little pieces of functionality to creating Kanban and story boards to creating bug-tracking sytems, we take little steps, measure, and adapt quickly. Every team, every industry, every company is different, and unless we get good at those basic skills, we're just working from book knowledge and seat-of-our-pants thinking. Architecture Astronauts are not just architects. We have a little one inside of each of us.

Once you've lost your ability to be wrong, it's time to leave the game.

There is no do, only try

2009-11-23T16:56:52Z

I was reading a technology forum the other day when somebody asked a question that kind of went like this: "I am a programmer. I've noticed lately that my attention span is getting shorter and shorter. Could you guys provide me with quick advice on how to make my attention span longer?"

I suppose something in the form of a XKCD comic or a couple of sentences might not be too much?

On one hand, I really feel for the guy, as evidenced by my own struggles with distractions. But on the other hand, something's out of whack.

]]> A blog I read a year or two ago put it kind of like this: "Somewhere there is a 300-pound man in the latest running gear -- expensive shoes, clothes, cardio equipment, etc -- sitting on the couch eating Doritos and reading the latest "Runner's World" magazine article about how to improve your marathon times. This man has not ran for twenty years and will not go running any time soon."

It's the drive-by, magpie, spectator-in-the-sky thing again. Let me pick up this little shiny bit of information -- it gives me joy to collect shinnies -- and imagine for a moment that one day I actually might be doing something where I would need it. This imagining gives me a brief sense of satisfaction without any of the pain that would go into actually doing it.

My response was to quote Yoda: "There is no try, only do." which means either do something or don't, but even begin to fool yourself into thinking that collecting little easy-to-eat bits sparkly of wisdom is actually doing much of anything at all.

I'm working on a server deployment issue right now -- trying to cram F# into a web hosting provider that doesn't want to run anything in beta -- and I was thinking about what a pain that's been over the last couple of days. Why does everything have to be so complicated? So late last night I posted my question over on HubF#. The guys over there are awesome and I had many replies by the time I got up.

None of which were very useful, unfortunately. But it's not their fault.

One guy was doing something completely different, but my words sounded kind of the same to him (perhaps he was just scanning because of a lack of attention skills?) so he posted his link where he solved a different problem. A couple of guys gave a blanket answer that you would have picked up from any Microsoft sales pitch over the last ten years.

Actually I used the post as sort of a negative indicator -- there is no obvious easy answer. So I assume that means it is doable, just frustrating. That's good news! Means I'm a bit ahead of the curve. So today I set about doing it.

Interestingly enough, a couple of weeks ago the same amount of frustration would have probably stymied me -- as you solve problems, you build up "problem muscle" that you can use to solve even more problems. Eventually you're like "okay, this is going to be very painful and frustrating, but I'll work my way through it. I always do. Let's start!"

One of the things I notice when training technology teams is that good team are always making up excuses to succeed whereas poor teams are always making up excuses for why they can't. That's why when I'm coaching the critical thing I look for is how the team solves problems, and the critical thing I provide is a way for the team to increase their "problem muscle"

The fascinating part of this is that it does not depend on success. I very well may work for a few more days and never be able to solve the problem. But still I benefit from the attempt. It's a no-lose situation, but it requires action and not speculation.

Yoda was wrong, but he had a good point. There is no do -- accomplishing a goal is what you focus on but it's not the real reward. The real reward is being able to try -- to execute -- better and better each time you move towards a goal. Want a better attention span? Go make yourself do something that requires it. When you're done -- even if you fail -- you have a better attention span.

Want to learn how to improve your marathon time? Get off the couch and try running to the mailbox.

There is no do, only try.