7 ms·

Don't write code first

141 points by a3voices 13y ago

danso 13y ago
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 13y ago
  and how many build first and solve a problem no one has?
  - danso 13y ago
    People who, unlike a successful drug dealer, actually want to use their own product? I agree that if you are someone with desires not shared by the rest of society, you should probably go and talk to people and see what they desire...but it's also quite possible to think of something you and maybe some of your friends would use and have that be the guiding force in development. The problem with asking other people whether they'd like it, well [insert apocryphal story about Henry Ford and people wanting faster horses]. It's not either-or, it can be a mix. But it's not beyond the capacity of some hackers to hack on something they care about and, at the same time, have it be something that others will care about, unless all they're doing is trying to make a quick buck in the startup rush.
  - c0n5pir4cy 13y ago
    Lots, but at the end of the day it shouldn't mean that nobody should build first.
  - goshx 13y ago
    that's why a lot of products fail. They are solving problems nobody has.
- wickchuck 13y ago
  Really depends on the type of product, if you know it's something that the whole world would benefit from then maybe build first makes since, but if your targeting a niche market then for sure you want to get a barometer if your product is going to be needed and what the biggest pain points of those who would use it are.
- thatthatis 13y ago
  Facebook wasn't "build first" in any appreciable sense. The prototype features were outlined in a well received editorial in the Harvard Crimson in December of 2003. There was widespread outcry for the administration to build what Zuckerberg realized he could build faster. Further, there were existing prototypes in house facebooks. Source: user number under 10k
- peterwwillis 13y ago
  For every five or ten successful build-first companies, there are 10,000 failures. Please keep things in perspective.
  - johnrob 13y ago
    That is a dangerous conclusion - you can blow off just about any piece of advice with it.
  - rhizome 13y ago
    What are the historical estimates of success for the sell-first case? Having both figures is necessary for perspective.
