
Don't write code first - a3voices
http://blog.reemer.com/why-only-fools-write-code-first
======
ginko
I understand that Hacker News is mostly targeted towards the startup crowd,
but asking _hackers_ to have a business model before they write anything is
completely backwards to me.

Hackers don't write code because they want to make lots of money. Hackers
write code because they are hackers. Building a viable business on top of that
code may be a nice side effect of this.

~~~
adlpz
The word hacker has been twisted into oblivion.

Just assume that any mention to 'hacker' in Hacker News has nothing to do with
hacking, but with entrepreneurship.

~~~
sebinsua
It has and it hasn't.

There's always been a yin-yang between hacker and hustler here.

And I am glad this hasn't been destroyed as there is merit in the frame.

We hack and hustle customers and software.

We validate the market on both ends: business and product.

------
segmondy
I can't wait to see the "Write code first" article later this afternoon.
</sarcasm>

There are no concrete rules in life, I get it. If you are trying to make
money, all he is saying is find out if people are actually willing to pay for
this. However, like other's have pointed out, sometimes we write code not
driven by monetary rewards but just the joy of coding. There are no concrete
rules, sometimes it's a great idea to write code when the idea comes into your
head, sometimes it's not. The hard part is figuring out when to do which.

~~~
dexen
_> I can't wait to see the "Write code first" article later this afternoon.
</sarcasm>_

== Don't go looking for customers before you have working code. ==

Years of experience show sales and investment rounds go better if you can show
an actual, working software. The solution doesn't have to be complete, nor
perfect fit for this particular customer, but nonetheless, if you pitch, you
better be able to back your words with something concrete.

Don't even attempt to set pricing or commiting to delivery deadlines unless
you have at least sizeable chunk of code working. At the very least have
third-party libraries ready and pick a platform (hardware, OS and UI toolkit)
that provides most of what you need.

Beware that quite often what seems an easy endeavour upfront, show to be quite
complex, perhaps even unachievable, as you start coding. Thanks to the halting
problem, it's not possible to find that out without actually implementing the
important parts of your software.

Last but not least, before you start selling, have had written and delivered
at least a few similar pieces software. Having experience in problem domain is
crucial for producing commercial-grade software.

# # #

Phew, easier than it seemed -- which goes to show how little value is in such
generalizations. At least in general ;-)

------
davidjgraph
There are some assumptions in the story. The first is that you/your team is
able to communicate your idea verbally (maybe with some mockups) clearly
enough that people understand it fully. This isn't always the case, and it's
certainly not always the case with engineers. We're in this process right now
and I tried to explain exactly what the product is verbally to potential
users, I just couldn't.

The second assumption that seems to come into this argument is that ideas for
products are stand-alone and don't evolve through experience in a domain and
feedback of pain points on existing products (prior to where we form the
idea).

You either put up a landing page and say give me your email, or you build a
minimum viable product as with feedback as you build.

So we built the minimum viable _prototype_. It's not the MV product, anyone
using it gives up within 3-4 minutes. But combined with me talking directly to
the user, I can now hear that lightbulb turn on as they get what I'm talking
about.

Simply, it's a continuous spectrum between the two boundaries and you need to
pick the right point for your product. As a contextless headline, this is bad
advice.

~~~
zacharycohn
I think you missed the point a little bit.

The point isn't to get them to confirm what you want to build is the right
thing, it's to learn more about their problems to find out what you should
build.

------
RokStdy
I really don't understand all of the negative feedback to this post (maybe I
didn't see the old title, as it has evidently changed).

It seems like this is straightforward honest advice when you're trying to
solve somebody else's problem(s). Some other folks have mentioned other
products as examples of build first, but those all seem to have been people
solving their own problem/desires.

If you're trying to create a business that attempts to solve other people's
problems, this approach would be excellent. The example that the author used
(Movie theater) illustrates the point of view perfectly. I suspect none of us
have ever had the problem of watching a movie and being distracted by the fact
that we didn't purchase enough snacks. That is not a problem a 'user' has ever
thought of, but I would guess theater owners think about it a lot.

~~~
codezero
The original title was "Why only fools write code first"

I'm glad HN moderates titles, it's super unproductive to react to a title but
people do it anyways, rather than reacting to the content.

It's easier to just read the title though :)

~~~
a3voices
I simply made the original title of the submission match the title of the blog
article. I didn't realize it would be an issue.

~~~
codezero
You did the right thing honestly. The rules seem to indicate matching the
source title is the defacto right thing to do.

All the same, I think in cases where responses start reacting to the title and
not the content, it makes sense to moderate it, but then again, I am biased.

