A Commuting Principle That Shaped Urban History - <AUTHOR> https://www.citylab.com/transportation/2019/08/commute-time-city-size-transportation-urban-planning-history/597055/ <comment><USER2> Overall I liked this article. It describes an interesting though simple core principle. I have three criticisms:

1\. The article is scientific enough that using "grew exponentially" in the colloquial sense of just "grew a lot" is grating.

2\. The article gives the impression that Boston is an American city on a grid where elevated trains preceded subways and dominated the transportation system. In reality the core of the city was not at all a grid, subways came first, and subways have been more prevalent than elevated trains.

3\. "the vaunted self-driving car, as imminent and yet illusory as nuclear fusion, will not transform the basic geometry of road capacity" This ignores the potential drastic reduction of space allocated for parking, including space that is already part of roadways.

<comment><USER3> > This ignores the potential drastic reduction of space allocated for parking

How so? If you mean because of more car sharing, I don't think that's going to happen. Most people would still want their own car. If you mean because of being able to let the car park itself outside the city, or even drive home: That would drive up cost for the owner and reduce convenience (having to "order" it 30 minutes ahead of time). In addition, it would worsen congestion on streets due to cars moving more.

<comment><USER4> I can imagine NYC with 1/10th the private cars and 4x the shared/rental/taxi cars, and traffic flowing much better than today owing to the additional bandwidth freed up by the 70-80% reduction in street-side parking space need.

NYC residents just might accept the trade-off.

<comment><USER5> As an NYC resident, I would much prefer to just have 1/10th the private cars, twice the number of trains (or whatever is necessary), and a massive reduction in the number of cars sitting around unused, with the resulting extra space being converted to green space, pedestrian-only areas, and bike lanes. Self- driving cars and the infrastructure they necessitate would make NYC more hostile to people, not less.

<comment><USER4> Train infrastructure is simply not economical by comparison to buses. You could have a bus system as good as, say, Buenos Aires, if you were willing to let it be run by the private sector. Cars are not entirely replaceable by trains and buses. But if you replace N privately-owned, mostly unused cars with N/10 privately-owned _shared_/rental/taxi cars whose utilization is much more than 10x that of the average privately-owned non-shared/rental/taxi car in the city, then you win big even if you also improve buses and even trains.

<comment><USER5> I would be happy with more buses or trams or any other kind of mass transit option. As long as the space taken up by private cars is drastically reduced and the resulting space repurposed for actual public use. Public space is currently completely wasted by being disproportionately allocated for cars, many of them completely unused and taking up space for free.

Buses and trains may not completely serve all the needs which cars can, but almost all of the remaining transit needs can be easily taken care of by bicycles, which should also be a much higher priority in the city. Either way, it really is a no-brainer that we must de-prioritise cars.

</comment></comment></comment></comment></comment></comment><comment><USER6> > _The best option is to densify our cities. This is hard, too_

Leveling off or lowering the human population through lower birth rates works better. I'm not saying it's simple or even possible since so many people jump to conclusions about eugenics etc, but reducing overpopulation makes a lot of problems easier. If we don't figure out how on our own, nature will do it for us so we might as well figure out how in a peaceful, fair way.

<comment><USER7> Whether we like it or not, it's already happening. [https://ourworldindata.org/uploads/2019/06/2019-Revision-%E2...](https://ourworldindata.org/uploads/2019/06/2019-Revision-%E2%80%93-World- Population-Growth-1700-2100.png)

But this doesn't really solve the city/urban problem as the vast majority of economic growth occurs in cities and the continual migration of rural to urban happens even when total population is shrinking.

<comment><USER6> That chart shows a positive growth rate beyond 2100, which means continued exponential growth, not a decreasing population.

Lowering population _alone_ doesn't solve every problem, but without it, many problems are unsolvable.

</comment></comment></comment><comment><USER8> Except that people didn't used to "commute" in the modern sense: many craftsmen worked from home, and large numbers were domestic servants.

There is probably some other principle at work, of which modern commuting is a special case.

<comment><USER9> While that may be true, I think it doesn't change the traffic factor much: "home office" users still need to sell their wares (their clientele must be able their house) or they need access to a local market. Similarly, people need market access to buy groceries and such.

The typical "commuters" in those days were probably farmers, who traveled from outside to the city markets. But that wasn't a daily commute, probably once or twice a week.

</comment></comment><comment><USER10> > the vaunted self-driving car, as imminent and yet illusory as nuclear > fusion, will not transform the basic geometry of road capacity

I'm not so sure about this. I've generally been someone with a lower tolerance for a long commute than the average person. Usually I've lived within a 20 minutes walk from my job. My wife and I have had flatmates for 4 out of our 5 years or marriage. I decided 2½ months ago that it was worth moving farther out in order for my wife and I to get more privacy. A big reason for this was that a friend who lived in the area told me that he usually got a seat on the line into central London. Indeed, having figured out an ethical way to _always_ get a seat, my commute is significantly improved by my newfound ability to get into a writing habit.

If driverless cars or driverless double-decker busses become widely available and many people have the ability to get one-shot commutes, then I suspect that more people will ride them.

</comment><comment><USER11> This agrees with my experience. I grew up in the centre of Madrid and I would always estimate around 30 minutes to get to any other part of the city by public transport.

<comment><USER12> 30 minutes from the centre of Melbourne doesn't get you all very far by public transport (or by car most of the time either). It's pretty sprawling.

</comment></comment><comment><USER13> For a while, I have occasionally considered the idea of turning the shopping mall inside-out. Rather than one building in the center, with a vast expanse of parking lot all around the perimeter, put the parking structure (and auto- service businesses) in the center, and place the shopping, offices, and restaurants around the edges. Then use elevators and horizontal transport systems to move people around quickly without needing their cars. Access from the outside would be by pickup/dropoff cars, public transport, and pedestrians, and building facades would be immediately adjacent to the street.

I don't think you can go straight from an everyone-in-a-car culture to a walkable+public transit culture in one step. So first you get people to put their cars in places that are less in the way, by driving _past_ their destination and parking _on the other side of it_ from the main transit network connections. This allows things to be closer together for pedestrians and the vehicles that do not park.

Imagine the degenerate case, where a worker in an office park wants to visit a store in the mall next door. When the office is surrounded by parking, and the mall is surrounded by parking, a direct walk requires traversal of two large parking lots, and the worker has an incentive to drive, from a parking space near their entrance to the office building, to a parking space near the mall entrance nearest their store. Turning the shops and offices inside-out, in the best case, puts the office and the shop directly across the street from one another, and the worker can cross on a pedestrian overpass faster than they can reach their car. In the worst case, the worker rides two ring-avators and two elevators, once to get to an office-mall adjacency point, down to street level, walk across, back up, and then ringwise again to get to the shop. To drive, the worker would have to walk into parking to reach their car, drive out to the exit, drive in to the mall parking, and walk out again to the shop. That's not entirely eliminated, and would likely occur when the offic and mall are further separated, but it does make walking directly slightly more attractive.