- AznHisoka 13y ago
  All of those, including Google are B2C companies at its core(I know the first 3 sell ads, but they'd be useless without consumers). If you're selling to consumers, you need to know what they want, because asking them won't yield useful answers. Who would have told you "I want a text box where I can type 140 characters about how I feel" 6 years ago? If you're selling to businesses however, you need to do customer and market research.
needacig 13y ago
Suspicious that this made it to the top with almost no comments.
- saosebastiao 13y ago
  I've seen it happen quite a bit with some of the more popular bloggers here, but this one definitely seemed a little suspicious.
- atwebb 13y ago
  Tons and tons of things make it to the top with no comments, I'm always curious as to why they are there and have 20 points (not sure of the accuracy of that) within 8-10 minutes but no comments. Though this is just a delicious linkbait-y title so that probably helps it...
- barrkel 13y ago
  Low comment count is frequently an indicator of quality on HN. Contentious, heat-generating (as opposed to light-generating) discussions, often political and / or emotional in nature, tend to produce the most comments, and are the least useful to read or get involved in.
- kareemm 13y ago
  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!
checker659 13y ago
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 13y ago
  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.
rkv 13y ago
Sometimes you need a demo to gain customer attraction.
c0n5pir4cy 13y ago
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 13y ago
  >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.
  - c0n5pir4cy 13y ago
    The problem is that other companies are trying to replicate a model. Mojangs model wasn't really a model, they needed money to continue the development of Minecraft. People really liked the idea of a voxel creative adventure game at the time and spread the word. Now the market is saturated with them, yet Minecraft is still on top. Expecting the model to play out the same again is stupid, because the original conditions that caused Minecraft to be successful have changed. At the time, Notch just wanted a game that played the way Minecraft did; he was focused on building something cool that played into his nostalgia.
  - rhizome 13y ago
    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.
druska 13y ago
Always writing code will also make you a better developer.
- peterwwillis 13y ago
  And delivering pizzas will make you a better driver. But it's not a good career choice.
- icecubed 13y ago
  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 13y ago
    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.
ginko 13y ago
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.
- al1x 13y ago
  That's kind of the point of this article though. He's pointing out the flaw in the "code first" approach. He started out that way and wound up wasting years of his life. The "hackers" of news.ycombinator.com are (or should be) business-minded hackers (it's kind of the point of ycombinator). This kind of reminder is always helpful.
- ovi256 13y ago
  A "business model" can mean a for-profit enterprise as well as an open source project solving a pain point and showcasing your skills. The questions customer development asks can be used for the open source project too, with great effect.
  - xerophtye 13y ago
    yep! that's how good useful open-source code (especially APIs) are built! I mean dont u want people to actually USE what u took time and effort to write? You may not have written it for money, or to make a business, but you would want people using it. So when you code AFTER knowing what people need, the feeling is way more awesome! i mean think about it, u wanna make something really cool that no one uses? or something everyone agrees on is super cool, and would love to actually use? I actually spent nearly an year writing a rather powerful and challenging mathmatical reasoning engine (heck it can not only solve but LEARN mathematics!) but i had no users in mind. So i could never explain to people why anyone wud want to use it. and that didnt really feel that good
- mildtrepidation 13y ago
  This sentiment is a bit like saying "sailors don't sail because they have somewhere to go. Sailors sail because they want to sail." It may be true if you're on a lake or in a bay, know the area well, and your intention is to just go and flex your sailing muscles. To practice, enjoy, check out something you're aware of but haven't actually navigated, or something else that's similarly within easy reach. It loses its applicability when you consider that, no, some sailors actually do have destinations. And some trips are long or difficult enough that they do in fact require planning, specific goals, timelines, and all manner of other preparation. I'm sure it's not a perfect metaphor, but the point is that the artificial limitation of "hackers hack to hack" is short-sighted and fundamentally flawed. Some do, some don't, and I would say most are somewhere in between. But please don't make the mistake -- on behalf of others -- of defining the entire community in terms of your preconceptions about what hackers do or don't value or attempt in an absolute sense.
fein 13y ago
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.
davidjgraph 13y ago
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 13y ago
  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.
raz32dust 13y ago
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.
jlongster 13y ago
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.
- zacharycohn 13y ago
  How do you know those are the three most important features until you've talked to a bunch of customers who tell you they are?
  - jlongster 13y ago
    How do you know what demographic to engage in until you have a rough sketch of a product? You have to choose something to start with, and starting with a few tech features is absolutely valid.
    - zacharycohn 13y ago
      ... you pick a demographic then go talk to them? Sketch first means you're thinking about a product and hunting for a customer. Customer first means you're thinking about a problem first then building a solution.
      - jlongster 13y ago
        Honestly I think we're just bike-shedding at this point. There are tons of companies that started with a sketch of a product (to solve a known problem) and evolved it based on customer feedback.
segmondy 13y ago
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.
- thwarted 13y ago
  Sometimes it is easier to find out if people are willing to pay for it by writing a little bit of code. The challenge is knowing how much is a little bit and that "proof of concept" applies just as much to possibile-to-sell as possible-to-implement.
- dexen 13y ago
  > 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 ;-)
patatino 13y ago
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 ;)
deleted 13y ago
[deleted]
nostromo 13y ago
Are there any examples of a big tech company that started with sales and not the product?
- xerophtye 13y ago
  Microsoft :P can't get any bigger than that. They sold DOS to IBM even before they had anything like that
  - jwdunne 13y ago
    If I remembering reading correct, MS also sold their version of BASIC to Altair before actually having physical access to an Altair.
    - xerophtye 13y ago
      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!!
- zequel 13y ago
  MS-DOS?
peterwwillis 13y ago
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)
RokStdy 13y ago
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 13y ago
  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 :)
  - RokStdy 13y ago
    Ah, ok, thanks. I see now why there would be a harsh reaction. I will re-title my forthcoming post from "Why only stupid dummies do 'x'" to something more nuanced. :-)
  - a3voices 13y ago
    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 13y ago
      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 13y ago
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 13y ago
  > 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 13y ago
    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)
zacharycohn 13y ago
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-tips http://www.slideshare.net/ZacharyCohn/18-customer-interview-... [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.]
dave_sid 13y ago
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.
general_failure 13y ago
What is being described is called 'consulting'. No consumer would pay for code that doesn't exist.
- brownBananas 13y ago
  Are you sure?
- kareemm 13y ago
  I'm the author. This is demonstrably not true.
- xerophtye 13y ago
  apparently you haven't been to kickstarter.com
unholiness 13y ago
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 13y ago
  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.