------
vezzy-fnord
This whole "everything has to be a business" mentality can get pretty toxic.
It's perhaps the root cause for all sorts of things like proprietary software
(not inherently evil, but by definition cannot be trusted), software patents,
DRM and whatnot.

A hacker who has an idea will do it regardless of whether it'll make them
money or not.

~~~
udit99
> A hacker who has an idea will do it regardless of whether it'll make them
> money or not.

That's exactly the motivation that drives me to create side-projects. But it's
still a bummer when nobody uses them.

The point is not about money, but creating value. Hackers don't always want to
create things just for flexing their technical muscles. In the end, we all
want to provide value in one form or another. If no one is using your
software, then it's wasted effort.

You could modify the approach outlined in the post and just verify peoples'
pain-point and see if they'd be willing to just use your software instead of
asking them to commit to paying for it.

~~~
general_failure
Some people on this thread liken hackers to children/babies. Doing things out
of fun and compulsion without thinking too much about the net result. That is
hardly true (as you say)

------
patatino
The last time I talked with 5 potential customers they all agreed that my idea
would really fit their needs but they can't see how this ever would work.
Explaining to them couldn't change their mind.. I like your approach, but
sometimes a little demo is necessary.

edit: I'm dissapointed this isn't about entity framework ;)

------
unholiness
People don't always know what they want. People have trouble seeing which of
their needs can be feasibly addressed. People are bad at imagining how new
ideas integrate with their established way of doing things. If, 10 years ago,
you'd asked every current smartphone user whether they needed a multi-hundred
dollar phone that does mostly the same things as their laptop, the vast
majority would say no.