</comment><comment><USER14> I liked the article, but I did wonder if the author understood what self- driving vehicles would allow for, providing that they had maybe 7-8 nines in reliability and safety (if that is even possible).

People have already mentioned the idea of "sending the car back home to park" and "being able to do something else in the car while commuting". But there are other things the cars could do:

1\. Trains of cars - convoys - drafting each other, reducing energy use, while also increasing road density (bumper-to-bumper traffic - but at highway speeds).

2\. No more "traffic waves" on the freeway, nor "rubber necking" at accidents, both of which likely contribute to the congestion issue.

3\. No-stop intersections - again at high-speeds - because cars could coordinate/negotiate their speeds and lanes to allow for "collision-free" operation (unfortunately, there will still probably be collisions - and they wouldn't be pretty).

All of these options - and possibly others I haven't thought of - rely on things that self-driving vehicles don't yet have - mainly car-to-car communication - so all cars know where other cars are (even if they aren't within sight-lines of the sensors) and how fast they are moving. Basically a form of swarm robotics, with constraints on motion vectors.

Of course, #3 (and maybe the other two) might not come about unless the chance of an accident drops to infinitesimally small values - perhaps it may not even be possible. Better safety systems for the occupants would likely need to be developed as well (for that "impossible" chance it would be needed). Such cars might also need to be "trained" on "how to crash to protect occupants" and/or how to coordinate a collision with another vehicle(s) in real-time as the collision unfolds, to minimize occupant danger - this again, would require a standardized mesh network and coding to be able to take advantage of all the sensor data that would flood in (and out - as sensors and actuators become disabled by the accident unfolding - maybe the other cars involved - or not involved - could share their information "from the outside" to allow the disabled car to take better actions or whatnot). It's actually a fascinating problem when I think about it - extremely complex, lots of parameters and such; I wonder if anyone is working on it? If not - they should...

<comment><USER15> The answer is to park 20 feet in the air. When self driving is ready so will anti-gravity enhanced cars/trucks.

</comment></comment><comment><USER16> I'd love to build a large subdivision with the streets laid out in a fractal curve:

        _ _
        _|_

        |__ __|
        |  |  |
           +</comment><comment>----
        |__|__|
        |     |

        _ _     _ _
         |___ ___|
        _|_  |  _|_
             |
             +</comment><comment></comment><comment>--
        _ _  |  _ _
         |___|___|
        _|_     _|_

         __ __       __ __
        |_ | _|     |_ | _|
           |_____ _____|
         _ | _   |   _ | _
        |__|__|  |  |__|__|
                 |
                 +</comment><comment></comment><comment>====
         __ __   |   __ __
        |_ | _|  |  |_ | _|
           |_____|_____|
         _ | _       _ | _
        |__|__|     |__|__|

It would likely suck to live there, but the traffic patterns would be cool...

<comment><USER17> Sounds like a good game of Cities: Skylines, call it Hilbertville.

</comment></comment><comment><USER18> > We must make do mostly with building up and densifying the urban areas we > already have. As transportation goes, so go our cities.

If we make transportation better, our cities can be less dense. So can't we make transportation better?

What causes congestion? Car traffic. Why does car traffic cause congestion? It's an inefficient use of roads. What are some alternatives?

1) Build more roads. Sure, except it's expensive, time consuming, and you quickly run out of land, and would have to build them one on top of another.

2) Fit more people into existing roads. How? Buses, trolleys, trains, subways, vans. Build out the mass transit to the suburban enclaves.

But all this supposes an urban center is also the only answer. What do people need to congregate in one place for? Usually to work in one place. But why work in one place?

Due to division of labor, most of us don't do things with multiple completely different people on multiple completely different subjects; we're just not that collaborative. But you may need to transport _your work_ to another group in a company. At a bank, all this is paper; in a car manufacturing plant, this is car parts. The former is done digitally now, and the latter could be done, again, by increased transportation efficiency.

All the other things we use are already decentralized outside the city; schools, churches, supermarkets, health care, water, power, recreation. It's really just business, and the ability to work decentralized, that constricts where and how we live. Transportation will make it easier to decentralize. And we can start by giving up our cars.

The other aspect of work decentralization I've already seen at a rental car facility. A computerized kiosk displayed a remote worker on screen, who processed my driver's license, credit card and rental information and directed me to my rental car. It was surprisingly trouble-free and pleasant, and only one of us needed to be there.

<comment><USER19> There are many classes of jobs that you must be physically present for. You must be physically there to make food, to build, to repair, to be security, to treat patients, to drive a bus, to build a boat. Things walk off of shelves if you don't have employees manning checkout stations. These all legitimately require your physical presence.

<comment><USER18> A lot of those things are already automated. Machines that create pizzas, burgers, cocktails, robots that weld, security robots, remote medical care, driverless transportation.

The rental car place had people there... two to move cars and clean them, and one to sit in an exit booth to check IDs against contracts and lower the tire- ripping thing. But they didn't need three people idling behind desks waiting to process people's policies.

<comment><USER19> They are very rarely automated. And the jobs you don't need physical presence are outweighed by those you do, IMO.</comment></comment></comment></comment>


Einstein's Math May Be Compatible With Faster-Than-Light Travel - <AUTHOR> http://www.huffingtonpost.com/2012/10/10/einsteins-math-faster-than-light-travel_n_1951272.html

<comment><USER2> _as a spaceship traveling at super-light speeds accelerated faster and faster, it would lose more and more mass, until at infinite velocity, its mass became zero._

I remember the same theoretical considerations proposed when Tachyons were popular.

</comment><comment><USER3> Quantum theory is already nonlocal.</comment>


Complete novice to full-time product designer in 1-2 years - <AUTHOR> http://davemart.in/90k/ <comment><AUTHOR> This is my first time blogging in a while.

I'd love to hear your reactions. What would you do differently? What do you disagree with? I'd love to chat about it!</comment>


Silicon Valley: Abandoned - <AUTHOR> http://www.businessinsider.com/alaska-miller-silicon-valleys-ghost-towns-2009-10

<comment><USER3> Ostensibly, this is good as it means cheap office space.

There's a catch though... have any of you folks actually seen these buildings? They're not exactly in nice neighborhoods (I actually used to work next to one of these). Most of them are over the 101 which means it'll be a 15-20 minute drive to downtown for food. While it's true that Google is also past the 101, they can also afford to hire their own chefs. An apartment off of San Antonio/University/MenloAve/Castro/etc. seems preferable.

The other bit of trouble is that they're all large office buildings. Are they set up so that they can be rented out by a small shop? I'm pointing at the Yahoo campus buildings in particular.