deleted 13y ago
[deleted]
martywm 13y ago
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.
rurban 13y ago
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.
bosky101 13y ago
"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
cyberneticcook 13y ago
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.

141 points by a3voices 13y ago

danso 13y ago

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 13y ago
and how many build first and solve a problem no one has?
- danso 13y ago
  People who, unlike a successful drug dealer, actually want to use their own product? I agree that if you are someone with desires not shared by the rest of society, you should probably go and talk to people and see what they desire...but it's also quite possible to think of something you and maybe some of your friends would use and have that be the guiding force in development. The problem with asking other people whether they'd like it, well [insert apocryphal story about Henry Ford and people wanting faster horses]. It's not either-or, it can be a mix. But it's not beyond the capacity of some hackers to hack on something they care about and, at the same time, have it be something that others will care about, unless all they're doing is trying to make a quick buck in the startup rush.
- c0n5pir4cy 13y ago
  Lots, but at the end of the day it shouldn't mean that nobody should build first.
- goshx 13y ago
  that's why a lot of products fail. They are solving problems nobody has.
wickchuck 13y ago
Really depends on the type of product, if you know it's something that the whole world would benefit from then maybe build first makes since, but if your targeting a niche market then for sure you want to get a barometer if your product is going to be needed and what the biggest pain points of those who would use it are.
thatthatis 13y ago
Facebook wasn't "build first" in any appreciable sense. The prototype features were outlined in a well received editorial in the Harvard Crimson in December of 2003. There was widespread outcry for the administration to build what Zuckerberg realized he could build faster. Further, there were existing prototypes in house facebooks. Source: user number under 10k
peterwwillis 13y ago
For every five or ten successful build-first companies, there are 10,000 failures. Please keep things in perspective.
- johnrob 13y ago
  That is a dangerous conclusion - you can blow off just about any piece of advice with it.
- rhizome 13y ago
  What are the historical estimates of success for the sell-first case? Having both figures is necessary for perspective.
