Feature Development and Traffic Growth at Justin.tv(blog.justin.tv)
blog.justin.tv
Feature Development and Traffic Growth at Justin.tv
http://blog.justin.tv/2008/03/feature-development-at-justintv.html
8 comments
Looks like they are hiring: http://news.ycombinator.com/jobs
Yes we are. Feel free to contact me ([email protected]) if you are interested, or if you have any questions.
It sounds like agile, but really, is putting 12 bazillions features on a website a agile thing ? Agile is a company-level thing, not a development team matter.
Look at this : http://www.justin.tv/ it feels like clutter to me. I suppose that they wish that putting "features" by the dozen will help them getting more users, but I think when your users start to wonder "where do I click next ?" or "what do they want me to focus on ?" ; You are not on the good tracks.
Like soccer : stop for a second, raise your head, look around, if you run fast with your head down, you'll end in the corner.
Look at this : http://www.justin.tv/ it feels like clutter to me. I suppose that they wish that putting "features" by the dozen will help them getting more users, but I think when your users start to wonder "where do I click next ?" or "what do they want me to focus on ?" ; You are not on the good tracks.
Like soccer : stop for a second, raise your head, look around, if you run fast with your head down, you'll end in the corner.
Working with actual paying customers on another system I found they liked new features even if the new feature took an hour to develop. I believe the reason is that they felt like they were paying for something when new things were being developed often.
There were times when we didn't develop a new feature in an extended period of time (6 months) and people would just jump ship. They had more then enough features, 7 years worth of development but still if they didn't get there dose of a new feature every once and awhile they were as good as unsubscribed.
There were times when we didn't develop a new feature in an extended period of time (6 months) and people would just jump ship. They had more then enough features, 7 years worth of development but still if they didn't get there dose of a new feature every once and awhile they were as good as unsubscribed.
Have you seen myspace.com? It's proof that clutter isn't the problem tech people think it is.
See http://andrewchen.typepad.com/andrew_chens_blog/2007/11/do-y... for more in depth coverage of the same idea.
See http://andrewchen.typepad.com/andrew_chens_blog/2007/11/do-y... for more in depth coverage of the same idea.
ok, maybe I'm not the guy to sell average product to average people then.
So this is a proof that agile can be applied to average products for average users.
So this is a proof that agile can be applied to average products for average users.
in contrast I'd say, I observed other similar sites copying justin.tv frontpage.
nice post Mike. think having a regular release day is a great idea. well done.
Wow that guy who made Justin.tv must be really sexy!
Sounds like Agile to me.
We don't share much with "agile development" except a rapid development cycle.
"Agile development" things we don't do do (from the wikipedia article):
Exhaustive unit and integration testing - our testing is sparse and only for things that need it worst
Close, daily cooperation between business people and developers - getting business people involved in day to day development is horrible, at least in our experience
Even late changes in requirements are welcomed - we don't really have "requirements"
Face-to-face conversation is the best form of communication - face to face communication is essential, but it's not the "best form of communication". It's extremely costly in comparison to email.
Although we are "agile" in the following ways, they seem so self-evident that it's difficult to think anyone would ever admit they don't follow them:
Customer satisfaction by rapid, continuous delivery of useful software - vs. slow, halting delivery of useless software?
Working software is delivered frequently (weeks rather than months) - this we do, and it's good advice. Small things we'll even do on an hourly, or minutely basis.
Working software is the principal measure of progress - broken software or nonsoftware is the measure of progress?
Projects are built around motivated individuals, who should be trusted - projects are built around commitees who can't be trusted?
Continuous attention to technical excellence and good design - no attention to technical excellence or design?
Simplicity - complexity?
Self-organizing teams - top-down organized teams? unorganized?
Regular adaptation to changing circumstances - rare adaptation to changing circumstances?
"Agile development" things we don't do do (from the wikipedia article):
Exhaustive unit and integration testing - our testing is sparse and only for things that need it worst
Close, daily cooperation between business people and developers - getting business people involved in day to day development is horrible, at least in our experience
Even late changes in requirements are welcomed - we don't really have "requirements"
Face-to-face conversation is the best form of communication - face to face communication is essential, but it's not the "best form of communication". It's extremely costly in comparison to email.
Although we are "agile" in the following ways, they seem so self-evident that it's difficult to think anyone would ever admit they don't follow them:
Customer satisfaction by rapid, continuous delivery of useful software - vs. slow, halting delivery of useless software?
Working software is delivered frequently (weeks rather than months) - this we do, and it's good advice. Small things we'll even do on an hourly, or minutely basis.
Working software is the principal measure of progress - broken software or nonsoftware is the measure of progress?
Projects are built around motivated individuals, who should be trusted - projects are built around commitees who can't be trusted?
Continuous attention to technical excellence and good design - no attention to technical excellence or design?
Simplicity - complexity?
Self-organizing teams - top-down organized teams? unorganized?
Regular adaptation to changing circumstances - rare adaptation to changing circumstances?
Exhaustive unit and integration testing - our testing is sparse and only for things that need it worst
Agreed, and I don't think we suffer for it.
Something we do that has a bigger bang-for-buck imho is a lot of monitoring. Just about every one of our live systems gets automatically and regularly tested to make sure it's always working. I sleep better for knowing this.
Agreed, and I don't think we suffer for it.
Something we do that has a bigger bang-for-buck imho is a lot of monitoring. Just about every one of our live systems gets automatically and regularly tested to make sure it's always working. I sleep better for knowing this.
Is this why Hacker TV falls on a Thursday? (Testing day)
That's just a coincidence - we started Hacker TV before we settled into this weekly cycle.
Hmmn, maybe Daily Standups are a Scrum thing? I can never keep the various sects straight.
That and last-minute release planning (the Product Backlog).
That and last-minute release planning (the Product Backlog).
They don't belong to anyone, just consider it a good habit that may or may not work for you.
The rhythm method for development. Sounds great, will try.
I love the justin.tvs, its awesome.
justin.tv is the best :)