<comment><USER4> "Ostensibly, this is good as it means cheap office space."

Cheap office space in a dying empire that smart people are increasingly leaving because its citizens are too shortsighted to realize their economy will collapse if they don't pay for what they've purchased, too racist to let in the next generation of innovators, too stupid to educate their own kids, and too apathetic to fix the problem.

Cap-and-trade is probably the last chance to fix the economy of the valley, and frankly it's not looking good right now.

<comment><USER5> The Valley will not soon be displaced and will do just fine in spite of the larger economic problems - nowhere else in the world will one find such an aggregation of talented entrepreneurs, monied investors, academic expertise, and, above all, critical relationships with those who know startups well and are integrally involved in launching and promoting them.

With every cycle (I have seen them all), the Valley takes new shape in its economic drivers, and it will likely do so again this time around. But the tech revolution has fundamentally changed world commerce and is not about to slow down. The Valley remains its epicenter, in spite of any bleak short-term issues.

Early-stage startups (my area of specialty) have not slowed but rather increased in the past year, and their quality is up (very often driven by immigrants or first-generation children of immigrants - _this_ is a big change from 25 years ago). The venture-backed part of the startup world has been on hold and will largely remain so for the time being. In time, it too will emerge again, but this will depend on an eventual opening up of the IPO market.

The Valley will survive and emerge stronger than ever, in my view. Opportunities for those seeking to launch new startups are as good as they ever have been (and office space is cheap and plentiful, and certainly not just in large office buildings but everywhere).

<comment><USER4> "The Valley will not soon be displaced and will do just fine in spite of the larger economic problems"

Which seems more likely in twenty years:

A) The CA/US debt, education, and political problems will be fixed

B) In the near future Boris Johnson or some other politician who 'gets it' is able to convince their government to pass a series of bills that create the same economic/social conditions that created SV, and over the next twenty years this new area catches up to and surpasses SV despite SV's current massive advantage.

As for education, IIRC it was one of the top three issues for every presidential election between 1964 and 2000 and virtually nothing changed. For the past two election cycles it hasn't even been one of the top five issues, and there's no evidence that it's coming back in 2012. The fact is that the vast majority of CA/USians can't read English proficiently, that is well enough to compare and contrast the viewpoints in two different newspaper articles. This means the vast majority of our population is completely useless in the modern economy. Not only are we making zero progress toward fixing this, but there is zero will to fix it. And even in the past when there was tons of will to fix it, it still proved unfixable.

As for the CA/US debt, the vast majority of citizens STRONGLY support increasing the debt. A black-gay-atheist would have a better chance at winning the south in the 50s than a presidential candidate who supports the kind of tax increases needed to fix the debt.

As for our other political problems, our policies are completely based around made-for-TV soundbites and not academic research. That's why our infrastructure is crumbling, we support torture, we're destroying the value of the dollar, etc. And I see zero sign of this changing.

As much as I love SV-- and I still intend on moving there-- let's face the facts, the chances of someplace else catching up to SV are vastly better than the chances of fixing the problems facing the US.