AznHisoka 13y ago
All of those, including Google are B2C companies at its core(I know the first 3 sell ads, but they'd be useless without consumers). If you're selling to consumers, you need to know what they want, because asking them won't yield useful answers. Who would have told you "I want a text box where I can type 140 characters about how I feel" 6 years ago? If you're selling to businesses however, you need to do customer and market research.

needacig 13y ago

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

saosebastiao 13y ago
I've seen it happen quite a bit with some of the more popular bloggers here, but this one definitely seemed a little suspicious.
atwebb 13y ago
Tons and tons of things make it to the top with no comments, I'm always curious as to why they are there and have 20 points (not sure of the accuracy of that) within 8-10 minutes but no comments. Though this is just a delicious linkbait-y title so that probably helps it...
barrkel 13y ago
Low comment count is frequently an indicator of quality on HN. Contentious, heat-generating (as opposed to light-generating) discussions, often political and / or emotional in nature, tend to produce the most comments, and are the least useful to read or get involved in.
kareemm 13y ago
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!

checker659 13y ago

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 13y ago
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.

rkv 13y ago

Sometimes you need a demo to gain customer attraction.

c0n5pir4cy 13y ago

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 13y ago
>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.
- c0n5pir4cy 13y ago
  The problem is that other companies are trying to replicate a model. Mojangs model wasn't really a model, they needed money to continue the development of Minecraft. People really liked the idea of a voxel creative adventure game at the time and spread the word. Now the market is saturated with them, yet Minecraft is still on top. Expecting the model to play out the same again is stupid, because the original conditions that caused Minecraft to be successful have changed. At the time, Notch just wanted a game that played the way Minecraft did; he was focused on building something cool that played into his nostalgia.
- rhizome 13y ago
  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.

druska 13y ago

Always writing code will also make you a better developer.

peterwwillis 13y ago
And delivering pizzas will make you a better driver. But it's not a good career choice.
icecubed 13y ago
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 13y ago
  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.

ginko 13y ago

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.

al1x 13y ago
That's kind of the point of this article though. He's pointing out the flaw in the "code first" approach. He started out that way and wound up wasting years of his life. The "hackers" of news.ycombinator.com are (or should be) business-minded hackers (it's kind of the point of ycombinator). This kind of reminder is always helpful.
ovi256 13y ago
A "business model" can mean a for-profit enterprise as well as an open source project solving a pain point and showcasing your skills. The questions customer development asks can be used for the open source project too, with great effect.
- xerophtye 13y ago
  yep! that's how good useful open-source code (especially APIs) are built! I mean dont u want people to actually USE what u took time and effort to write? You may not have written it for money, or to make a business, but you would want people using it. So when you code AFTER knowing what people need, the feeling is way more awesome! i mean think about it, u wanna make something really cool that no one uses? or something everyone agrees on is super cool, and would love to actually use? I actually spent nearly an year writing a rather powerful and challenging mathmatical reasoning engine (heck it can not only solve but LEARN mathematics!) but i had no users in mind. So i could never explain to people why anyone wud want to use it. and that didnt really feel that good
mildtrepidation 13y ago
This sentiment is a bit like saying "sailors don't sail because they have somewhere to go. Sailors sail because they want to sail." It may be true if you're on a lake or in a bay, know the area well, and your intention is to just go and flex your sailing muscles. To practice, enjoy, check out something you're aware of but haven't actually navigated, or something else that's similarly within easy reach. It loses its applicability when you consider that, no, some sailors actually do have destinations. And some trips are long or difficult enough that they do in fact require planning, specific goals, timelines, and all manner of other preparation. I'm sure it's not a perfect metaphor, but the point is that the artificial limitation of "hackers hack to hack" is short-sighted and fundamentally flawed. Some do, some don't, and I would say most are somewhere in between. But please don't make the mistake -- on behalf of others -- of defining the entire community in terms of your preconceptions about what hackers do or don't value or attempt in an absolute sense.

fein 13y ago

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.

davidjgraph 13y ago

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 13y ago
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.

raz32dust 13y ago

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.

jlongster 13y ago

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.

zacharycohn 13y ago
How do you know those are the three most important features until you've talked to a bunch of customers who tell you they are?
- jlongster 13y ago
  How do you know what demographic to engage in until you have a rough sketch of a product? You have to choose something to start with, and starting with a few tech features is absolutely valid.
  - zacharycohn 13y ago
    ... you pick a demographic then go talk to them? Sketch first means you're thinking about a product and hunting for a customer. Customer first means you're thinking about a problem first then building a solution.
    - jlongster 13y ago
      Honestly I think we're just bike-shedding at this point. There are tons of companies that started with a sketch of a product (to solve a known problem) and evolved it based on customer feedback.

segmondy 13y ago

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.

thwarted 13y ago
Sometimes it is easier to find out if people are willing to pay for it by writing a little bit of code. The challenge is knowing how much is a little bit and that "proof of concept" applies just as much to possibile-to-sell as possible-to-implement.
dexen 13y ago
> 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 ;-)

patatino 13y ago

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 ;)

deleted 13y ago

[deleted]

nostromo 13y ago

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

xerophtye 13y ago
Microsoft :P can't get any bigger than that. They sold DOS to IBM even before they had anything like that
- jwdunne 13y ago
  If I remembering reading correct, MS also sold their version of BASIC to Altair before actually having physical access to an Altair.
  - xerophtye 13y ago
    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!!
zequel 13y ago
MS-DOS?

peterwwillis 13y ago

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)

RokStdy 13y ago

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 13y ago
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 :)
- RokStdy 13y ago
  Ah, ok, thanks. I see now why there would be a harsh reaction. I will re-title my forthcoming post from "Why only stupid dummies do 'x'" to something more nuanced. :-)
- a3voices 13y ago
  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 13y ago
    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 13y ago

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 13y ago
> 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 13y ago
  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)

zacharycohn 13y ago

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-tips http://www.slideshare.net/ZacharyCohn/18-customer-interview-... [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.]

dave_sid 13y ago

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.

general_failure 13y ago

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

brownBananas 13y ago
Are you sure?
kareemm 13y ago
I'm the author. This is demonstrably not true.
xerophtye 13y ago
apparently you haven't been to kickstarter.com

unholiness 13y ago

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 13y ago
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.

deleted 13y ago

[deleted]

martywm 13y ago

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.

rurban 13y ago

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.

bosky101 13y ago

"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

cyberneticcook 13y ago

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.