Hackers don't always know what people want. Hackers, having hammers, will only
see the bits of problems that look most like a nail. Hackers, having hammers,
will forget that other people don't like to deal with hammers. Hackers, having
hammers, say things like: "For a Linux user, you can already build [Dropbox]
yourself quite trivially by getting an FTP account, mounting it locally with
curlftpfs, and then using SVN or CVS on the mounted filesystem."
([https://news.ycombinator.com/item?id=9224](https://news.ycombinator.com/item?id=9224))

The real lesson is to integrate users in every part of development. Targeting
a specific user group? Talk with them, try out products they use, and try to
grok their needs, values, and relationship with technology. Trying an
innovative interface? Throw together a minimal, flexible mockup (just enough
to facilitate a conversation), and find out how people react.

Whether you should _start_ with users depends highly on the product, but get
users involved throughout the design process when user input is needed.

~~~
kareemm
I think you should always start with users by having a deep understanding of
their problems. That may come from domain expertise or from talking to them.
But if you don't start there, you're going to make a lot of incorrect
assumptions.

------
c0n5pir4cy
A lot of successful things have been built before there was customers. Some
people just enjoy building cool things and when they start don't really care
about customers; Minecraft springs to mind.

Also, the quick rise of this is a bit suspicious.

~~~
Afforess
>Minecraft springs to mind.

Minecraft is an example of a game at the right place, at the right time. Indie
when indie was the hot new thing, 3d voxel, when gaming was tiring of FPS's,
and cheaper than most console games.

It is not a model others, or even Mojang has been capable of replicating.

~~~
rhizome
_Minecraft is an example of a game at the right place, at the right time._

A great number of products and business ideas spring from noticing that
something seemingly necessary doesn't exist, which, said another way, is
recognizing that there is a right time out there waiting for the right thing
to come along.

I see the battle here as a conservative/liberal one. Not politically,
necessarily, but of personal effort. Do you research and line up customers and
let people wait for the product to arrive, and in this way creating a right
place for a product to occur in (hopefully) the right time? This i see as
conservative with ones own efforts while beign liberal with other peoples'
time and attention. Alternatively, being liberal with one's own efforts in
creating a product that can be presented in a turnkey fashion, effectively
treating the customer's time and attention conservatively. There's no right
answer.

------
jlongster
I understand the spirit of the post, but it's not so black and white. You
should think about what you really need to do, and then do it. That might be
writing a little code first, and then focusing on the customers.

The reason is that a lot of the time you need to technically validate an idea.
You have a great idea for a product but you have no idea if it's even
possible. You _have_ to write code to understand what your product is even
going to be ("these are the 3 most important features, can we actually do
them?") Maybe these are features that depend on an external service and you
need to make sure they provide the right info.

I feel much more willing to sell an idea when I have a vague idea that it's
possible.

But yes, only write as little code as possible at first, and expect to throw
it all away. It's just part of the research process.

~~~
kareemm
Author of the post here.

> The reason is that a lot of the time you need to technically validate an
> idea. You have a great idea for a product but you have no idea if it's even
> possible.

I agree that things are rarely black and white, but because hackers tend to
default to their comfort zone - code - and because (in my experience)
technical risk is usually a non-issue, the biggest risks are finding a large
enough market, a set of customers willing to pay, and a way to profitable
reach them. Since they're usually the biggest risks, it makes sense to tackle
them first.

~~~
jlongster
Definitely agree that most technically-focused people fall into the trap of
writing too much code too early.

There's the other end too, though: you get so wrapped up into an idea and sell
it too hard and end up not delivering because you were detached from the
technical reality.

I think you just need to be smart about switching contexts, especially early
on in the game. Using a little bit of code here and there to stay well-
grounded, while focusing on customers to validate the idea. Early on you
definitely should be spending most of your time engaging future customers.

~~~
kareemm
> Early on you definitely should be spending most of your time engaging future
> customers.

100% agree. Though my approach is less about selling and more about learning:
are we solving a valuable problem? Are people willing to pay for it? Do we
have some ideas about how to scalably reach those folks? Etc

~~~
jlongster
That's true. I guess because I'm a "hacker" I just don't know how to ask those
questions without involving the technical merits of the product.

I have a specific question, as I'm in this phase right now. I need to validate
my product and demographic. It's a finance app targeted towards developers.
I'm still working through the core feature-set (on paper, and a little code).
It needs to differentiate itself in the details; the market is somewhat
saturated. I also don't see how I can make a landing page without screenshots.

Now, how do I validate it without writing any code? I have already written
some code because I need to make sure I could get certain info from banks. I
need to make a landing page to get people to sign-up. Can I really do that
without screenshots (even if it's mock-ups, I need to think about the UI a
little)? I need to "sell" it on a few features; writing code has helped a ton
to sift through my ideas. How do you flesh out a landing page when you just
have an idea?

Obviously, I'm still learning about this.

~~~
kareemm
> I also don't see how I can make a landing page without screenshots.

Use thumbnails with copy about benefits. That's what we did.

> How do you flesh out a landing page when you just have an idea?

We talked to customers about their problems - we reached out to people through
our networks and cold emailed them. We understood their problems first, then
were able to create a landing page with fake thumbnails of the interface. We
wrote copy detailing benefits (save time / save money / make money) of the
product. The goal of the landing page was to get more people who we could talk
to to validate our idea.

It didn't matter that the product didn't look anything like the thumbnails.

The only code we wrote was to hook up the landing page to Mailchimp.

------
zacharycohn
Great article. This is something that, logically, makes a ton of sense... yet
very few entrepreneurs do.

I published a Slideshare last week with some tactical tips on performing the
interviews: [http://www.slideshare.net/ZacharyCohn/18-customer-
interview-...](http://www.slideshare.net/ZacharyCohn/18-customer-interview-
tips)

[Full disclosure- my company teaches big companies about this stuff. We
publish a lot of free content as A) Content marketing, but B) as a way to help
our startup friends.]

------
peterwwillis
What's ironic here is all the push-back from people about why you seemingly
don't need to think about anything but code. There's a bunch of hacker and
code-specific reasons not to write code first he doesn't even mention.

\- To provide a usable product for your customer you need to _ask them what
they want_. I can't tell you how often I see tools that are practically
unusable for the target audience because the devs were just writing with devs
in mind and couldn't be bothered to take a couple days to do interviews. (I'm
looking at you, every-open-source-tool-that-gets-shown-off-on-HN)

\- Writing code first also means you probably didn't have a plan for the
entire design flushed out, which means hacks on top of hacks, which is
equivalent to a giant Jenga stack with half the pieces missing.

\- How will this code be used in 10 years (if at all)? In 20? Is it going to
be made obsolete, or will your users and their needs change? (think
multimedia, transportation, competing market forces, legislation, etc)

------
bosky101

        "Talk is cheap. Show me the code" Torvalds, Linus (2000-08-25)
    

Surprised this quote didn't get mentioned already.

FWIW... on a first glance, i parsed the submitted title as

    
    
        "don't write, code first". 
    

lol.

On a more serious note, I wonder if the folks at Xerox Parc would have created
the mouse/various interface hacks had they thought about the biz. On the
contrary it was the "business concerns" that decided to not continue it
further.

That said, code itself has its own consumers/customers who will use what you
create. And that's selling in its own right. _eg:_ jQuery's decision to
incorporate chaining, selectors, more functional aspects.

