XSDs provide type-checking.
4,550 karma · joined January 27, 2009
2. Maybe they are jumping ahead to "many-core". Instead ask: what can we do with this extra silicon? In the past this lead to cache; pipelining; a faster multiplication technique; on-board maths "co"-processor. Today, it gives us systems-on-a-chip; hardware video-decoding; absurd GPUs; and even physics PUs.
I spoke to the person who developed that multiplication technique, and he said that it was due to extra silicon being available - it was inconceivable before then, in that people did not conceive of it because they could not conceive of something so wasteful of silicon.
Second, real reasons: Java is verbose and statically typed, and therefore it takes more work to make changes - it is slower to develop in and less flexible/agile. These things really count when you want to try out an idea; and when you need to adapt it. There's also a community effect, where all those early adopters are working with Ruby/Python, that's the platform cool stuff gets developed for (eg. sinatra, github, haml).
Technically, it's possible to write a sinatra in Java (I have; using annotations for urls); but who would use it? I actually love Java myself, including its static typing, and use it in my startup. But when I've played with Ruby - even as a novice without knowing the tricks - I found it much quicker to develop in, and the code easier to understand because less cluttered. It's probably not as reliable; and the code doesn't run as fast; but these things just don't matter for prototypes and early versions.
When I was 10, The Flintstones had an episode about this. Fred and Barney gathered statistics about what people wanted in a song, and then composed it. They catered to all subjects, and a punchline was that one of them was "mothers-in-law". The song was terrible; the main message seemed to be that such art lacks integrity (not in an ethical sense, but in a sense of fitting together, being whole, being one thing). Of course, such lack isn't necessary (eg. the Monkees had some great songs), but it is much harder than speaking out of a deeper truth. Perhaps it's like the flow of writing off the top of your head vs. over-editing and getting a patchwork of concepts and mismatched conjugations.
I've always liked the idea of a work being both popular and critically acclaimed (who doesn't?). I do think there's a thrill in doing something that is very cool to yourself; but there is also a thrill in doing something that is truly valuable to people. Both can be aspects of the heroic journey, of serving something greater than oneself: serving an idea, or serving a community.
But I think this may be a little different for art (which Sivers is talking about) and software (which I'm (mainly) talking about).
Oh no, you don't ask for feedback from your colleagues - you get it from people with the problem you're solving. From users. Your fellow developers can't even know if you solved the user problem; the best they can do is point out things like grammatical errors which, as you say, is useless.
EDIT I guess your PHP friend wouldn't have been able to bring over users for his very his first app, and I bet he remembers it vividly. You could email him, or talk on the phone. He's not the only person in the world to have shipped, but you know him, so he's an excellent person to start with. You could visit him. Consider: 500 km vs. 4 weeks. Sounds ridiculous, but if you take this journey, you won't forget his point of view.
Is it because you are not convinced that aiming lower is the right thing to do; or do you believe it but you have trouble actually doing it?
Perfectionism is common in programmers (perhaps because imperfect syntax doesn't work). It means that you compare your product with "perfection", instead of comparing it with "nothing" (ie. it not existing at all.) If you tend to be critical, and quickly notice faults and omissions, then you may be a perfectionist. It seems to me that perfectionism is the number one reason why many programmers aren't successful in business. It's very difficult to overcome, but one way to begin is simply try to find what does exist in your product (and elsewhere), and just acknowledge that it does. You might not yet be convinced that it matters, but just being aware of it is a start.
For me, a crucially motivating thing was people actually being interested: feedback. When I launched that 2-hour product, I wouldn't have continued if there was no feedback. But there was (a single email!). Feedback can help survive the gap you mention, to paying customer. Before then, just getting something that does something can be very motivating (see my GP comment).
BTW: don't do tdd for a MVP! It takes too long. The advantages of tdd don't really make sense for prototype.
EDIT Ask yourself how you could cut corners, and yet still deliver some of the essence of the thing. Work out what your one essential idea is, and try asking of a particular line of code: is is absolutely necessary for that essence? Some other questions:
- error checking? *cut*
- corner cases? *cut*
- "option to save your work"? *cut*
(unless it's a DB etc, whose essence is storage)
- cover the most common cases? *cut*
(just cover *one* case)
- documentation? *cut*
(except: the essence + how to run)
- debug? *cut*
(provided it mostly runs)
- integration test? *cut*
- define formats/interfaces? *cut*
- present slides of your product (Steve Blank)
- pretend to have a product, but you just:
post on HN
one webpage (optional: a survey on it + Skype chat)
(feels wrong to me, but can be done ethically)
- adwords campaign + landing page
Here's some essays that might help: "Mediocrity is underrated (or better is the enemy of good enough)" http://nayna.org/blog/?p=11 "Getting Real" [6 very short excerpts, I suggest read all esp the footnote/quotes, in this order:] http://gettingreal.37signals.com/ch02_Whats_Your_Problem.php http://gettingreal.37signals.com/ch09_Epicenter_Design.php http://gettingreal.37signals.com/ch06_Race_to_Running_Softwa... http://gettingreal.37signals.com/ch06_Shrink_Your_Time.php http://gettingreal.37signals.com/ch06_Done.php http://gettingreal.37signals.com/ch10_Less_Software.php and pg's 2008 essay (on HN 2 days ago): http://news.ycombinator.com/item?id=1525068
disclaimer I find it hard to cut corners on my present project. My excuses (which I'd like to overcome) are due to it being based on a new mathematical model:
- if the maths isn't realized correctly, it won't work perfectly
- showing off all its benefits (eg error checking) requires more work
- getting the foundation right will be easier to build on
- patenting (can't be done after release)I'm not clear on what you mean by "losing faith in the product". Do you mean that you stopped believing that it had any value whatsoever; or that any/enough customers would ever like it; or that you lost faith in your own ability to accomplish it? Or do you just mean that... you ran out of motivation?
The key idea is not that "it takes time", but for it not to take time. In other words, to get something done ASAP. I'm talking like 2 hours, not 2 weeks or 2 months.
esr said to launch a product you need something that (a) runs; and (b) has a promise that it can be turned into something really cool in the near future. It's code + words. Note: this means that the thing that runs is not really cool. [many others also state this idea, but I really like esr's formulation]
For motivation in general (not just for launch), the same thing is true: you want to get something that works ASAP. Fred Brooks says of this style of incremental development: I was stunned by the electrifying effect on team morale of that first picture on the screen, that first running system.
I wrote the first version of my product in 2 hours (though I'd been thinking about it for a couple of weeks; and it took a 9 hour day to write the website). This isn't because I'm some great coder, but because the product was that simple. It wasn't "finished". It took a year before the first sale, and eventually I made enough to retire (for small values of retire).
tl;dr release before it's ready.
You found a great article yesterday - now you can't find it!
Reddit is successful, in that it's valued by many. It was successful for the founders [I'd dearly like to know how much they got, to an order of magnitude]. It's only 5 years old - it took Amazon 10 years to become profitable, google began in 1996 was incorporated in 1998, but didn't even start serving ads til 2000 - which accounts for almost all revenue today. So I think it's too early to call reddit "not very successful". [It would be interesting to have data on how long it typically takes for "successful" startups to become successful.]
I do disagree with pg that the essence of reddit was "to tell people what was new". Slashdot already did that and other news sites. Reddit's (and Digg's) innovation was that everyone could vote on comments. [But pg has far better information on reddit than me, so I'm left wondering why he thinks that...]
Yet... HN grows and grows... it is reported widely... luminaries routinely post here... and here are you and I.
pg has said he is careful to focus on what matters (eg. spam; ranking), not what seems to. It appears to be working. And it exactly supports this essay's thesis, of working on looking professional vs. what's important. Maybe it's a bit like undergraduates handing in essays in a fancy folder?
I like the lambda syntax (I don't recall seeing exactly this syntax before):
() -> alert("lambda")
(() -> alert("lambda")) () # to call itsingle page: http://hbr.org/2010/07/how-will-you-measure-your-life/ar/pr
Of the people who have the problem that WePay solves, there is a continuum of how bad the problem is, how important it is to them to fix it and so on. But there is also a continuum of those people's attitudes towards change. Psychologically, some people like change and some don't. It is these early adopter that you want - that are a subset of the people with the problem who are suffering acutely.
I mean, what can they spend it on? I can think of servers and bandwidth (but they're pretty cheap these days, except for youtube-content intensive), and staff (but what would they do?) and perhaps advertising and publicity in general can absorb as much money as you can throw. I guess a professional sales force would be expensive.
To save that $100,000 in a year, working 6 hrs per weekday and 8 hrs per weekend day (impossible to keep up) is 6x5+8x2=46 hours pw = 2,392 pa. You'd need to take home $41.8 ph (after tax).
It's theoretically doable.
I have to break down complex problems in order to come up with questions that I can understand. The really hard part is in finding the right way to break them down, because not all modularities and boundaries between them will help to solve the problem. But all of this properly forms part of Feynman's step one, of writing down the problem.
I also often get a sense of what the answer should be - but it's very difficult to even begin to describe it in words, let alone define it clearly, and even harder to prove it is correct. Yet... it almost always is correct. This is properly in Feynman's steps two and three.
Computers are useless. They can only give you answers - Picasso
It is by logic that we prove, but by intuition we discover - Poincaré
and so another, even bigger, computer had to be built to find out what the actual question was - Douglas Adams
My history shows 5 pages from the landing page before I found one that said what CouchDB is (the faq), and I'm still not sure what distinguishes it.
btw: awesome logo and poster.
There's a jurisprudential idea that people don't obey the law only out of the goodness of their heart, nor out of an economically assessed fear of sanctions, but of a "habit of obedience". This (to me) seems related to the pecking order instinct. http://en.wikipedia.org/wiki/Jurisprudence#Bentham_and_Austi...
Fairy tales (for young and therefore impressionable children) have a strong theme of people being born to a certain role. And the idea appeals to children.
The belief that you can improve is a revolutionary, subversive and dangerous idea.
btw: keep the paragraph - pimp your stuff by all means - and (eg) a simple bar <hr> would separate it; that's how 37signals and Joel do it (of course, maybe it's just me who was distracted by it). While it is very effective advertising to integrate it into the story (a kind of product placement), it's harder to do both well than focus 100% on the content.
I think it's a good idea to promote your product with interesting/educational content... though there is nothing to differentiate the pitch from the content here (it's heading towards "advertorial"); and 37signals do this all the time without needing to mix the two.
But it also makes me question the whole post - did it exist purely for the purpose of carrying a sales pitch? And on reflection, I do find the content a bit lacking: "perhaps the language is too verbose" was interesting; and it seems very true that Ruby is used for small projects, and .Net are used for enterprise-size projects; but his conclusion, that "the resulting code is going to be verbose" doesn't connect to the question, which was about the language being too verbose.
A way to connect them is that huge projects have more names, and so you need longer variable/method/class names to distinguish them (I'm including namespaces in name length here); and in huge projects, you need names that are more self-descriptive (because it is so important than someone else will be able to understand it, someone who might not ever get to meet you to ask you) - and self-descriptive names are long. You'd like to reuse this full information without the typing. Hence, intellisense.
Douglas Adams' version of Hoare's make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.:
their fundamental design flaws are completely hidden by their superficial design flaws. http://www.otostopcu.org/yazi/h2g2/b4c36.php
One approach is to not expect to have customer-based competitive advantage at the start, but have a plan of how to get there. Eg. a product that has network effects + a plan for how to get there.
I think the idea of enduring or sustainable competitive advantage is a bit misleading, because things always change, so competitive advantage is dynamic. It can be more helpful to in terms of the duration of a competitive advantage. For example, when you start off with an easy-to-copy product that is in demand, you do have a competitive advantage - it's just that it doesn't last long. But you can use that brief period to build the next competitive advantage. (in rock climbing, a dynamic move is when you are not statically supported, but rely on your momentum to reach a stable point).
(1). New technology that you have developed secretly and roadmapped into the future (so that as your previous release is copied, you are ready to release the next one). Of course, those developments must also be needed by customers (eg. enhance an attribute that they care about; meaning that the initial release was lacking in this aspect, yet it still had some core value that made it worth buying). It's a bit like having your own private giant upon whose shoulders to stand. Because you've done the experiments, you've seen more. You do more experiments, and see more again. This is keeping ahead of the engineering curve, and so it's a supply-side advantage.
(2). Customers that have developed a habit of using your product, especially if they have changed their behaviour in order to adopt it (they might have done so because you were the only one to offer the technology, and then being the one with the best technology - due to point 1). This is related to switching costs. Demand side.
(3). Related to point 2 is when you not just have customers, but you are recognized as the leader, because you have dominant market share (here's where it's an advantage to focus on a niche: it's easier to dominate a small pond that a big one). Psychologically, people like winners. It also means that you win all sorts of races, where people have to make a choice: third-parties choose to support you; big companies choose to standardize on you; users choose to train for your product. Demand side.
(4). Network effects! Again with the customers, but here, because of interaction between customers, the value of the product is proportional to the square of the number of customers. This makes it harder to stop you, but you first need to be ahead - so it's more of a multiplier than a CA in itself. Demand side.
(5). Feedback. Once you have customers, you get feedback from them, and you can improve. If you can get this feedback before your competitors (eg. by launching before them), it can help you keep ahead. It's a kind of secret information, as you learn about what the market really wants; and it's also specialized to your product. In these senses, it is proprietary (owned by you). Another private giant. Supply side.
(6). Revenue. Once you have money coming in, it's a kind of magic, because you can reinvest and grow. Smaller competitors can't match this (assuming you can spend the money in ways that make a difference - like advertising - but it can be surprisingly difficult to find such ways...) And even large companies don't want to bother competing with you, once you really get going (they might buy you though). Supply side.
(7). Although particular skills can help, there's always someone smarter, more experienced etc. However, I like to think that a particular combination of skills can approach a hard-to-replicate advantage (though of course it has to make a difference to the start up. It's no good being an art-expert + TCL programmer unless that's somehow needed).
(8). There are also milder ones like good PR (a kind of advertising), being attractive to talented workers (which in turn increase your success), being inspirational (more advertising).
I agree about patents. They're a good piece of paper as a bargaining chip in acquisitions.
Now, the difficult thing for me is to apply these abstract ideas to my own actual startup (it's easier to be wise when you're not involved). They all seem to point to agility and getting your product out there now. Scary.
tschild's two comments here summarize my thinking: http://boards.straightdope.com/sdmb/showthread.php?t=257389#...
I did find it distracting, because (to be frank) people don't like to be told what they should be doing; laughter is a way to defuse the affront. Another approach is to appeal to those (few) people who are keen to learn about techniques that will help them. And I really think that that's what you were going for. Changing the wording would help achieve that aim, in my opinion.
So... yes.
btw: I really liked your explanation of linked lists being cheap to modify; and the article in general is very well done and communicates very effectively - I'd say it's of textbook standard.