<comment><USER6> Silicon Valley is more than 100 years old. I blogged about this in [http://www.skmurphy.com/blog/2008/11/05/steve-blank-on- secre...](http://www.skmurphy.com/blog/2008/11/05/steve-blank-on-secret- history-of-silicon-valley-at-chm-nov-20/) but here is one quick data point:

 _California Landmark NO. 836 PIONEER ELECTRONICS RESEARCH LABORATORY - <USER2> is the original site of the laboratory and factory of Federal Telegraph Company, founded in 1909 by Cyril F. Elwell. Here, Dr. Lee de Forest, inventor of the three-element radio vacuum tube, devised the first vacuum tube amplifier and oscillator in 1911-13. Worldwide developments based on this research led to modern radio communication, television, and the electronics age. Location: In sidewalk, SE corner of Channing Ave and Emerson St, Palo Alto_

Radio technologies preceded and prepared the way for electronics and semiconductors, and it was fueled with risk capital.

<comment><USER7> That is a somewhat misleading claim. Whatever area had turned out to be the center of the semiconductor industry, there would presumably have been some electronics firms there already.

<comment><USER6> My argument is not that Silicon Valley was inevitable but that it takes a long time to grow an entrepreneurial region.

It's not misleading in raising the bar to areas/regions that want to be the next Silicon Valley and don't have an entrepreneurial substrate and appropriate ancillary services (e.g. attorneys, accountants, banks, that understand startups and entrepreneurs) to form a viable ecosystem.

I don't think the 100 years is misleading, if it had happened somewhere else (e.g. Boston) I think it would still have involved the same antecedents: major universities, risk capital, electronics firms...It may also have been important that it was primarily agricultural land that was pushed aside, if there had been other active industries they may have preferentially competed for the same talent.

Three good books I rely on for this analysis are

"Understanding Silicon Valley" by Kenney [http://www.amazon.com/Understanding- Silicon-Valley-Entrepren...](http://www.amazon.com/Understanding-Silicon- Valley-Entrepreneurial-Stanford/dp/0804737347)

"The Silicon Valley Edge" by Lee, Miller, Hancock, and Rowen [http://www.amazon.com/Silicon-Valley-Edge-Innovation- Entrepr...](http://www.amazon.com/Silicon-Valley-Edge-Innovation- Entrepreneurship/dp/0804740631)

"Regional Advantage" Saxenian [http://www.amazon.com/Regional-Advantage- Culture-Competition...](http://www.amazon.com/Regional-Advantage-Culture- Competition-Silicon/dp/0674753402/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> High vacancy in a central location means cheap rents that facilitate face to face interaction. Perhaps there is room for a half dozen different kinds of co-working / hacker dojo spaces that can now afford to come into existence.

</comment><comment><USER8> I can't recommend <http://burbed.com> enough for people around here for some good perspective on Silicon Valley real estate.

<comment><USER9> The columns remind me of the let's-converge-to-the-classics-in-the-safest-way- possible-because-we-lack-guts-and-imagination in "The Fountainhead", by Ayn Rand.

</comment></comment><comment><USER10> Story Title: Linkbait

CRE sucks, but it sucks less in that area.

</comment><comment><USER11> Someone really should have proof-read these captions.</comment>


Why Free Plans Don't Work - <AUTHOR> http://www.softwarebyrob.com/2010/08/18/why-free-plans-dont-work/ <comment><USER2> I loved this article, but after thinking about it for a bit I realize that there _is_ an argument for going free. Two pretty strong ones, in fact.

1) If you want to get acquired - and we're talking about a big acquisition here - it would do to go free so you manage to score a big-enough user base to get noticed. And so the bigger company is interested in acquiring you not only for your technology, but also for your users. (That said, acquisition may be a risky bet.)

2) Going free also makes sense if you want total market dominance. In which case, free is really the only way to go. The writer is speaking from the POV of a micropreneur, and it makes sense for him to retract his free plan (in fact, it makes sense for 37signals/the 37signals model to do so too).

But if you're in the position of being the next Facebook, going free and dominating the market is really the best thing to do. (Or Youtube, or Google, or Flickr).

You find lots of users, lock out the competition, and _then_ you can figure out how to monetize.

Which only goes to show that there are all kinds of businesses out there, and the advice you read on the net really should be done through the context of your particular business and/or market.

<comment><USER3> _Going free also makes sense if you want total market dominance. In which case, free is really the only way to go._

No it's not. The other way is to make the best damn product in the market. I hate to give cliched examples, but since we are talking market dominance, see Windows, Adsense and iPod.

<comment><USER4> I can see iPod and Adsense, but Windows? Windows won for very, very different reasons. When Windows first appeared, it was far from the best product on the market. It won because it was already everywhere (because of DOS). Microsoft practically invented the "give it away to ensure market dominance" game (Ok, slight hyperbole there). It took the court system to slow them down.

<comment><USER3> What consumer OS on affordable computers (that leaves Macs out) was/is better than Windows?

 _It took the court system to slow them down._

That was not for their dominant desktop OS, it was for using their monopoly to push IE and server products.

You can call out Microsoft on dodgy anti-competitive behaviour in some respects, but you cannot take away credit for building the solid product that is Windows. Heck, even now after goofing up with Vista, they are back with Windows 7.

<comment><USER4> Windows won because DOS was already everywhere. It wasn't the best product. I would argue OS/2 and Macintosh were pretty significantly better. It's not a coincidence that it took this long (Windows 7) for MS to produce a decent operating system - they are now having to compete on quality. But you don't even have to buy the argument that Windows was sub-par. It doesn't matter, because that's not why MS won.

Just as MS used the omnipresent Windows platform to push Office, IE, and countless other products (with varying success) they used DOS to push Windows. _That_ is why Windows won.

There's nothing dodgy about it - the point is there is more than one way to win the market, and being the best product is pretty far down on the list.

<comment><USER3> Of course, Microsoft used DOS to push Windows and perhaps OS/2 was better in some ways, but the Wikipedia article suggests OS/2 lost because Windows was better in some important ways.

 _The collaboration between IBM and Microsoft unraveled in 1990, between the releases of Windows 3.0 and OS/2 1.3. Initially, at least publicly, Microsoft continued to insist the future belonged to OS/2. Steve Ballmer of Microsoft even took to calling OS/2 "Windows Plus".[9] However, during this time, Windows 3.0 became a tremendous success, selling millions of copies in its first year.[10] Much of its success was because Windows 3.0 (along with MS- DOS) was bundled with most new computers.[11] OS/2, on the other hand, was only available as an expensive stand-alone software package. In addition, OS/2 lacked device drivers for many common devices such as printers, particularly non-IBM hardware.[12] Windows, on the other hand, supported a much larger variety of hardware._

<http://en.wikipedia.org/wiki/OS/2>

The other question to consider is why another PC OS didn't come up to compete with DOS/Windows considering that Microsoft actually helped open up the hardware ecosystem. A dominant player with most of the "market share" need not stop a new better player (see web search). Maybe it's worth acknowledging that making a good OS is a hard problem which MS cracked better than the rest.

<comment><USER5> There were other PC DOS, but MS had something up their sleeve: [http://en.wikipedia.org/wiki/DR- DOS#Competition_from_Microso...](http://en.wikipedia.org/wiki/DR- DOS#Competition_from_Microsoft) and <http://en.wikipedia.org/wiki/AARD_code>

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I was just thinking this about Evernote the other day. I really want to pay them. They make a great product that serves me very well. I do believe they deserve my money. The problem is, the payed plan would be a complete waste for me. I don't need it. The free thing fulfills my needs perfectly. If it would be a 30 days trial, I would be a happily paying customer by now.

The same thing is true for dropbox for me. After the first month I was actively looking for a "donate" button on their website. I love the product, it works perfect, I would pay for it without thinking a second, I just have no need for the paid plan.

I understand the free plans are for marketing purposes. In my case I had more than 10 different choices for a note taking application, or a online backups system. The factor that pushed me towards Evernote and Dropbox were the consistent great reviews. Free was the cherry on top, but not the reason why I choose those two apps.

<comment><USER7> I'm not touching Evernote again until they get exporting features. It's a _really_ impressive, useful service, but despite their repeated claims of supporting open formats they've provided utterly squat in the past few years I've watched them.

 _Years_. More than enough time to write exporters (not even .txt / .rtf!) if they value it at all.

<comment><USER8> Sounds like a good freemium upsell to me.

<comment><USER7> I might actually go for it if that were the case. It'd have to be damn-good exporting, however - quite frankly, I don't trust them with my data, especially given their lack of export progress + claims. The company as a whole doesn't seem too trustworthy. I want a panic button.

<comment><USER9> I am very confused by this subthread. If you run the MacOS client, and you are a premium subscriber all your evernote data is locally available on your hard drive - it's unencrypted and easy to see and parse.

</comment></comment></comment></comment></comment><comment><USER10> Startups are too skiddish about charging. This shouldn't be novel or surprising, this is regular business 101.

Businesses charge money for useful products. People are used to paying for useful products.

The only difference is that the variable costs associated with hosting more users are tiny. How much does each user cost you? Basically nothing in the scheme of things. The problem is that the fixed costs are high - development, overhead, etc. Just becuase the variable costs are low doesn't mean you can't charge your users for the fixed costs.

Other businesses do this all the time. Startups should not be afraid of charging their fixed costs on to their customers. Advertising is fine if you are a media website and are trying to be an online newspaper or a website with no real function at all, but if you are a full fledged web app with useful features, CHARGE!

<comment><USER11> The freemium model pertinence depends indeed on the free user cost. A service for which the cost in minimal (i.e. no support, low bandwidth or storage needs,...) for free users, could benefit from it as a marketing tool.

The perceived added value for paying users should be significant, obvious and justify the fee.

</comment></comment><comment><USER12> Looks like "the web changes everything" is coming around full circle. To see the future one need only look in the past. What are retailers doing today? They've been at this for, what? Thousands of years, right?

In other words: some things are going to be expected to simply be provided (e.g. free wifi at starbucks). Some things people are just not going to pay much for, not even as much as you did (e.g. loss leaders like Milk). Some things you can mark way up.

</comment><comment><USER13> Instead of saying that "free" plans don't work outright, I argue that they work for some type of products and don't work for other products.

He provided examples of niche products that so far, serve small markets. LessAccounting, Crazy Egg, - what is their user base numbers? One example he gives has a user base of 5,000 users. If you are a niche product, I don't think the free plan is ideal since you are serving a small market and need to build a user base before it makes sense.

Conversely, if you have an app that is going to get a really large user base, and I'm talking 'millions', then it _probably_ will work (i.e. google, twitter, facebook, ect.). The example of those are far and few.

The other comment I would make is, maybe you aren't creating a compelling enough product to get a user demand that supports a 'freemium' biz model.

<comment><USER14> _Conversely, if you have an app that is going to get a really large user base, and I'm talking 'millions', then it probably will work (i.e. google, twitter, facebook, ect.)_

Actually, not. None of those are using a "freemium" model; they are all ad- based products. If your business model is dependent upon giving advertisers eyeballs, "free" is a great way to go-- but that has nothing to do with the topic at hand.

<comment><USER13> "Give your service away for free, possibly ad supported but maybe not, acquire a lot of customers very efficiently through word of mouth, referral networks, organic search marketing, etc., then offer premium priced value added services or an enhanced version of your service to your customer base."

From Fred Wilson's mouth (he coined the term "Freemium")

<comment><USER3> _acquire a lot of customers very efficiently_

First of all, people who don't pay are users, not customers. Secondly, how are conversion rates of less than 2% considered _efficient_?

In the freemium model, even if cost of customer acquisition (COCA) for a free "customer" can be considered to be zero, Life Time Value (LTV) is increasingly negative.

</comment></comment></comment></comment><comment><USER15> Yes, but would those companies have become popular if there hadn't been a free version in the beginning? Would as many invest in an unknown product in the beginning to eventually make it known?

<comment><USER16> That's why you offer free trials. :)

<comment><USER15> So the real advice is: Offer free accounts and then get rid of them.

<comment><USER17> That was basically what I took away from the article. Start by offering free accounts until you gain some sort of traction and people become aware of your product, but once you start getting significant traffic stop with the free.

<comment><USER18> Something else to take away: don't require people to give away their billing information upfront when signing up for a trial; simply downgrade their account if the trial period ends and they haven't paid yet.

</comment></comment></comment></comment></comment><comment><USER17> Perhaps a good balance is, instead of free, charge a small one time setup fee. pinboard.in for example does this and it seems to work really well. They offer a premium version with a monthly fee and a "free" version, which cost something like $5 or $6 to set up.

To me, the difference between free and a one time $5 fee was minimal, but to the people running the site difference in revenue is probably pretty huge.

<comment><USER19> That's worse IMO. Maybe the $6 is minimal for you, but it's not in the average case. Studies have shown that there is an enormous difference between "free" and "cheap" in people's minds. The difference between free and $1 is bigger than the difference between $1 and $10 in terms of customer resistance. The point of a free product is to eliminate barriers to entry. Most people are not that dedicated, and even the smallest snag in the conversion process can shoot them out of the funnel. Charging a small setup fee combines the worst aspect of pay (much harder to gain users) with the worst aspect of free (anemic revenue).

</comment></comment><comment><USER20> I feel this really should have been titled "Why _My_ Free Plan Didn't Work." Since free plans have and will continue to work for some people.

I don't know about you but I doubt GitHub would have taken off had it been exclusively pay-ware. Even if it did gain some traction someone would have made a free with upgrade option version of it.

<comment><USER21> The main thing with GitHub that makes it a great example of freemium is that they have two separate audiences for free and paid accounts. The free accounts are for open source projects and random hackers who write code for fun. By doing this, they attract talent and popularity to their service that convinces a different audience (businesses) to pay.

GitHub probably still has many more free than paid users, but the upfront cost was probably well worth it in the end.

<comment><USER22> I would guess that there are a decent number of paid users who aren't "businesses", but just people.

I myself have a paid account because: 1\. I want private repositories for school work and cba to set them up on my own server. 2\. I run my website off of github, and only paid accounts get CNAME support. 3\. I think they're awesome guys, and I want the service to stay around. This is the most important one.

</comment></comment></comment><comment><USER23> I would argue that in order for a free account to work you will have to meet the following criteria:

\- The free account is only useful while you're starting to use it - so a real constraint has to be in place for you to want to upgrade.

\- Your product has to be useful enough on it's own.

\- Your product is not too niche. If the percentage of people on planet earth that can benefit from your product is low, then there will be less chance that a user finds somebody else to recommend the product to.

I haven't looked at Bidsketch, but if people are signing up for free and the free plan has enough constraints in place but people are still not upgrading, that could be a sign that people don't like the product enough or don't get enough value out of it.

Also, the article doesn't state what features the free plan had, but if the free plan used to be what is now "basic plan", maybe the free plan was too good ?

The website looks good btw.

 _edit: added a bullet point_

<comment><USER23> You would also have to measure and account for over how much time the free users convert to paid users. If it happens over two years, you have to take that into account.

As the gigaom article mentions: _The thing is, over time inactive users drop off, and active users start paying. Once Evernote finally figured that dynamic out and started talking about it, term sheets and partnerships requests started flowing in, Libin said._

</comment></comment><comment><USER24> A free plan is often a replacement for advertising spending. It gets you users who wouldn't otherwise consider using your product, and you hope that they would tell their friends about it, and some of those friends would eventually pay.

Here is an extreme example: If I remember it correctly, MySQL's conversion rate was quoted as about 1 in 1000. If they didn't distribute the entire product for free, they would have much less market penetration, but certainly earned much more. Had they chosen that route, they wouldn't be able to sell the company for a cool billion.

Nothing in life is free. If you want a lot of users, and don't have the advertising budget for it, you give some or all of your product away for free.

</comment><comment><USER25> I recently wrote a post tracking evolution of pricing plan of a company (Clicktale) over last 4 years. Even though they still have the free plan, the prices of individual plans increased 10x in four years: [http://visualwebsiteoptimizer.com/split-testing-blog/how- pri...](http://visualwebsiteoptimizer.com/split-testing-blog/how-pricing- plans-evolved-over-time-for-a-saas-startup/)

</comment><comment><USER26> My site uses a freemium model, and in some ways it kind of has to. The site is a social-network type site where writers critique each other's work. Members can join for free, but their accounts have lots of limitations that are lifted by paying a monthly fee.

For my site, the most important part is having active members, whether they're paying or not. If nobody is active on the site to critique writing, then new writers won't join. Having a pay barrier to joining a community like this one would very quickly strangle it.

Like most freemium plans, only a small percentage convert to a paid plan, but enough do to keep making it worthwhile. I even doubled the price of the paid plan at one point to see if it would affect conversions, and it didn't, so people are finding the model useful.

So freemium works for a model like mine; but for many web apps, especially ones where the customer sets-and-forgets it, it might not make as much sense.

</comment><comment><USER27> _0.8% of free user accounts eventually upgraded to paid._

When only 1% of users were using paid?! That's doubling your paid user-base!

<comment><USER12> But how many free users came in in the mean time? Maybe the raw number was doubling but the paid user percentage wasn't. And even it was he found a way to get an 800% increase.

<comment><USER28> He said the revenue was remaining flat. That is the revenue was not increasing, so the core number of paid users was not increasing either.

</comment></comment></comment><comment><USER29> "... led to an 8x increase in paid conversions. Look at that again. That's not 8%. That's 800%."

Technically, a 700% increase.

<comment><USER30> Good point, but he did say "increase". Perhaps he meant x+8x?

</comment></comment><comment><USER31> The article makes excellent points all around. The #1 goal of any business is to gain positive cash flow (revenues greater than expenses). Anything else sinks your business. It's high time start-ups learned that lesson.

Sure, starting out you need to gain traction. You do that by: 1) having a superior product 2) gaining a superior rep

The only way to have a superior product is to identify your target market. Nothing in life is "free". If you want to offer a service to your clients that cost them nothing out of pocket you better be pulling in revenue in other ways (advertising or info selling). Since many are averse (privacy issues and ad- block) to those other options you must charge your user base.

Your product doesn't have to be the one with the most features, just the one whose features are the best executed.

Your product has to meet the client's needs. If you don't know who your target client is (Everybody is not an appropriate answer) then you need to refine your pitch. Part of client needs eventually comes down to support and interaction. If you spend all your resources (time, server, bandwidth, development opportunities) supporting a vast number of free clients at the expense of revenue generating clients you will quickly gain no to poor reputation.

Note: I tried to figure out what Evernote is doing. Their free service does meet the vast majority of user's needs (including mine). The amazing thing is that their service is so simple and straight forward that perhaps they don't need to spend so many resources on support and with the API (Trunk) and partnerships their development/expansion costs are now being taken on by so many other parties. I'm sure they bled cash brutally at the beginning but their product was so novel and amazing that VC money came to the rescue. Fact is that there are few start-ups in such a position. There are also few products out there so novel that users talk about not "needing to" but "wanting to" contribute to their success. Twitter? Ha! But Evernote is different. People want to pay them for their service even if they don't need to upgrade. They just love it so much. That is a truly rare and beautiful thing.

</comment><comment><USER32> This is also an important consideration when trying to evaluate (and iterate on) user feedback.

The type and quality of feedback that you get from paying customers is often completely different than what you get from non-paying users. Paying customers bring higher, and more importantly, more _precise_ expectations of how your product should work for them. If you listen carefully, they'll tell you what your product needs to be. You'll have fewer users, but you'll actually have a _product_ , rather than a service that tries to be everything to everyone.

</comment><comment><USER33> If you get someone in the door, you can upsell them _eventually_. You have a long time to go. I don't know if the relationship between company and user is the same in the current mobile app marketplace.

Also, many freemium companies are actually enterprise companies in disguise, where the pricing plans really work best for larger organizations over individuals. Free users are a loss leader to enterprise sales.

Generally, I wouldn't paint with such broad brush strokes. Free can work. Free might crater for you. Look hard at your product and market when designing your pricing.

</comment><comment><USER34> I am on the mailchimp free plan. One reason I think it works for them is that it's impossible to stay on the free plan if you are successful. It's nice to not have to pay while I'm building my list and don't get much value out of it yet. But every day, as my list grows, I know I'm going to have to pay -- at that point it would be silly to cancel.

Another reason it works for them, is that many of their customers probably start with a list -- in that case, it's not free (if you have over 500 subscribers)

</comment><comment><USER35> My 2 cents:

He did get a lot of exposure from the free plan, so at least at the beginning, a free plan is a great way to start a user base.

It is true that after that you will need to balance things out so that you don't get too many free users when compared to paying users.

But like the guy says, it's also about looking at your business and making a decision about whether this sort of free-plan offer is sustainable for your situation. For some companies it is and is part of the business plan, whereas for others it doesn't really help.

</comment><comment><USER36> This was the same conclusion that Homestead reached. They initially launched with a fremium model but after being deluged in freebie support costs switched to credit-card-required.

Although their overall signups plummeted, their paying signups went up by multiples.

It would be interesting to see if being freemium for a limited period at the very start is a profitable way to promote the company. Has anyone ever done a "get a free account now - available only for the next 30 days" experiment during launch?

</comment><comment><USER37> I expect in the near future we'll see more Trial Membership Plans ala Netflix and others and the Free Plan will be removed in favor of a demo example or a "nearly free" plan.

</comment><comment><USER38> For the launch of my next site I am going to do a limited number of free accounts a day(starting at different times in the day). Then you won't get overrun with free users, but allow people to give you their email to let them know when more free accounts are available. Not sure if this will help but worth a shot. Might force people to try it paid if they don't want to wait.

<comment><USER39> Just seems a bit arbitrary to me.

</comment></comment><comment><USER40> What does it mean for the IPhone/Android apps then? Does it make sense to have a lite/free version of an app?

</comment><comment><USER41> I just finished FREE by Chris Anderson.

It's a free download at Audible.com. I highly recommend that people listen to the book as it's only about 6 hours long.

</comment><comment><USER42> The conclusion that "Free plans don't work" has been overly extended from data that doesn't suggest anything of the sort.

What the data does suggest is that his free plan is meeting a majority of his user's needs, and hence the "extras" that people get for upgrading are not selling.

What he needs to do is reduce the free plan so that more users' needs are addressed in one of the paid plans.

</comment><comment><USER43> Free plans do work as a way to get a critical mass it seems.

</comment><comment><USER44> After reading the article we've made the free option less visible (www.examprofessor.com), and perhaps we'll remove it completely one day soon.

Nice article!

</comment><comment><USER45> I think you should use a free plan if actively using the 'free' plan will eventually force the user to go to a paid plan. e.g. dropbox.

If you just give your core product away for free then users will only switch if they need the extra features of the paid plan. You can still use 'free' for marketing, because total conversion rates with a free plan will probably be higher, just don't expect these 'free' customers to switch if they don't have to.

<comment><USER46> The problem with dropbox is that they don't have a client for automating backups. That means everything I store there has been manually dragged into the dropbox folder (see NB). It would take me a long time before the number of files I needed to share online exceeded their free limit.

NB: Truth be told, I run batch files via task scheduler for backing up certain folder to dropbox, but I doubt the typical consumer does.

<comment><USER47> I use symlinks to the directories I want inside the main Dropbox folder. This works well.

</comment></comment></comment><comment><USER48> Maybe he should also consider changing the text on the register button?

<http://www.bidsketch.com/>

<comment><USER3> There is a 30-day free trial.

</comment></comment><comment><USER49> Free plans work if they are inadequate for customers who can afford to pay, but adequate for a taste. Less Accounting does a great job of this. The only reason not to offer such a plan would be the resources it requires to support free customers, and perhaps that it has a negative price anchoring effect.</comment>


Technical Debt is Not a Bad Thing - <AUTHOR> http://sendgrid.com/blog/technical-debt-bad-thing/ <comment><USER4> As far as I can tell, this article is saying "if you define technical debt as something that isn't too bad, technical debt isn't too bad".

The article draws a distinction between bad code and technical debt - <USER2> things that make it hard to refactor a system are not 'technical debt' but 'bad code'. It's my experience that being unable to refactor systems is a consequence of accumulated technical debt - that as the interest compounds, bad designs build on top of bad designs and you can't fix the first bad design because the second bad design relies on it.

And the more expensive it gets to pay down the technical debt, the less anyone wants to pay to do it.

<comment><USER5> This does seem to be an odd distinction. Though, I think the metaphor of technical debt does support the interpretation. At least to a degree.

Technical debt should be viewed the same as any debt. With a major caveat being that there is no time limit on it. And to that end, you don't always have to pay down your debt.

The problem, I think, is everyone applies personal financing to thinking of technical debt. Very rarely can an individual accrue debt that will allow them to make money. It is not at all uncommon to make a design trade off that "pays dividends" pretty much immediately.

And, not too shockingly, xkcd has a good visualization on this. [http://xkcd.com/1205/](http://xkcd.com/1205/) (Granted, I can see how this is not necessarily the same thing. But I often feel that what folks call "technical debt" is really, "I wanted a jet liner solution for what a walk down the street could have accomplished.")

<comment><USER6> But is technical debt really like ordinary debt? I think an argument could be made that technical debt is inherently worse than ordinary debt.

I think it relates the discussion of why software is an especially hard thing to write.

A simple way to put it is, "planning a large system is harder than you think it, for any value of 'you'". With another large part being that no only is calculating the time spent on the project hard, calculating how long or short the project will be is hard. And "harder than you think" means that no matter how sophisticated one gets, bad estimates will tend to seduce you based on the deadly combination of ignorance and wishful thinking - everyone experiences wishful thinking and everyone is ignorant of the real implications of a large enough new system.

Now, technical debt involves getting some momentary gain in the present based on _planning_ to take of the problem in the future. And by that token, technical debt will expose you to the risks of planning a larger system immediately.

And this isn't to argue that one can or should eliminate technical debt - <USER3> that there's every reason to be more wary of it than ordinary debt.

<comment><USER5> If you are challenging that technical debt is not like ordinary debt, then you are just challenging the metaphor entirely. I agree with challenging it; though, I think it is more applicable than you are allowing.

My personal take, is the debt is actually taken out against the knowledge of others. That is, in technology, knowledge is the currency. To take on technical debt, then, is to leverage other peoples knowledge.

This sounds dangerously close to my saying technical debt is the opposite of NIH. And to an extent, I think I am. Pretty much, identify the areas where you/your company will take full ownership of the technology versus the areas where you will rely on the solutions of others.

I think the metaphor can be seen as double edged in this regard. Companies such as Google can afford to make massive investments in custom build workflows/etc. Smaller companies can not afford these investments and instead must work with standard "off the shelf" ones.

That is, your company may not be able to afford avoiding some technical debt. And the vast majority of the "debt" you take out will never need to be paid back.

<comment><USER6> Well,

Many metaphors can be partial metaphors and still be useful.

I agree with your point that the ordinary debt that enterprise takes hinges on asymmetric knowledge - I think contemporary economics sometimes looks at it that way.

Consider there are different kinds of debt. Gambling addicts will frequently barrow money to gamble more. They get a certain high from gambling and they have a delusional idea of their odds of winning. I think the worse sort of software technical debt can equate to this - the planners merely have a delusion that they have a better idea of the risks and rewards involved than other people.

I agree that most companies have to take on technical debt. I think they do pay for it in the form of miserable programming environments, bad software and canceled projects. It is true that once a project is canceled, the technical debt is gone and unpaid. But most of the world's bad debt isn't actually paid - unless the Mafia decides you should sleep with da fishes...

<comment><USER5> I didn't mean the debt would go unpaid by the project being abandoned. I meant more that you take on debt in every choice you make, and many of these "debts" will not come due for anyone.

Consider, many folks that are writing PHP level apps do not know how the full HTTP stack works. Expand that, most people writing web apps of any flavor have a small understanding of this.

For most of us, this is not a big deal and never becomes due. We took on some technical debt by trusting the frameworks that we have chosen to handle them for us.

However, if any of us find ourselves at the scale of Facebook, Twitter, etc, then we find that suddenly a lot of the tiny details of HTTP start to matter. To the point that solutions that minimize resources and the like suddenly matter. Heavily.

All too often, however, people use this argument in favor of "shiney new framework." Taking on struts was technical debt because you offloaded much of your core to them. I question whether many companies truly needed to ditch fully working struts implementations in favor of "new shiney," though.

And then, this metaphor can be extended in amusing ways. There was the assertion that git took on unnecessary "technical debt" by remaining in C instead of C++. Instead, it can also be seen more as they took on the cost of not having abstractions unto themselves.

So, my assertion is that for most projects, the benefit of a technical debt never outweighs the downside. Not because the project will "go away" but because it just is never really a problem.

Your gambling example is amusing to me. Few people will ever consider that healthy debt. It is one thing to have a sponsor, and another to have an addiction.

<comment><USER6> Well,

My experience is in medium-sized-institutions rather than giant soft-centric firm like Facebook or Google or the single-web-app startup. I think this is where the majority of programmers still work.

Here, projects "always" last longer than you think and effects of shortcuts accumulate in an unfortunate fashion.

You can say technical here is a "good choice" when it happens to be an unavoidable choice. But when it is an avoidable choice, I see it as "always" a bad choice.

\-- And my quoted "always", I mean "often and more often than it is your naive impulse to think so that it's better to say always than to just guesstimate that it might not happen in this case 'cause you'll be swayed by wishful thinking"

<comment><USER5> But, here is the thing, technical debt also includes adopting "new shiny." I've known people that decided to roll their own framework instead of just sucking it up and using wordpress or ext. Meanwhile, someone else came along and used these, got a solution together, and managed to knock it out of the park.

That is, debt should be considered in this regard the same as a loan for money. Taking out a loan to get something done quickly and with little effort has a huge benefit. So does picking a framework that you can hire a lot of folks for.

Further, and this can be subtle, if you are going to do this, then you bloody use the money/technology according to the terms of the entity lending. How many people hate maven because they decided that its way just wasn't good and wanted to tweak it? How many people, on immediately taking up a new technology, look for how they want to do it first? Before they have even understood how that technology was made to be used?

This is not to say there may not be reasons to leave or tweak a technology. But, realize for most companies it is not a viable proposition to do so. Instead, accept and leverage the disadvantages and limitations of the technological "debts" you have taken out.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Technical debt isn't _necessarily_ bad. However, people who take joy in pointing this out usually aren't the ones who end up paying it down every day. It's usually a (sometimes wannabe) pointy-haired boss who's just trying to crack the whip harder. The key is realizing that technical debt must be paid at some point. Saying "technical debt isn't bad!" is oftentimes an excuse to avoid paying it down.

<comment><USER8> Is it considered better practice to pay the debt down little by little, or all at once (as in rewrite or feature freeze)?

<comment><USER9> There aren't many managers around that are going to feature freeze to pay off technical debt. In reality it has to be paid off as you come across it i.e. you're working on a new feature that depends on some code with technical debt. This seems fine as after all, there's not much point paying off technical debt if it isn't slowing down development.

</comment></comment></comment><comment><USER10> Sure debt isn't a bad thing ... if you invest your loan wisely, and pay it back. And "bad code" is absolutely technical debt. If it was cranked out because of a deadline, it might be well-invested debt, if it was done because of laziness or incompetence, then it's just like maxing out your credit card on a trip to Vegas... but either way, the loan will come due.

</comment><comment><USER11> This title is intentionally misleading, but I'm glad for it because it was a good read. But essentially what it is doing is redefining the term 'technical debt' in terms of its original, intended definition, as opposed to the definition by which it has been re-appropriated, i.e. 'bad software'.

If you define 'technical debt' in the re-appropriated sense, it is surprising to see an article title which translates to 'Bad Software is Not a Bad Thing', which is why I immediately read the article. But the original definition makes so much more sense, and actually provides the motivation for thinking of 'technical debt' as having a real place in the philosophical conversation of building software.

</comment><comment><USER12> Technical debt is like debt, if you are borrowing it to expedite something and you actually pay it down later when you have the resources it can be a good thing. Sometimes though, it is just poor development practices or design. Here is a presentation I gave at the FirstRound Capital CTO conference a while ago, it was pretty well received and fun to talk about things people have seen in their own companies:

[http://www.slideshare.net/spullara/managing-technical- debt-1...](http://www.slideshare.net/spullara/managing-technical- debt-15539856)

</comment><comment><USER13> Technical debt comes down to the ideology of "make it work, then make it right".

Every time I make a technical decision, I ask myself how much debt am I taking on if I skip the "make it right" part. And what am I gaining from skipping that step?

I think the CEO's, CTO's, product managers, mid managers and lead devs all know they are taking on debt (if it has been communicated to them properly), they simply make what looks like the best decision at the time as far as the business goals are concerned.

\- The debt can be hidden until, its to late. How many times have you thought, this code is duck tapped from top to bottom and on release its fine? On the other hand how many times do you think code is bullet proof only for it to fail once it hits real world use cases?

Technical debt is a risk vs reward equilibrium and everyone uses their best judgement to decide how much they want to borrow (unless they are ignorant to the the fact that they are taking on debt).

As the author mentions, in the context of a startup taking on technical debt. Its much less risky.

On one side of the equilibrium we have, "build a polished product that no one wants" then on the other side we have "release a buggy MVP, that will drive early adopters away forever".

I would rather save time and get a MVP out ASAP, after that deciding if its beneficial to pay off the MVP debt or to keep iterating faster and release a 2.0.

</comment><comment><USER14> A lot of what is called "technical debt" is really developers coming in after the fact, looking at messy, real world code with years of feature build-up and bug fixes in it, and deciding "Ugly, rewrite."

<comment><USER7> A lot of "technical debt" is also messy, real world code that its writers can't accept as being bad because they've dealt with it for so long and can't think about it any other way.

<comment><USER15> I imagine the intersection of those two sets is much larger than either camp is likely to admit.

</comment></comment></comment><comment><USER16> I've never understood why people do not track technical debt in the same way that we track bugs and other issues. At least that way you can report to management the increase in debt, and the ratio between the amount of debt and the time to fix bugs.

</comment><comment><USER17> The article heading and conclusion line seem to contradict each other.

"Technical Debt is Not a Bad Thing"

"When you don't pay down technical debt, just like real debt, it becomes a big problem, as I explained in Dirty Socks and Technical Debt."

</comment><comment><USER18> Surely something HN likes to discuss.

[http://hn.algolia.com/#!/story/forever/0/technical%20debt](http://hn.algolia.com/#!/story/forever/0/technical%20debt)

</comment><comment><USER19> correct, technical debt is a _very_ bad thing.

<comment><USER20> My two cents is to point to an analogy with the economies of under developed countries: The more debt you have, the more difficult it is to get rid of it, and in the end it may lead to defaulting and bankruptcy.

So, you can't just "borrow" everywhere, and think that you are able to repay. It is important to refactor and downpay immediately, when you realize that you are going to depended on the debt elsewhere, or you'll get accummulated debt when you'll have to downpay the dependencies as well.

I'll coin that as the "future value of money syndrome". :)</comment></comment>


Productivity Showdown: Python/Django vs C#/ASP.NET - <AUTHOR> http://kurtgrandis.com/blog/2010/02/24/python-django-vs-c-asp-net-productivity-showdown/

<comment><USER2> Neat.

One of the arguments I hear against Python is that while initially things happen fast, the effect does not scale for large applications. Or that Java/C#'s static type checking makes it more scalable.

I'm curious if you have seen any scalability effects. For example, did the Python teams productivity stay consistent or did it taper off the further into the project you got? Did the C# team's productivity go up over time? Stay constant? Drop?

I'd be really curious to see the time series on the productivity.

<comment> bjelkeman-again Yes, that would be interesting. I wonder how much this depends on how much "low level" work one has to do though? In the article he talked about the programmers not being that familiar with Django yet. It depends of course a lot on what you are building, but in our development team we find that we don't touch Python that often and mostly build at the Django layer.

<comment><AUTHOR> Both really good questions. That was started almost two years ago so we've worked on a variety of different types of projects since that initial study-- from simple websites to high-availability, rich applications. Some have required more internal knowledge of Django than others, but I can't think of a time where Django itself was an impediment or a bottleneck.

With regards to time series...me too! I don't have enough data to make any statistically-backed claims, but anecdotally Django-based sprints do start off with a big bump in velocity, because you're handed a tremendous amount of functionality upfront via the framework itself, Admin CRUD, etc.. Once a team gets moving their velocities tend to stabilize, which is one of the reasons story points and velocities are such powerful estimation and forecasting tools.

That being said, C# teams seem to have larger standard deviations around their mean velocity. One thing I have noticed is that refactors tend to have differing impacts. Major refactor efforts and rearchitecting almost always noticeably hit the C# team's velocity much more so than the impact on the Python group. Having done refactoring and and rearchitecting in both environments, I tend to think it's a function of the syntactical overhead associated with the C# language.</comment></comment></comment>