When i write frameworks or libraries, I always try to start with the
api/wrapper first, and then work on the internals. can't remember the threads,
but am sure there have been a bunch of HN threads on just this subject.

~B

------
general_failure
What is being described is called 'consulting'. No consumer would pay for code
that doesn't exist.

~~~
kareemm
I'm the author. This is demonstrably not true.

------
fein
I've always been mystified by the oddly specialized approaches that come
across as a "one size fit all" claim.

Just like pure Agile, Waterfall, etc methods aren't complete solutions, we
seem to have the tendency to try and redefine "good software development"
every other month.

The most important thing is to do what works the best with your team; and even
this varies from project to project. Sometimes coding out a half baked idea
into a POC is better than spending hours on a whiteboard, just to get stuck at
some unforeseeable roadblock as soon as the code hits the editor.

Sometimes, you need to hash out a problem on paper before devoting coding
time. Proclaiming absolutes as gospel is a little dangerous.

------
nostromo
Are there any examples of a big tech company that started with sales and not
the product?

~~~
xerophtye
Microsoft :P can't get any bigger than that. They sold DOS to IBM even before
they had anything like that

~~~
jwdunne
If I remembering reading correct, MS also sold their version of BASIC to
Altair before actually having physical access to an Altair.

~~~
xerophtye
If i remember correctly, they wrote BASIC for it, (language design) and then
pitched it to altair, who then gave them an actual altair to implement it on,
no? Btw, wasn't programming without actual access to a PC, pretty common back
then too? (even decades later, when u had decent computers). From what i hear
from my dad, programmers wrote it out on paper, and sent it to the data entry
people who would type it in, run it, and report any bugs etc. Heck, imagine
debugging without access to a PC!!

------
danso
Given the state of today's technology, I'm kind of surprised that this
viewpoint would be expressed in such absolute terms. Here are a few companies
I can think of in which "build first" seemed to permeate the enterprise at the
very start:

\- Google

\- Facebook

\- Twitter

\- Chatroulette

\- Minecraft

~~~
Heliosmaster
and how many build first and solve a problem no one has?

~~~
c0n5pir4cy
Lots, but at the end of the day it shouldn't mean that nobody should build
first.

------
cyberneticcook
I understand that for the author of the article the goal is to make a product
that people use and that entails a financial return. I just want to say that
building a software from scratch, even if doesn't end up used by millions of
people, is worth doing for the process itself. Not just for the fun of it, but
especially because you learn a lot during the process. I don't consider
learning a waste of time nor a fool somebody that is motivated more by
learning than by fame and money.

------
rurban
True header. Don't write code first. First write the docs to understand the
problem domain from the other side, the user, and come up with a better API.
Then write the tests to support this API you came up with, and help
structuring the code into small testable units. And lastly write the code. The
business model needs not to be written, it must be simple enough to stay in
your head and explain it to anybody in two sentences anyway.

------
martywm
This is interesting. I have applied to YC and have not written code first. I
have talked to customers and found out they need. We will see if these quotes
hold true because in interviews I read YC likes when something is already
coded a bit.

------
dave_sid
This, and about 2000 other articles, are just a regurgitation of the Lean
Startup book.

It's almost comical these days when you read a blog article or pick up a
magazine and it's just recycled ideas from that book.

------
raz32dust
I think this applies to startups that target businesses, and this is generally
good advice for that segment. It doesn't really apply to consumer products
like Facebook, Google, Minecraft etc.

------
checker659
Is this really a one-size-fits-all advice because I always seem to be
presented with it as being such. Clearly there must be edge cases where this
advice doesn't apply (?).

~~~
DrJid
Yeah, I don't think it's a one size fits all. However, if you can present a
solution to a person's problem, and that solution does instantly resonate and
it becomes obvious that such an app/website can exist to solve it, people will
want it badly. -- and that becomes obvious.

I basically think it ties back to becoming an expert on the problem. Instead
of the solution.

------
needacig
Suspicious that this made it to the top with almost no comments.

~~~
kareemm
Ha. Author of the article here. I submitted this 588 days ago when I first
wrote it:
[https://news.ycombinator.com/item?id=3721015](https://news.ycombinator.com/item?id=3721015)

Just bummed I'm not getting karma for submitting it this time!

------
rkv
Sometimes you need a demo to gain customer attraction.

------
druska
Always writing code will also make you a better developer.

~~~
icecubed
Becoming a better developer requires a certain level of self-criticism and
willingness to improve and learn. Just writing (lots of) code alone will not.

~~~
a3voices
Writing lots of code will make you a better developer if you lack the
experience, but you will plateau if that's all you do.

