Some links on tech start-ups I found interesting
Wednesday, November 25th, 2009 12:21 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
charmianThese don't directly have to do with social media, but apply to internet businesses in general.
1. On how start-ups shouldn't be over-ambitious at the beginning: The basic message is that start-ups shouldn't play to their weaknesses, and realize that being small and having no customers confers some advantages.
Quote: "When I see start-ups looking to go toe-to-toe with established multi-million dollar businesses, I think “wow, that’s courageous.” When I see that they want to take them on at their own game, feature by feature, product by product, price by price, I worry a lot for their future. Playing to your weaknesses in a head-on competition is a surefire way to destroy yourself."
Commenters on Garry Tan's post quoting this one seem to disagree on some points, though.
2. On Product Design Debt vs. Technical Debt
Technical debt is not defined in the article itself, but in one of the links, is defined as "the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term." Such debt may be taken on intentionally or unintentionally.
Although technical debt is not really like actual, money debt, it does create problems for a company: "If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too. "
However, some argue that technical debt has a positive side.
There's also the concept of "technical inflation," which is defined as: "the ground lost when the current level of technology surpasses that of the foundation of your product to the extent that it begins losing compatibility with the industry. Examples of this would be falling behind in versions of a language to the point where your code is no longer compatible with main stream compilers."
Anyway, back to Andrew Chen's post: he posits another sort of debt which he calls "product design debt," which occurs when people create features and don't really put them in the UI in a tested way. Eventually, as more features are created, they get shoved into the webpage/UI, and it ends up looking like the Las Vegas strip. The navigation fails to scale up.
He's also written an interesting post about clutter in social media sites: he argues that these sites tend towards clutter because the users demand more features.
Sites seem to deal with this in various ways, he says. Some of the major ones: a) creating everything (leading to tons of clutter, as designers try to figure out how to smush everything into the site, a la Myspace), b) opening up the CSS/HTML layer (allow people to put in whatever widgets they want. Myspace, and also Tumblr) c) creating an open platform (a la Facebook, and Ning), d) allowing users to do offsite stuff with your API (Twitter), and e) ignore demands of users, focus on core features.
Personally, I prefer open CSS/HTML or open platform options. I can manage simple CSS and HTML, so I like the idea of being able to go under the hood and add what I need. Open platforms are also good because you can use all kinds of novel apps, allowing a lot of flexibility.
1. On how start-ups shouldn't be over-ambitious at the beginning: The basic message is that start-ups shouldn't play to their weaknesses, and realize that being small and having no customers confers some advantages.
Quote: "When I see start-ups looking to go toe-to-toe with established multi-million dollar businesses, I think “wow, that’s courageous.” When I see that they want to take them on at their own game, feature by feature, product by product, price by price, I worry a lot for their future. Playing to your weaknesses in a head-on competition is a surefire way to destroy yourself."
Commenters on Garry Tan's post quoting this one seem to disagree on some points, though.
2. On Product Design Debt vs. Technical Debt
Technical debt is not defined in the article itself, but in one of the links, is defined as "the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term." Such debt may be taken on intentionally or unintentionally.
Although technical debt is not really like actual, money debt, it does create problems for a company: "If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too. "
However, some argue that technical debt has a positive side.
There's also the concept of "technical inflation," which is defined as: "the ground lost when the current level of technology surpasses that of the foundation of your product to the extent that it begins losing compatibility with the industry. Examples of this would be falling behind in versions of a language to the point where your code is no longer compatible with main stream compilers."
Anyway, back to Andrew Chen's post: he posits another sort of debt which he calls "product design debt," which occurs when people create features and don't really put them in the UI in a tested way. Eventually, as more features are created, they get shoved into the webpage/UI, and it ends up looking like the Las Vegas strip. The navigation fails to scale up.
He's also written an interesting post about clutter in social media sites: he argues that these sites tend towards clutter because the users demand more features.
Sites seem to deal with this in various ways, he says. Some of the major ones: a) creating everything (leading to tons of clutter, as designers try to figure out how to smush everything into the site, a la Myspace), b) opening up the CSS/HTML layer (allow people to put in whatever widgets they want. Myspace, and also Tumblr) c) creating an open platform (a la Facebook, and Ning), d) allowing users to do offsite stuff with your API (Twitter), and e) ignore demands of users, focus on core features.
Personally, I prefer open CSS/HTML or open platform options. I can manage simple CSS and HTML, so I like the idea of being able to go under the hood and add what I need. Open platforms are also good because you can use all kinds of novel apps, allowing a lot of flexibility.
no subject
Date: 2009-11-26 01:13 am (UTC)no subject
Date: 2009-11-26 03:26 am (UTC)no subject
Date: 2009-12-03 08:44 pm (UTC)no subject
Date: 2009-12-03 08:45 pm (UTC)