No one, actually it's the character limit for the title. :)
I didnt mean to be hostile or disrespectful. I just believe that they need some more time in the evolution process, make the app better and then ask for feedback, which at that time more likely to produce more meaningful feedback from the community...
Why not? If it's fun and harms no one, I don't see why one shouldn't create "small useless apps" in her spare time. If anything, you should pat folks like that on the back for trying new things (assuming they're new to the person making them).
I am actually, the issue here is not that i don't like these projects, but i cannot give meaningful feedback on them... When you develop any sufficiently big project, most of the assumptions and specifications change over time. This is evolution. And what i criticise is, whether it is a good idea to show a half-baked app and make people think that it is useless. I believe waiting a bit more and developing the app and then posting it makes more sense. For all the learning practices, i agree it is very valuable experience, but just let them evolve...
One could argue that Twitter is a 'useless' app that realistically could have been prototyped over a weekend. I'm not arguing whether it is or isn't, but it's certainly popular.
My favorite 'weekend' app of the moment is Word Wars[1], which happened to be built during a hackathon.
I'm putting the finishing touches on "By A Bus", which is a source code escrow service activated by a dead man's switch that I started tinkering with yesterday, after reading this HN thread: http://news.ycombinator.com/item?id=3990761
Why am I doing it? I thought it would be a fairly easy thing that could be knocked out pretty quickly that would solve the problem of what happens to source code when their developers die. Source code escrow services are complicated and expensive, but with "By A Bus", you can just choose to escrow your Github-hosted source code so that if you die, all (or some of) your private repositories can be open sourced, or 'willed' to other open source contributors to take care of.
It is useless? Well, now it certainly is, and even after it launches, it might still be except to a small percentage of developers. I'll have learned a little more about the dotcloud infrastructure when it's done, and learned the GitHub v3 REST API, which I'd never touched before.
This kind of experience isn't exactly groundbreaking, but the more little things I can touch, the better off overall I am to be able to handle new things that I haven't seen before, or figure out how 'thing a' will interact with 'thing b'.
Most importantly though, small things can grow to be bigger things. Twitter wasn't exactly the hyper-mega trending analytics engine it is today when it first launched, but it grew into that as its creators realized how people were using it. Google started out as a search engine, and is now one of the biggest companies in the world. The best ideas start from small beginnings, and I'd much rather have a small project that a few hundred people like than a Facebook-sized project that nobody does, and I'll have wasted a lot less time in getting there.
Don't get me wrong, the title is put together because of the character limit. I truly appreciate and like the idea of putting together bootstrapped apps, i work for one of those ideas going into maturity, but then don't you think you lose one silver bullet you have. Other people's feedback is important, especially on HN, so i was thinking of using it wisely and show them a developed feature-set, at least some level of maturity. I am sure, twitter's thing is not the idea of micro blogging and following and such, but rather the feature set they have put together and served and scaled for the long time they are alive. Otherwise competition would crush them, remember Google Buzz...
They exist NOW because of their extended feature set, and that they were able to monetize all the data they found that they had access to.
They existed originally because they had a dirt-simple microblogging application that people liked. If they had spent a year developing it and people didn't like it, they would have wasted that year.
The goal of an MVP is to do exactly what you say is so valuable -- get customer feedback. If you're solving a problem that people have, it doesn't matter if your application is ugly or has all the features it might have a year from now -- it only matters that it exist in whatever minimal form it can exist in that solves that problem.
If you wanted to compete with Twitter, then yes, you'd have to release a better product. But then, you're not building an MVP. You're not 'testing the market'. The point of an MVP is to see whether or not people even want it. To see if you're actually solving a problem. To see if anyone will pay for it. If you're testing out a truly new idea, then that's what you need -- to get it in front of customers ASAP to find out if anyone is willing to pay for or use your app at all.
Dropbox started out with just a video[1]. No working product whatsoever. He figured if he could show people what his software aimed to do, then he could find out if they'd pay for it. The alternative was to spend a year or two building a product that he couldn't sell. Why waste a year of his life?
well, my intention was asking why such small things,
i think mvp is overrated, people can put together a meaningful set of features and produce a real product, probably not in a weekend but in a month or two or six... then it makes more sense for the audience to check the featureset and give more meaningful feedback. That's my opinion at least. Don't get me wrong, i appreciate and support all the efforts by these bright people, but...
15 comments
[ 3.2 ms ] story [ 46.5 ms ] threadThis is, however, the first time it's been possible to get such wide visibility of these kinds of projects thanks to HN and the rest of the Internet.
Try it sometime. It's fun.
One could argue that Twitter is a 'useless' app that realistically could have been prototyped over a weekend. I'm not arguing whether it is or isn't, but it's certainly popular.
My favorite 'weekend' app of the moment is Word Wars[1], which happened to be built during a hackathon.
I'm putting the finishing touches on "By A Bus", which is a source code escrow service activated by a dead man's switch that I started tinkering with yesterday, after reading this HN thread: http://news.ycombinator.com/item?id=3990761
Why am I doing it? I thought it would be a fairly easy thing that could be knocked out pretty quickly that would solve the problem of what happens to source code when their developers die. Source code escrow services are complicated and expensive, but with "By A Bus", you can just choose to escrow your Github-hosted source code so that if you die, all (or some of) your private repositories can be open sourced, or 'willed' to other open source contributors to take care of.
It is useless? Well, now it certainly is, and even after it launches, it might still be except to a small percentage of developers. I'll have learned a little more about the dotcloud infrastructure when it's done, and learned the GitHub v3 REST API, which I'd never touched before.
This kind of experience isn't exactly groundbreaking, but the more little things I can touch, the better off overall I am to be able to handle new things that I haven't seen before, or figure out how 'thing a' will interact with 'thing b'.
Most importantly though, small things can grow to be bigger things. Twitter wasn't exactly the hyper-mega trending analytics engine it is today when it first launched, but it grew into that as its creators realized how people were using it. Google started out as a search engine, and is now one of the biggest companies in the world. The best ideas start from small beginnings, and I'd much rather have a small project that a few hundred people like than a Facebook-sized project that nobody does, and I'll have wasted a lot less time in getting there.
[1] - http://wordwars.clay.io
They existed originally because they had a dirt-simple microblogging application that people liked. If they had spent a year developing it and people didn't like it, they would have wasted that year.
The goal of an MVP is to do exactly what you say is so valuable -- get customer feedback. If you're solving a problem that people have, it doesn't matter if your application is ugly or has all the features it might have a year from now -- it only matters that it exist in whatever minimal form it can exist in that solves that problem.
If you wanted to compete with Twitter, then yes, you'd have to release a better product. But then, you're not building an MVP. You're not 'testing the market'. The point of an MVP is to see whether or not people even want it. To see if you're actually solving a problem. To see if anyone will pay for it. If you're testing out a truly new idea, then that's what you need -- to get it in front of customers ASAP to find out if anyone is willing to pay for or use your app at all.
Dropbox started out with just a video[1]. No working product whatsoever. He figured if he could show people what his software aimed to do, then he could find out if they'd pay for it. The alternative was to spend a year or two building a product that he couldn't sell. Why waste a year of his life?
[1] - http://youtu.be/7QmCUDHpNzE