The Parable of the Two Programmers (1985) - <AUTHOR> http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html? <comment><USER2> There was a MOOC on Coursera called "Irrational Behaviour" and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to a point where he was fixing the door locks in 10 or 15 minutes with virtually no disturbances for the customers. His tips started to fade off and his customers became outraged at his 70$ charged for those 10 mins of work.

Conclusion: we don't want to pay related to the value we receive for a certain service, but to the amount of effort involved in the delivery of that service.

<comment><USER3> >Conclusion: we don't want to pay related to the value we receive for a certain service, but to the amount of effort involved in the delivery of that service.

I don't think that's a fair conclusion. There's _much_ more going on here.

Locks are security for people. If I call a locksmith and he takes over an hour to open or fix my lock, I think, "Oh, good, even a professional is going to take some time to get through this. It's pretty secure!" If the locksmith is done in 10 minutes, I think, "Holy shit! With the right tools and know-how, someone can completely bypass my security in ten minutes!" This isn't so shocking around here, because most people on HN know just how vulnerable most security systems can be. Many people will not have that knowledge and be comforted by a locksmith taking longer.

Also, when you hire a locksmith, you usually watch the locksmith do his work- either because you're locked out of something and have to stand around uselessly, or the guy is in your house and it shouldn't take too long. This makes you invested in his effort- if it takes an hour, you _watched_ the locksmith work for an hour. It's hard not to pay, given that you saw how long it took, and how he was working at it.

The same standard doesn't seem to apply elsewhere- if my steak takes an hour rather than twenty minutes, I'm not going to pay more for it, I'm going to complain to the manager. If the oil change takes too long, I'm not going to be happy about that, either. If I buy a cabinet, I usually don't care if the carpenter took 10 hours or 20, I'm going to want to pay based on the quality of the cabinet.

I think your conclusion is true in _some_ situations, but it's definitely not universal to all work.

<comment><USER4> I think this is mostly true.

However, if you were watching someone prepare _the_ most exquisite steak, and it took lets say a full hour to trim the meat, get the pan ready and properly buttered, cook off the edges of the steak, etc, and you were sitting there watching the chef go through this metiMaybe we just care about seeing the complexity in an operation for it to have value.culous process, then perhaps you wouldn't be upset that it took so long--and most likely would enjoy the steak more, having seen the entire complxex and careful process to cook the thing.

Similarly, if an oil change was a complex operation and you watched the mechanic half-dismantle your car to change whatever needed changing.

Or if you watched a programmer bounce around the screen in vim for 20 hours; coding, testing, tweaking, and debugging.

</comment></comment></comment><comment><USER5> The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be _a lot_ harder than expected

What happens when, after 2 months of scribbling and playing space invaders, Charles realizes the project actually requires 3500 lines of code? He wants the project to succeed but now he doesn't have enough time, and he fears to ask for help because he knows he is labeled as a lazy and arrogant guy.

So he works long hours to fix the situation, then he burns out.

Source? This is somehow happened to me. Several times.

This story can be true, people like Charles and simple projects exist, but these are exceptions, not the rule. It's easy for a beginner to believe he is that guy and then experience a death march [1] Things can go wrong for Alan, but he has a team to support him and his managers know he is working at something complicated.

I'd like to be Charles one day, but for now I'm Alan.

[1] [https://en.wikipedia.org/wiki/Death_march_(project_managemen...](https://en.wikipedia.org/wiki/Death_march_\(project_management\))

<comment><USER6> If this story had happened in real life, and the problem had been more complicated than anticipated, and Charlie had realized this, it would be likely to fail, because he did not have enough leverage toward the upper management to get the resources required to succeed, so in that case the project would be likely to fail, or at least be severely delayed.

However, Alan was making the problem more complicated by introducing a lot of accidental complexity, and I have often seen that this is done even when the problem is more complicated than anticipated. Such a project could easily create enough work for 10-15 people in the hypothetical scenario in the article if the project had enough necessary complexity to be a four person project.

It is very hard to distinguish between what is necessary and accidental complexity, and that is precisely the point of the article. Prestige is very often bound to how many subordinates you have rather than how well you solve a particular task, so making your project artificially complex can be a strategy for climbing toward upper management. This may of cause be a conscious or unconscious from the employee/manager in question.

<comment><USER7> > ... and Charlie had realized this, it would be likely to fail, because he > did not have enough leverage toward the upper management to get the > resources required to succeed

Not to mention, the company will be paying Alan and his team much more than they're paying Charles.

It's my suspicion that people will give more weight to people they're paying more, simply because they're perceived as more valuable - independent of any other hard data. So despite having already spent more money on Alan, they'd be likely to continue doing so, due to the perception of hard work and the perceived value to the company.

<comment><USER8> I read an study testing an idea similar to yours, but with wine. They organized a study in the guise of a wine tasting event where there were 3 bottles of wine, but 2 bottles were marked up (one from $5 -> $50 and another from $10 -> $90). Even though people didn't know they were tasting the same wine, they said the the more expensive one tasted better. The other half of the study was with the prices removed, people couldn't guess the more expensive wine. The conclusion from the study was that "Individuals who are unaware of the price do not derive more enjoyment from more expensive wine."

Source: [http://www.wired.com/2011/04/should-we-buy-expensive- wine/](http://www.wired.com/2011/04/should-we-buy-expensive-wine/)

</comment></comment></comment></comment><comment><USER9> Related Hacker News comment: [https://news.ycombinator.com/item?id=8941621](https://news.ycombinator.com/item?id=8941621)

From 'Software Requirements & Specifications' [0], by Michael Jackson (not that Michael Jackson, and not the other one either), published in 1995, a parable [1]:

'What do you think?' he asked. He was asking me to tell him my impressions of his operation and his staff. 'Pretty good,' I said. 'You've got some good people there.' Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.

'What did you think of Fred?' he asked. 'We all think Fred is brilliant.' 'He's very clever,' I said. 'He's not very enthusiastic about methods, but he knows a lot about programming.' 'Yes,' said the DP Manager. He swiveled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. 'Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.' His voice dropped to a reverent hush. 'Fred tells me that he's not sure he understands it himself.'

'Terrific,' I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. 'But what about Jane?' I said. 'I thought Jane was very good. She picked up the program design ideas very fast.'

'Yes,' said the DP Manager. 'Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet -- if you see what I mean?'

I saw what he meant.

[0] [http://www.amazon.co.uk/Requirements-Specifications- Software...](http://www.amazon.co.uk/Requirements-Specifications-Software- Principles-Prejudices/dp/0201877120)

[1] [http://www.win.tue.nl/~wstomv/quotes/software- requirements-s...](http://www.win.tue.nl/~wstomv/quotes/software-requirements- specifications.html)

</comment><comment><USER10> I've lived this experience, many times over, and the story is true at it's core.

Some folks might dismiss this as a fantasy scenario, and sure, it's missing a lot of details. In the real world, the lone programmer doesn't get to write an efficient program for different reasons: the software design is locked down by managers, there is fear of abandoning the poorly written legacy code, newer programming tools aren't allowed because most developers don't know them, or there is a sunk cost of an expensive software license that has already been purchased.

The story is symbolic, but the lessons are universally true, even today. For managers: conventional methods of judging productivity are unreliable. For developers: few organizations will enable you to work optimally.

</comment><comment><USER11> I don't believe some parts in the story.

1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data.

2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experienced coder. Specs are usually ambiguous and often don't even describe the problem that actually needs to be solved. It takes a lot of talking to clients to discover what you actually need to do. Halfway through the project you'll realise that half of the spec should be changed. If you just implement the spec without talking to anybody, you'll end up with code that solves the wrong problem.

But then there are things I can absolutely relate to. Good solutions seem simple and obvious in retrospect. But it takes a lot of effort to come up with simple solutions.

<comment><USER12> It's explicitly labeled a parable: "a simple story used to illustrate a lesson." It's not meant to be literally true. The second programmer's inexperience is just another reason why his boss judges his work to obviously have been easy.

<comment><USER13> Unrealistic parables teach unrealistic lessons

That a thing is a parable does not render it immune to disagreement on realism grounds

Indeed if the defense is to point out that it's not meant to be realistic then it's probably not just valueless, but of negative value

Parables are not a good way to learn in my opinion

<comment><USER12> The point of this parable is that neither company has any clue what the actual value of the work done was. Alan looked like he was working hard and was rewarded for looking like he was working hard. Charles looked like he was goofing off and was rewarded for that.

Yet when you compare the results, Alan took 24 programmer-months to solve the problem, and Charles took 3 to do it better. If the companies had some way to objectively value the work done, Charles is clearly vastly better. But they don't.

It's got nothing to do with the specific techniques involved. It doesn't even weigh in on the reason for the difference -- is Charles brilliant compared to Alan's normal, or did Alan just stumble and turn a simple task hard? That's all irrelevant.

The point is just to illuminate how hard it is to know the value of a developer's work. I know I've run into that repeatedly in my career.

</comment></comment></comment></comment><comment><USER14>
      Day         What I Did        TotLOC
      ---  </comment><comment></comment><comment></comment><comment>-----  </comment><comment>
      Mon  Prototype Possibilities     300
      Tue  Write Building Blocks       900
      Wed  Construct Major Content   1,700
      Thu  Add Features              2,200
      Fri  Refactor, Test, Deploy      300

      Customer: Looks great. Thank you!
      Boss: Only 300 lines of code in 5 days?
      Boss: How can you be more efficient?
      Me: I could take Fridays off.

<comment><USER15> I don't understand; your numbers add up to 5400, not 300.

<comment><USER16> The final column isn't LoC written that day; it's LoC in total. Friday was spent refactoring (what we in the old days called "rewriting", before the hipsters made it cool); taking the code that was already working, and making it smaller, lighter, better.

<comment><USER17> > what we in the old days called "rewriting", before the hipsters made it cool

Calling it refactoring dates back to at least the early 90s[1], which I'm pretty sure predates "hipster hackers." If anyone "made it cool" it was probably Martin Fowler[2].

[1] [http://www.ai.univ-paris8.fr/~lysop/opdyke- thesis.pdf](http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf)

[2] [http://www.amazon.com/gp/product/0201485672](http://www.amazon.com/gp/product/0201485672)

</comment></comment></comment></comment><comment><USER18> I dislike this strongly. It is attempting to demean a group of people without really giving them a fair chance. It exaggerates and vilifies the "enterprise programmer" while lionizing the young-but-inexperienced smart programmer. It's a very common theme here on HN. It's playing into the narrative of the young entrepreneur that can drop out of college and build the next successful start- up. The fact is that most people in that situation will fail the first few times as they gain experience. People who can operate like Alan, though obviously Alan does not deliver results, are very valuable in a company. Systems have a tendency to get more complex and you will need people who have experience dealing with that complexity, managing it, and reducing it.

Let me address the parable a bit more directly.

The parable is very hard for me to relate to because to me it seems like the two characters are cherry picked such that they're vastly different in terms of skills. It looks to me like Charles is either much better than Alan at design or got lucky. I think the only wisdom that can be gleaned from the story is to not over-complicate your design. Charles and Alan both spend time upfront designing their code, but it seems that Charles came up with the better design and saw the simple kernel of the problem. That's the only real difference between the two. Alan saw a problem that needed a lot of work and specs to get right, but Charles saw it was actually a very simple problem.

I would say the lesson is to make sure you understand the problem well enough, but Alan is an experienced guy who still couldn't figure it out, so it must have been a hard problem to know how to work with in the first place. Maybe Alan was working defensively to make sure he had all his bases covered in case the design turned out to be different than he initially anticipated. I can't say.

<comment><USER19> This is indeed a comment-baity article. It is fiction, those two people didn't really exist and do those things. It gets programmers/developers riled up - because it's so believable.

It is indeed the case that the characters are vastly different in terms of skill, and that is sort of the point. Alan did spend time developing his skills, but it was focused on frameworks and processes, and not effective programming or problem solving. Maybe he just didn't have the right start, didn't know what he didn't know, and just went the wrong way from there. But management, and Alan himself, can't tell the difference.

I think that's the ultimate take-away. Non-programmers and "bad" programmers can't recognize good programming, even if they look at results. Well they can, but it takes a lot of time and luck to come across comparable situations. It seems like an intractable problem. They don't know who to trust; and there doesn't seem to be a way to find out for them, except to be genuinely good at developing software... but how to know which way to go about that?

</comment></comment><comment><USER20> A lot of people seem to think this is a story about programming. It's not. It's about perceptions. A good programmer knows that a certain portion of his work is managing perceptions. This is part of a skill-set known as 'soft skills' and will get you farther than a perfect understanding of monads.

</comment><comment><USER21> The issue that seems to be overlooked here is the objective value of solving the problem itself. Instead it focuses on the developers and their rewards.

A does a thing, it takes a long time, solves the problem and he becomes System Analyst.

C does a thing, it's shorter in both time and effort, and he leaves the company a year later.

What about the value produced by the solution?

It's clear that if a single (inexperienced and poorly communicative) developer can produce a satisfactory solution in a fraction of the time of a majorly architected approach then the first view (A) is overvalued.

The moral of the story seems to be something about how huffing and puffing, self-importance is rewarded over a thought out appropriate solution to the task at hand.

How about going forward in the story? A sequel-sequel?

At Automated, their unrealistic approach to planning and development, and their focus on titles and rewards led to bloated and unmaintainable software, where everyone in the company fought to make something "smart" that demonstrated their intelligence and worthiness of being rewarded - the problem specifications being nothing more than a means to achieving this.

At C, Charles either gained the experience necessary to understand the reasons for communicating efforts and planning to the rest of his management and went on to design appropriate solutions in another company, or he decided that being rewarded for his efforts was more important than solving problems and gaining domain experience and joined the above.

</comment><comment><USER22> I know it's a parable and the objective is to send the message that "customers value complexity". In the enterprise we see lots of news where a business spend millions in a certain solution and we sometimes think it was overspend.

But I see another point why the story reflects the reality in some aspects: experienced developers tends to overengineer a problem, and I recall the 'hello word' joke about programmer evolution. But at the same time, the novice, rarelly will deliver a good sollution in the first time.

In my point of view, the simpler solution, will just work, could have lots of technical debts and could be hard to scale, while the complex one, could turn costly to support. Its very hard to find an optimal point between both.

</comment><comment><USER23> This brings to mind the maxim, "A job, no matter how small, will grow to fit the time and resources available".

<comment><USER24> Well stated. I will jot it down for my next meeting with my manager :)

<comment><USER25> Shhh. It's a secret. Use it to your advantage, don't tell your manager!

In all seriousness though, your manager probably won't take kindly to hearing your advice about project management.

</comment></comment></comment><comment><USER26> If there is a second sequel to this story, it's that the one guy goes on to start a successful company, and the other guy is entrenched in the politics of his company.

I think this would be a better comparison if space invaders was left out. Or perhaps if it were, "he scribbled for a while, then played space invaders, then scribbled some more.", as opposed to him starting with nothing but space invaders. The other guy began by inventing problems rather than solving them.

It comes down to, a direct, though outwardly puzzling, solution that is apt VS. an indirect, political, frustrating(for everyone), bloated, slow solution.

If it weren't a programming department, and it were two different companies, survival of the fittest would kick in, and the better faster guy would be more successful. And, it has. We now learn from the successful companies that are similar to the space invader guy and it doesn't seem so weird. The fact that people were catching on to this idea in 1985 is pretty striking.

This is anecdotal and doesn't really teach the bigger picture. It's also not encouraging, as it doesn't lead the user to the correct path of action.

It really needs a second sequel where the space invader guy goes on to be wildly successful to be a good story.

</comment><comment><USER27> That is why I love perl: the manager can not understand it and can not say it was simple.

<comment><USER28> I wonder how much language popularity is affected by this effect.

We Lisp/FP fans crow about how easy and quick dev in more expressive languages is, but to a clueless manager that's potentially exactly the problem. If it doesn't look like work, then the manager is apt to wonder what they're paying you for.

Whereas JavaEE ...

<comment><USER29> APL should've been much more popular if prestige by intimidation was a major factor.

</comment></comment></comment><comment><USER30> I can see exactly where Charles went wrong. Here is how the story should have gone:

Charles implements an entire interpreted language with garbage collection and an incomprehensibly coded virtual machine. Everything is documented and works flawlessly at that level, however. Nary a bug can be found by anyone experimenting with the language.

Charles writes the program in 30 lines of this language, which appear fairy simple on the surface, but rely on some deep semantics (that Alan's team doesn't even comprehend, for instance, let alone management, without studying).

In this case, nobody can dismiss the problem as being something easy that a junior programmer can solve, and Alan's team look like troglodytes from the Dark Ages. All the more so because their buggy, incomplete program is over 2500 lines, while Charles' language fits into 2300.

:)

</comment><comment><USER31> Rarely (unless you are working on your hobby project) you get a chance to make program simple. There are inherently complex requirements that can't be changed for political reasons, complex legacy interfaces to conform to et c.

Interestingly, most programmers seem to think that inherent complexity doesn't exist, i.e. that any requirements can be translated into a simple program. The result of this approach are leaky abstractions that later on cause much pain to the developer and anyone maintaining the codebase.

</comment><comment><USER24> Quite an interesting article. The best part is that the article does not judge. It simply lays down facts for us and leaves the opinionated part onto us.

<comment><USER32> I thought this was a fictional story.

<comment><USER33> It might be the most fictional story ever written about programming.

It's completely ridiculous.

<comment><USER25> I don't think it's ridiculous at all. Have you ever worked in the defense industry?

<comment><USER33> Yes, actually, I have.

So this story isn't ridiculous because it applies to a niche that it never mentions?

</comment></comment></comment></comment></comment><comment><USER34> I have seen this kind of problems many times in real life. By start writing design doc and prototype code from very beginning, you demonstrate effort and progress. You most likely get hold of the project and eventually deliver it along with all the incremental complexity during the process.

On the other hand, if you spend 2 months iterate through the requirements and alternative design choices, you are far more likely to come up better design, but your manager (or the entire company) would have no patience to watch you thinking in your head. As the result, I have seen software designs could have been 10x or even 1000x better, but most people prefer to get something out first (this is especially necessary for startups).

Another random comment is LoC per day. I worked at a few large companies. The statistics show the residual code is about 6-16 lines of code per business day per software engineer. A lot of time goes into design, debugging, testing, iterations, redesign, refactoring.

</comment><comment><USER35> This is a parable about whether you really understand the nature of the problem, or not. If you do then you can produce a concise definition (i.e. a better program in fewer LOC) and if you don't then it can get much more complex. It's like the difference between trying to make a machine fly by making wings out of feathers and having it flap, or understanding the principles of aerodynamics and making a fixed wing out of canvas.

However, for most non-trivial problems understanding everything up front isn't possible. To know what works you may need to create prototypes and iterate, abandoning things which don't work or which end in a hairball of complexity and getting opinions from testers. In that situation just intuiting a solution and then typing in the code won't work and the more formalised process might work better.

<comment><USER36> The parable is really about the nature of corporate politics and the art of perception management.

I'm not sure how obvious the underlying point is -> _programming languages and methodologies are structured by political requirements_.

Programmer A is writing software. He knows nothing about perception management and status plays.

Programmer B is furthering his career and angling for a raise. By accepting 'corporate coding standards' he has proven he knows how to play the game and uses the project to increase his status.

The quality of the finished product, in terms of user experience and practical usefulness, isn't nearly as important as the social processes that created it.

IMO the interesting question is how much this applies to coding culture _and language and OS design_ as a whole.

</comment></comment><comment><USER37> Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.

<comment><USER38> No, this is just an extreme example of the "don't try to be a smart guy" ideology. In practice 100-500 LOC per day is normal.

<comment><USER39> Firstly, any real working programmer has days where they write _no_ code. You are writing documentation, meeting with users and sponsors to discuss new features and schedules, doing code-reviews and mentoring, merging branches, debugging race conditions, meeting vendors, chasing dependencies in other parts of the company, a million other things. That brings the average LOC/day down.

I can't imagine anyone sustaining 100 LOC/day over the long term unless they think that cranking out HTML templates or something counts as programming.

<comment><USER38> I realize that I was referring to number of LOC touched a day, not change to the total codebase size. I'm not sure what the first poster had in mind.

For reference, I count myself as writing about ~40 LOC a day for a greenfield project (which I spend about 50% of my time on), measured by total codebase size.

And no, it is not HTML templates, although it is a fairly verbose language. And I do all the things you describe in your first paragraph.

In my experience, a good programmer is almost always a fast programmer, and non-trivial programs usually require a lot of LOC to get the job done.

</comment></comment></comment></comment><comment><USER40> I think it's actually a great little story because in the end, everyone got what they wanted.

The lone programmer did his work, got paid for it and left, hopefully to find a company with a better fit.

The team was hired and got paid to do their work and, while doing so, created a process that the company felt comfortable with. Perhaps they are still working there today.

Everyone seems to have taken what they needed and got what they wanted.

There are an infinite number of ways to slice a thing. Choose one and figure out if it works for you. This applies to both sides, the worker and the management.

</comment><comment><USER41> The meta message of the parable is programming is, in actual practice, an art, not a vocation or profession. For political / economic reasons we sometimes have to pretend its a vocation or profession, but it really isn't in actual application. Software architecture should be in the "fine arts" department at university, not a branch of finance, engineering, or math.

In art, people expect the highest quality producers to instantly produce effortless appearing product (music, dance, painting, sport, drama, whatever) and are generally willing to pay for quality unless they're a hopelessly tasteless neanderthal. The only time effort is rewarded in art is when parents watch their (own) kids perform.

One epic fail of the parable is it was written in an era of C (pascal?) dominance where 500 LOC means something different then from now. That would be at least 2000 lines of boilerplate-ish java (think of the classic "enterprise hello world" java implementation) or 10 lines of clojure and pretty much everything else fits in between. Something that has stayed constant over the decades, from my observation, is a "complicated functional block" takes maybe three hours long term total average, a "little bit less than before/after lunchhour", and the only determiner of how many LoC are produced in that time is language quality and programmer quality. Maybe another way to phrase it, is a correctly sized block on a project flowchart takes a couple hours in all languages for a given class of programmer ability.

<comment><USER42> While software architecture certainly is an art, I would not say it is unique in that aspect among the fields you mentioned. Both engineering and maths should be considered art in their own rights.

If you consider abstract mathematics, it is easily seen that many mathematicians find most of their inspiration in the aesthetics of their ideas. Somehow the way we teach maths obscures this fact from the students.

Oh, and if you didn't already: Read «Zen and The Art of Motorcycle Maintenance». Aside from being a great story, it goes into detail about how technical work becomes art when done with Quality in mind.

</comment></comment><comment><USER43> How neat to see this little article pop up from 1985. Professor Neil Rickert was one of my computer science profs while I was at Northern Illinois University. He was a pretty solid teacher and beyond a doubt, knows his shit in and out. Definitely a highly respected professor within the computer science ranks. He's now retired or Professor Emeritus now, I believe.

</comment><comment><USER44> And if the specs change after the code was written (as usually happens in real life), who's code would have been easier to update? There is a reason experienced people may put more effort in to certain areas they junior programmers, they will have an idea what is likely to change and when.

</comment><comment><USER33> Oh god, this thing's actually getting traction here.

Look, there's no moral to this story and very little to glean from it because it's about a situation that's ridiculous on its face. It's written to appeal to cowboy programmers to make them feel better about their prejudices in software development.

Can _any_ of you actually relate a real-world case where a 4-month-long team- driven effort produced some code to solve a problem that could be solved by one cowboy in 3 months and 20% as many lines?

<comment><USER15> Yes. I worked at a company that spent hundreds of thousands of dollars, and nearly a year, on a server monitoring system that never acheived a high enough timeseries resolution to actually solve the problem it was funded for. Then a 20-year veteran of the company stepped in and wrote a 50-line shell script, pushed it to the relevant machines, plugged it into the timeseries database, and solved the problem. He called it his 89¢ solution.

<comment><USER33> Eww. Were there extenuating factors though? The monitoring system was somebody's pet project, or was purchased under contract on the hopes and dreams of sales, or the monitoring software did work but not in that specific environment, or...?

<comment><USER45> I've seen this exact same thing too. The "extenuating" (if you could call it that) factor was that the monitoring software was written in house and it was just shit. It might have been a pet project initially, but it didn't end up that way. It was just continued out of some combination of habit, risk aversion and not invented here syndrome.

When dumped and replaced by one of the better OSS versions in a few days by a developer who got fed up, things "magically" got much better, very quickly.

No praise or career boost at all for the developer in question, though. I think a large number of people (from management down) were embarrassed by the whole affair and wanted to forget about it. It seems that praise can only be dished out if you didn't embarrass somebody important.

</comment></comment></comment></comment><comment><USER46> Thanks. I have read this many years back, but could not find it anymore.

</comment><comment><USER47> I can't wait to get out of software development.

I'm just a couple of years removed from uni and I'm already planning my exit. My first corporate job was a huge eye-opener. This type of stuff left and right with zero career advancement and complete disdain from corporate.

I'm not even thirty and I plan on retiring and starting my own business (tech or other) by the time I'm 40. The only good thing about tech is that I can actually find a job and that the pay is above average giving me the opportunity to take the money and run!

It's a complete shame too because I enjoy solving problems through code. I love learning about new technologies. But everywhere I look software developers are completely screwed, absolute wasteland of an industry.

<comment><USER48> This comment is more for others than for you, but there are good companies out there that are engineering focused. Almost none of them are corporations in which "software" is just one division of many,

</comment></comment><comment><USER49> If we pretend this was a real story, Charles's manager should really have spoken to Charles about playing Space Invaders for 2 weeks straight. While Charles may be getting some valuable thinking time in, I can imagine he's also pissing off his colleagues who will feel they're working to support a guy messing around.

The exact nature of that depends on Charles, his manager, and the company, but it is possible to have those conversations without diving in and accusing Charles of goofing off.

Also, the manager made a huge mistake in judging the code based on what he saw. He should have spoke to Charles about this and tried to glean some insight into how it came to look so easy. If I'm speculating, the manager was looking to punish Charles for his behaviour and went about it completely the wrong way.

<comment><USER50> And that is why this is a parable—not a real story, and not intended to be read as one.

</comment></comment><comment><USER51> This parable is somewhat untrue, as it pats over the "good students engineers" shoulders, while throwing "cowboy programmers" out in the cold.

Unless you are producing libraries or frameworks, management don't care about internals of software. It's an engineers' problem next time they ask for a modification. Management care about having their problems solved. That's why relations between management and engineers are so notoriously dysfunctional: engineers want to produce art, while management wants to sell stuff to customers.

A manager inspecting a code? Really? A manager congratulating with engineers for releasing a half-working software while going off budget? Seriously? Managers hate engineers as much an normal people hate lawyers: they make everything sound way too complicated to squeeze more comfort zone to roam into.

Lone cowboy programmers that can conjure working stuff in a minimum time are praised by management, and insulted by colleagues.

And, since this parable was probably written by a disgruntled, good scholar engineer, I think this whole story is a little biased...

<comment><USER52> I think you missed the point.

<comment><USER53> ...though the idea that "engineers want to produce art, while management wants to sell stuff" has a lot of truth, and does have oblique relevance to the post, in the sense that Charles' "goofing off" was about thinking about the best way to abstract the problem and write it elegantly and concisely.</comment></comment></comment>


SQL Databases Don't Scale - <AUTHOR> http://adam.blog.heroku.com/past/2009/7/6/sql_databases_dont_scale/ <comment><USER2> I've been an Oracle database architect for almost 20 years.

His whole concept of "SQL doesn't scale" is the typical crap I always hear from people that are either not database experts, are using the wrong database technologies, or don't know what they're doing. More than likely a combination of all three.

And just because you can create an object model, and a simplistic data model, does not make you an architect of large, scalable database systems.

I have, over the past 4 years alone, built Oracle-based, fully scalable databases that handle over 25 million users daily.

Go read up on their RAC architecture, and the "shared everything" implementation.

Sure, it's expensive, but it works great.

For instance, if you play sports games from the world's largest video game corporation, all of your online transactions (achievements, etc) go through exactly such a system that I spent a year architecting and implementing.

If you do any online banking in Canada, or with some of the larger banks in the US, that, too, is on my resume.

I find that this type of FUD comes about from people that aren't good at designing and implementing large databases, or can't afford the technology that can pull it off, so they slam the technology rather than accept that they, themselves, are the ones lacking.

Most of them tend to come from the typical LAMP/SlashDot crowd that only have experience with the minor technologies.

Those of us that do it for a living, using the right technologies, seem to have no problems whatsoever scaling SQL.

Just saying.

<comment><USER3> You totally ignore the background of the author -- his company Heroku : Ruby/Rack :: Google AppEngine : Python/WSGI

But there's a huge problem -- AppEngine succeeds at seamless multi-tenant truly-distributed clustered hosting thanks to BigTable. Heroku needs to support standard Rails apps, so Postgres is the best they can do, and it's a huge hole in their offering.

You just _can't_ make Postgres (or Oracle) scale on an ideal horizontal the same way you can distribute IP, DNS, HTTP proxying, HTTP serving, memcache, message queues, or bigtable. You can't expose Postgres as an ideal service that just keeps up with what you throw at it.

<comment><USER4> WRT exposing Postgres, you're right that you can't simply expose a database and then expect the DB to scale under random selects, inserts, etc. (RAC is another matter I guess.)

However, as I said in the first comment to the blog post, if you define an interface using stored procedures (a pattern familiar to many Oracle DBAs), then PL/Proxy (<http://pgfoundry.org/projects/plproxy/>) lets you do hash- based partitioning in a way that's more or less transparent to the end-user of a DB, again assuming that it has a defined interface. The PL/Proxy installs form a 'bus' between the DB and the user.

Self-promotion: I'm currently working on hacking PL/Proxy into something that can be used to auto-scale a Postgres cluster on-demand, which has interfaces as a pre-requisite, along with some other things. The end-goal is to do exactly what you say: to scale-out Postgres like any other internet service on an ideal horizontal. Link: <http://code.google.com/p/hotrepart>

(Hum, I'm gonna get accused of spamming for repeating myself so often :-)

<comment><USER5> While Skype's PL/Proxy is a great way to make PostgreSQL more scalable, it doesn't do much to refute the basic argument that SQL databases aren't scalable since the SQL it helps you scale is limited to short RPC style operations.

<comment><USER4> That's a good point, and it brings to light an unspoken assumption underlying my post, which is that the use-case is a web-based, read-heavy OLTP-style system. If you were thinking of things like OLAP and data warehousing, then I'd agree with you absolutely.

However, under my re-qualified assertion :-) for large, complicated commits, the logic would either have to be at the database level for it to be in the same transaction, or a solution using temporary tables could be put together for more convoluted calls.

Neither of these are elegant, I'll grant you, but the two basic approaches - longer transactions over logic closely coupled to the datastore, or staged writes - are what most DBAs on high-end databases end up doing anyway, and would probably be reproduced in some form or another in any ACID system, no? Either way you'd still have a database that scales.

</comment></comment></comment></comment></comment><comment><USER6> Okay, see... here's more of the no-SQL agenda at hacker news. This isn't a question of "Does SQL Scale or not?" but "How much do SQL Databases Scale?"

I feel like the propaganda here is that because RDBMS doesn't scale to youtube or google scale they _suck_ and that's not true. Like SQL is a waste of time because at some point, you're going to need to shard your database.

Look, at _that_ kind of scale, you're going to have problems with any solution to any problem. Handling that kind of scale is going to be expensive no matter what solution you implement, whether it's map/reduce or flat files or some other solution.

But deciding to build a system from the beginning on something non-relational because someday you may have to accommodate that kind of scale is an example of premature optimization. The vast majority of features you get with SQL are going to outweigh the limitations of noSQL.

I've worked on some pretty high scale systems built on SQL and yes, there are problems, but there's just something irrational going on here and it's off- putting. It's like we are throwing out the baby with the bath water or something.

<comment><USER7> As others have pointed out, the "no SQL" crowd are invariably MySQL users who have run into the limitations of MySQL but for ideological reasons can't state that the problems they encounter are specific to MySQL.

DB2, Teradata and Oracle users regularly tackle problems 100x larger than MySQL can handle.

<comment><USER8> Agreed. I also fund it hard to sympathize with these startups having ambitions to scale to Google-like sizes, yet are unwilling to pony up cash for a proper database system like Oracle or SQL Server.

Seeing the amount of ugly hacks people are willing to come up with and employ and features they are willing to cut, just to handle _trivial_ loads, kinda makes me think that MySQL can only be considered free if your time is worthless.

<comment><USER9> I agree with you with a caveat. Everything you say is absolutely true, but remember that many startups are highly focused on conserving cash, and moreso than hacker time.

The retail price (I know discounts can be negotiated, but for a point of reference...) for MS SQL Server Standard edition is $5000, enterprise edition is $25000. I have never had to research Oracle prices but I understand they run even higher.

I worked as an MS SQL Server DBA for a while for a mid-sized company, and I wrote and employed some "ugly hacks" to emulate some of the Enterprise features because management at the time was unwilling/unable to pay for Enterprise Edition.

<comment><USER7> SQL Server and the rest of the Windows stack are effectively free under the BizSpark programme.

</comment></comment></comment></comment></comment><comment><USER10> RAID doesn't meet his definition of "scalable" because it has a central controller.

This whole post could be summed up as "ACID doesn't scale", which has been proven. Consistency, Availability or Partition Tolerance; pick two ([http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1495)).

Good introduction to non-ACID databases: <http://highscalability.com/drop- acid-and-think-about-data>

<comment><USER2> Oh please.

The mere fact that he's talking "RAID" instead of SAN speaks volumes. (No pun intended). Any storage engineer worth their salt would be rolling their eyes right now.

The doc you linked to was authored in 2002, about the same time that Oracle's RAC was introduced (late 2001). Some of his citations are from the 80's. THE 80'S!

DB technology has come a LONG way in 8 years, and that paper is no longer valid, unless you're talking about some basic, "minor"/open source db technologies.

If you want to say "open source DB technologies have problems scaling", then go right ahead, and I'll agree.

Just don't mind those of us who continue to build large, scalable systems, using the proper DB technologies, that disprove that "sql doesn't scale" generalization.

<comment><USER11> SANS are too expensive. They don't scale cost-effectively compared to commodity PC hardware.

<comment><USER2> I'd beg to differ.

Go take a look at Adam Leventhal's work with the Fishworks stuff.

Specifically, go check out the Sun Storage 7310.

It will scale HUGE, and is nowhere near the stupid cost of NetApp or EMC or the other major vendors.

I'd love to see how a bunch of commodity PC's will scale to 100TB, and still be manageable, and have anywhere near the same feature sets.

Again, if you're railing against something as ubiquitous as a SAN, I'm not sure there's anything I can say to change your mind.

Not that I'm really here to change your mind.

Again, the original focus was about SQL not scaling, and you seem to be fixated on the cost of that scaling.

<comment><USER12> _I'd love to see how a bunch of commodity PC's will scale to 100TB, and still be manageable_

100T is 666 spindles when you go RAID10 with 300G drives (common size in the SAS/FC area).

If you go S-ATA then it'll fit on 200 spindles using 1T drives. I'll stick to the latter variant for now because I'm too lazy to lookup Sun's pricing for SAS spindles, for my comparison below.

So, 200 spindles amounts to roughly 15 hosts (throwing in a few spares for good measure). The whole setup will comfortably fit into _one_ rack, including the FibreChannel machinery and other fluff that you'll likely want.

Thus from the hardware side this is trivially managable, 100T is just not a lot of data nowadays.

On the software side it's up to your creativity and mostly depends on _what_ you actually need to store. I've seen people setup commodity postgres clusters, as well as more fancy things like HDFS, GFS or homegrown storage layers that way. And it worked.

And, regardless of the indeed relatively sane pricing of the Sun (formerly StorageTek) products, the bottomline is what makes the difference.

In figures, for a 100T SAN on the 7310 you're looking at something like $50k for one head, plus around $75k for three trays. We're in the $125k ballpark, hardware-only. And I'm being rather optimistic here: This setup actually holds only 96T and the head is _maxed out_ (3 trays max per controller/head). That means your next upgrade will incur another $25k markup for the next head, good thing you didn't ask for 150T...

Squeezing the same amount of storage into 15 min-spec supermicro pizzaboxes I arrive at roughly $3000 per node, including spindles. A good buyer will get them cheaper. This commodity cluster sets us back only ~$45k in hardware.

That's 1/3 the price of the 7310 solution, being _optimistic_ on the Sun and _pessimistic_ on the commodity side.

That kind of difference makes up for a lot of development effort for the custom solution - most of which is a one time investment anyways and yields better flexibility in the long run. It's also the reason why most of the big boys don't use off-the-shelf SANs for their primary storage.

<comment><USER13> FWIW, I've built one of those SuperMicro machines, with eight drives, around the beginning of the year.

Allowing for redundancy (RAID 5 on six disks for data, and mirrored the boot drives), we ended up with 6.5TB of storage at about $3500 (that includes i7 proc and 12Gb RAM, and a fancy controller). My labor added some more on top of the $3500.

Mostly, we've been happy. It is more sensitive to heat issues than our HP G5s, and of course, generates more of that heat. If I were to go with any kind of density, I'd need a much more robust cooling solution.

<comment><USER12> Yep, that spec would be over the top for a storage node, though. A large chunk likely went into the controller and the i7 whereas in a storage-node most cheapo controllers (i.e. 2x8 is cheaper than 1x16) and whatever old xeon/core2 will do.

Wrt cooling, for actual servers (i.e. not storage nodes) we've had good success with Sun XFires, the 4100+ range. They are very well built and the markup over the SuperMicro junk is minimal (around 15% last time I checked). Among the niceties is a nice array of hot-swap fans - something that SuperMicro still doesn't seem to deliver in their popular chassis.

I'd also consider the xfires for storage nodes if they'd take 3,5" drives, but afaik all their low-end models only have max eight 2,5" slots. That's just no worthwhile density when compared to the larger SuperMicro tins (which go up to 30x3,5" now I think).

<comment><USER13> Most of the money went to the hard drives themselves. They've come down a lot since (1.5TB had just been announced), but it was around 70% of the cost. Everything else was relatively cheap.

The 2.5 drives are good, and seem to becoming typical, because they run much cooler. We've got some G5s in the same closet, with just as many drives, and they don't run nearly as warm.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I'm the author of Redis so I should be biased the other way around, but the Redis and KV experience taught me that to be exposed to the KV parading was for me a similar experience as learning the Scheme language, I started to write code in imperative languages in a new way. In the same way once you start thinking at scalability of your data in a new way, from the point of view of partitioning the data, organizing this data in away that is easy to access for your usage pattern, make judicious use of serialization, SQL databases can be a good pick. Simply you need to abandon the paradigm of _let's design our nice tables and run our multiple joins and group by against_.

But of course designing DBs in this new way makes most of the SQL features not needed in most scenarios... and you still have the overhead. And there are a number of other limits now that complex designs are not a good idea, for instance there is no way to get back the data in the natural ordering (the order you pushed this data, or the reverse)...

This is where KV stores start to be interesting as real world alternative, not just in order to learn the paradigm of scalability. But again, if you don't trust KV stores it is truly possible to use an SQL database in a more conservative and scalable way.

</comment><comment><USER5> _SQL databases are fundamentally non-scalable, and there is no magical pixie dust that we, or anyone, can sprinkle on them to suddenly make them scale._

I find this claim laughable. If the databases Mr. Wiggins chooses to work with fail to meet his scalability requirements, perhaps he should consider different databases. Scalable SQL databases have been around for over 3 decades.

<comment><USER15> Your comment would hold more weight if you elaborated some more. Are you referring to scaling by his standards? Please explain.

<comment><USER5> Mr. Wiggins would have us think in terms of "true scalability" which conflates the following concerns: more servers creates more capacity (the classic definition of scalability), the business logic of the app is separated from concerns of scaling server resources (this is not possible past whatever limit you set and so has no classic definition) and no single point of failure (more classically formalized as availability).

Companies such as Teradata have long offered SQL systems which meet the classic definitions of scalability and availability.

I think TimothyFitz's reply above was accurate. Mr. Wiggins article would be better titled something like "ACID databases have scalability problems, especially cheap ones startups use" but then, like <http://news.ycombinator.com/item?id=690653> , it wouldn't get much response.

</comment></comment></comment><comment><USER16> _So while sharding is a form of horizontal scaling, it fails point #2: it is not transparent to the business logic of the application._

I do not believe this is usually true, for two reasons. One may be nitpicking, but 'where to get the data' is not part of the business logic: it's pure application logic, dependent on your solution of the problem. In that sense, his argument is wrong. The other reason definitely isn't nitpicking: you can solve the problem by adding a layer between your DAO's and the databases, that handles the 'where to get the data' question. So yes, it requires some programming, but it is still transparant to the business logic. It does not require an invasive change in your application and I think he is grossly exagerating this point.

<comment><USER17> I don't see a good reason for "which server has my data" to be in-your-face application logic to code, when "which sector of which disk has my data" has long since been delegated to the platform and forgotten.

<comment><USER16> If you are bound to SQL databases, either for historical reasons or because the no-SQL database make other problems harder, then 'scaling the application' is a pretty good reason for writing that logic. There is no silver bullet.

</comment></comment></comment><comment><USER18> Crazy idea: Write your data-handling code in it's own tight little module. Use good abstractions so that the rest of your app doesn't give a crap HOW it's happening. When it's time to update to millions of clustered servers running bigTable, you rewrite the module, and you're done.

Software Engineering saves the day!

<comment><USER18> 3 upvotes and 2 downvotes without a single response.

As a junior member of Hacker News, I demand an education when I'm downvoted! :)

<comment><USER19> I wasn't one of the ones who upvoted or downvoted you, but just because you asked . . . while abstractions around your data-handling code are always a good idea, on some level they always leak. (For example, see the classic post [http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...](http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx) describing how ORM, one of the most common approaches to encapsulating data- handling code, tends to fail).

Most of your code _is_ data-handling code on some fundamental level, so it's pretty inevitable that it's going to matter to your application how that data is stored and what sorts of operations you can do on it, and that's especially true if you care about performance (which you generally always do after some level). So even if you have a nice abstraction of your query layer, the kinds of questions you can ask the database efficiently depend heavily on the underlying storage mechanism, and so your application logic has to be built so it only asks the right kinds of questions.

Even abstracting away the differences between, say, Oracle and MS SQLServer and MySQL is difficult enough, because of the different capabilities and performance characteristics. When you do that, you basically end up coding to the lowest common denominator, which can often limit what your applications does.

Trying to come up with an abstraction that can encapsulate the difference between a row- versus column-oriented database, or between a relational database and some other kind of storage, is pretty much a losing proposition: they're too fundamentally different in terms of what kind of data you can store, how you can store it, how you can query it, what kinds of transactional guarantees you get, and what operations are fast and which ones are slow.

So you really do kind of have to take your best shot at it, choose an approach, and if you choose wrong and have to change, it's just going to hurt. A lot. Good encapsulation and abstraction will ease some of the pain, but it's more like drinking whiskey before your leg gets sawed off than it is like general anesthesia.

</comment></comment></comment><comment><USER20> I thought it was a good summary of the problems facing SQL databases as organizations grow. However I would have appreciated some solutions to the problem.

<comment><USER21> I think one of the points made at the end was that there kinda isn't one - people have been trying to come up with the perfect solution to scaling RDBMS's for ever and the current state of the art (pretty much) is as described in the article - i.e, not great. People with really massive MySQL setups (eBay, for example) basically just do a huge amount of the stuff described here, but with lots of message-queue type stuff to glue it together and loads of hard work; i.e. you can make it scale but it's really really hard work because RDBMS's aren't inherent scalable.

<comment><USER7> _the current state of the art (pretty much) is as described in the article - i.e, not great_

That simply isn't true.

For me, thousands of transactions per second and 10s of terabytes of data on a single database is normal. It's unremarkable, it's everyday, it's what we do, we have done it for years. And I know of installations handling 10x that. It's only people who's only "experience" is websites that whinge about how RDBMS can't handle their tiny datasets.

<comment><USER21> What hardware is this running on, roughly? What the author was getting at, I think, was not that you can't do it, just that it's hard/expensive; you need fairly beefy hardware and experienced DBA's to manage horizontal scaleout manually.

<comment><USER7> That's a very curious statement, especially for HN. Why would you consider needing good, experienced people to be a _disadvantage_?

<comment><USER21> Because that kind of hardware+DBA team is prohibitively expensive for a startup?

<comment><USER7> Hardware yes, but the basic premise of a startup _is_ that your people are top-notch. Scalability doesn't imply building something up-front that can handle enormous loads - it means building something that can grow with you. As opposed to "oh crap, we've got some load now, better start again" a la Twitter.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> "Sharding kills most of the value of a relational database."

I can appreciate the point the author makes about partitioning schemes requiring heavy integration with the business logic, but I disagree with the claim that sharding doesn't work.

It's probably more accurate to say that sharding only works well if you design your database very carefully, or just get lucky about how your data model maps to sharding schemes. A bad sharded database can probably hobble your app, but a good one does get you remarkably close to true horizontal scaling.

In my experience, at least.

<comment><USER23> If you data model maps well to sharding, it maps well to distributed databases, and you're not gaining much by being on an RDBMS. I think the point they're trying to make is if you're going through the contortions to shard a relational database, you're better off just doing it in a distributed database in the first place.

<comment><USER24> There's more than one way to skin a mongoose and in this case the more common shard solutions are fundamentally different from distributed DB in that a distributed DB often times contains large amounts of a a subset of data that has to be merged with data on other DBs whereas a shard can have entire schema duplication on different shards where you can use relational technology just fine and even if the query is distributed you can just add rows to the end of a dataset rather than joining the data columns manually (implementing your own relational joins). In many cases you partition your sharded data in such a way that the majority of your queries are not distributed so that they can continue to leverage the relational model you had before, only performing a distributed query for more complex actions like reporting and such.

Also going back to the first place isn't really an option, shards usually come of a system that has grown, not ground up design. Ultimately I still support the distributed model myself, but a shard model does support relational data much more so than a distributed DB (at least out of the box).

</comment></comment></comment><comment><USER25> This article is about relational databases that you read from and write to. It isn't SQL-specific. It's a good article, not another "SQL is obsolete" as you might think from the title.

</comment><comment><USER26> In the final paragraph he compares himself with Capt Kirk, facing the Kobayashi Maru: "we can only solve this problem by redefining the question."

Well, perhaps that's as difficult as solving the "SQL scalability that 20 years of brilliant programmers haven't solved"?

...because he declines to _attempt_ to reframe the question.

[ or maybe he's leaving us wanting more: like his next post? ]

Anybody up for reformulating the question?

</comment><comment><USER27> At a management level there are larger problems. SQL was a solution to the "letting programmers run the show" problem. I.e. a commoditized language that executives could mostly understand and budget for. See pretty well everything Philip Greenspun has written.

</comment><comment><USER28> Scale like what? If you aren't IBM, Facebook or Google, why do you even care?

<comment><USER29> ouch, I'm not IBM, Facebook or Google but SQL scalability issues are a good part of my daily workload.

(the other part is made up from file system scalability issues).

Once you you get past a certain level these are non-trivial problems and anybody out there that is busy solving them has my interest.

</comment></comment><comment><USER30> Can anyone give me the context? I don't believe in absolutes. I only believe in "it depends on the application/budget/knowledge/etc"

</comment><comment><USER31> Maybe I am getting old, but I no longer find arguments over semantics as interesting as I once did.

<comment><USER32> I agree, but I'm not sure this is purely a semantic argument. Care to elaborate?

</comment></comment><comment><USER33> Isn't Facebook using MySQL?

</comment><comment><USER8> Summary of an article about how "SQL Databases Don't Scale":

      1. Mentions RAID, not SAN
      2. Mentions MySQL and only MySQL (with the exception of PostgreSQL once).
      3. Mentions Master-slave replication as a killer scalability feature.

I suggest he rename the piece to "A $500 server and MySQL Don't Scale" and then we can all agree and get along.

<comment><USER34> Yeah, there certainly are a few more tricks with regards to scaling RDBMS than the author covered. Depending on what your demands are there are different techniques and protocols which best suite you and can go very far to solving your problem. But with that in mind there may be better ways to solve your problem, and we should not forget about those.

If You start sharding you may get write gains, but you have to work very hard to keep things consistent (depending) and you may have to duplicate shards to make them highly available ($$$). Oh - and later down the track your schema might change in ways which your sharding scheme is just not flexible enough to deal with and depending on who you are that may be too much of a risk.

Besides the issue is really with availability, consistency and performance. It is very hard to scale all three of these together and even your cashcow solutions will hit their limits (although some of their limits are quite high :))</comment></comment>


How can i get traffic to my new blog? - <AUTHOR>

<comment><USER2> Well, as alexknight says, don't think about traffic. Think about readers. Readers are people, and you should be concerned about people, not numbers.

Second, you can read Obsession Times Voice[^1]. It comes from two guys who didn't care about readers, but were passionate about their topics. Now they have a reader or two. :)

Third. Read, read, read and read again. It will not be difficult to find good writers[^2]. This will not only teach you how to write, but also how to "listen". And if you know how to listen, you'll be more sensible to your readers. To what they want to read, to what they want to hear.

Good luck.

[^1]: <http://daringfireball.net/2009/03/obsession_times_voice> [^2]: see, for example, the [Read & Trust](<http://readandtrust.com/>) website.

</comment><comment><USER3> #1 don't think about traffic first. My advice? Be genuine, creative, interesting and insightful. All while trying to add your own unique flare to your writing. Focus on specific interests and passions that you are practically obsessed about. Readership will follow afterwards.

</comment><comment><USER2> Well, you may begin by posting the url[^1]. :)

[^1]: Ok ok, it's <http://www.samevisions.com/>

<comment><AUTHOR> yeah it is .. www.samevisions.com so is there any advices ?</comment></comment>


How does Angular teach you to be a better Software Engineer - <AUTHOR> https://medium.com/@tomastrajan/learn-angular-software-enginner-patterns-architecture-4836ef304b40 <comment><USER2> Unfortunately, the only thing you learn from using a framework is using that framework. Best practice has very little to do with the best solution for any problem, it's a backup for when there isn't enough experience to make a better choice. Learning to be a better software engineer means writing your own code, there is just no way around that.</comment>


Are You a Ninja or a Pirate? - <AUTHOR> http://tracksuitceo.wordpress.com/2007/08/08/are-you-a-ninja-or-a-pirate/ You know the part in Pulp Fiction where Uma Thurman's character states that you are either an 'Elvis man' or a 'Beatles man'. I couldn't agree more but I prefer to classify people as either Ninjas or Pirates. My wife recently blogged about this and our friend Kathleen introduced a new variable into the equation: Monkey or Robot.

<comment><USER2> 5D personality test: ninja pirate monkey robot zombie.

What could these things possibly have in common to make them used in the same fashion in metaphor and play so often? Maybe they all break the rules, in some way.

<comment><USER3> Here's the quickie test: Do you tend to position things as binary options (e.g., Ninjas & Pirates), trinary options ( Ninjas, Pirates, Zombies), or some further set of choices?

There seems to be some difference between those who tend towards the X vs. Y view, and those who tend to see more than simply two options.</comment></comment>


Uber's Flying Car Will Have a Hard Time Getting Off the Ground - <AUTHOR> http://time.com/4662443/uber-flying-car/ <comment><USER2> The article is correct in highlighting some challenges, though I think it doesn't cover all the right ones.

Challenges highlighted in the article that are not too serious, I think:

* Mechanical complications with prior VTOL aircraft: Yes, VTOLs with tilt-wing or tilt-rotor design are mechanically tricky, but those constitute just a small part of the designs that are floated these days. Electric multi-engine multi-rotor concepts (big drones, basically), by contrast, are extremely simple, mechanically.

(Note that the definition of VTOL in the article (vertical takeoff like a helicopter, flying horizontally like an airplane) is unusually restrictive, as it would exclude helicopters or multicopters, btw.)

* Congestion. Yes, new ATC and collision avoidance techniques need to be developed and rolled out. But seriously, there is a lot of space up there, it's a big sky. If it's used effectively, it'll be just fine.

* Safety: "Filling the skies over major urban centers with cars is an order of magnitude more dangerous than filling the streets with traditional cars, since at least an accident on the ground stays on the ground. An accident in the sky threatens everybody below."

Yes, a car on the ground threatens everyone on the ground, and a plane threatens everyone on the ground, too. Planes are much lighter than cars, and carry less fuel. Of course, they accelerate on the way down, but all in all I think the risk is comparable.

A related issue that quote might have alluded to is that aircraft crashing down could hit other aircraft below, but traffic density would have to rise considerably before that becomes an issue.

Challenges not highlighted enough:

* Enough battery performance, with high specific energy (kWh per kg). Progress is being made, but ploddingly. Currently still a fraction of the specific energy of av gas.

* The regulatory environment in aviation is tricky - even though the US aviation regulation is probably among the lightest and innovation friendliest in the world, you can't just launch and iterate, as in startups, for obvious reasons. Regulation and low volume is why a GPS that's only a fraction as capable as an iPad costs $20k when it's certified for an aircraft.

<comment><AUTHOR> you are absolutely right the two bigest challenges are battery density and regulations.</comment></comment>


Ask HN: Is anyone here visually disabled? - <AUTHOR> I have a visual disability that is causing me to slowly lose my sight. I would like to talk with someone working in industry that is blind or visually disabled about how I can enter the field myself. I have a family to take care of and limited time to make something happen. I'm willing to learn whatever I need to, move wherever I have to, and do whatever has to be done to ensure that they are cared for. I'm fairly competent with HTML, CSS, and Javascript, but would like some direction as to where to continue my education as far as real world skills are concerned. <comment><USER2> Hopefully this will be helpful: I found Sina Bahram's talk at !!Con 2016 _How I Code and Use a Computer at 1,000 WPM!!_ inspiring and incredible. He's blind and has his computer read everything out ridiculously quickly, and apparently gets input that way much faster than sighted people can read! Amazing.

 _I use a computer very differently than most people, because I'm blind. When I'm surfing the web, tweeting, checking email, reading the news, and writing code, I'm doing so because a program called a screen reader is reading me what's on the screen. I happen to listen to it read me this text at a thousand words per minute! Join me in listening to how I experience some common user interfaces. Yes, I'll slow it down for you. I also have a challenge for everyone in the audience. Can you get through a day only using the keyboard? What about not looking at your screen?_

 _Sina Bahram is an accessibility consultant, researcher, and entrepreneur. He is the founder of Prime Access Consulting (PAC), an accessibility firm whose clients include high-tech startups, fortune 1000 companies, and both private and nationally-funded museums._

Talk: [http://youtube.com/watch?v=G1r55efei5c](http://youtube.com/watch?v=G1r55efei5c)

Text copied from this page: [http://bangbangcon.com/2016/speakers.html](http://bangbangcon.com/2016/speakers.html)

</comment><comment><USER3> I don't have a visual disability, and don't really have experience with accessibility features for the blind. However, in case it's helpful, I can tell you that I'm very productive with the keyboard and linux terminals, and it seems to me that terminals would be an ideal user interface to use for the blind. It's like a chat window where you're conversing with your computer. I imagine it shouldn't be that hard to modify or extend a terminal so it passes all its output through a text-to-speech program. This would work best with CLI programs, but I imagine it would also be somewhat fine with TUI programs. I think both `ed` and `ex` are fine CLI text editors, for example. Here's a little showcase I did on `ed` on a StackExchange question a while back:

[https://askubuntu.com/a/954841/607795](https://askubuntu.com/a/954841/607795)

It might look a little confusing. By default, ed doesn't have a prompt for user input and its error messages are limited to "?". However, more helpful error messages can be activated with the command `H` and a prompt can be set with `-p`. `ex` is an improved version of `ed`, and comes with a prompt and more helpful error messages by default.

I've been wanting to try making that terminal configuration partly just for kicks and partly to not strain my eyes so much and work with my eyes closed, but this is pretty low on my priorities list. This would be my first attempt if I ever start to go blind, though.

</comment><comment><USER4> Possibly of interest: [https://news.ycombinator.com/item?id=12819482](https://news.ycombinator.com/item?id=12819482)

I co-own a very low traffic Google Groups called Blind Dev Works. The other admin is a blind developer.

[https://groups.google.com/forum/m/#!forum/blind-dev- works](https://groups.google.com/forum/m/#!forum/blind-dev-works)

The topic of blind coders comes up periodically on HN. Here are a few:

[https://hn.algolia.com/?query=blind%20dev%20works&sort=byPop...](https://hn.algolia.com/?query=blind%20dev%20works&sort=byPopularity&prefix=false&page=0&dateRange=all&type=comment)

</comment><comment><USER5> If you search YouTube for "blind coder" you'll find a number of people who have worked out different solutions.

It actually gets interesting because there are blind and visually impaired coders all over the world represented in the first bunch of links that show up.

I have chronic Central Serus Retinopathy in my dominant eye that seems to get worse year by year and leaves me night blind on one side. It's not as bad as what you're dealing with, but I do very much sympathize with you.

</comment><comment><USER6> Old thread that may be useful " _Ask HN: How do blind people code and work with terminals?_ " [https://news.ycombinator.com/item?id=5352608](https://news.ycombinator.com/item?id=5352608) (52 points | Mar 10, 2013 | 21 comments)

<comment><AUTHOR> Thank you I really appreciate it.</comment></comment>


Insane Clown Posse: And God created controversy - <AUTHOR> http://www.guardian.co.uk/music/2010/oct/09/insane-clown-posse-christians-god

<comment><USER2> I don't get it. Is it a joke, a parody, or something real? Does it even matter?

</comment><comment><USER3> Frighteningly pathetic. These "clowns" are the realization of every fictional story about the demise of reason and the descent into foolishness. The enlightenment is alive, but stagnating or trending down.</comment>


Nassim Taleb on the Financial Crisis - <AUTHOR> http://www.econtalk.org/archives/2009/03/taleb_on_the_fi.html

<comment><USER2> Nassim Taleb is a wonderful thinker and writer. The fall of Fannie Mae was hinted in his 2007 book 'Black Swan: The Impact of Highly Improbable' the following sentence is a from his book - "The government-sponsored institution Fannie Mae, when I look at its risks, seems to be sitting on a barrel of dynamite, vulnerable to the slightest hiccup". Not only Nassim Taleb, I remember George Soros referring to Fannie Mae and lurking troubled housing market long before the onset of the financial crisis.</comment>


PRSM - The Sharing Network - <AUTHOR> http://getprsm.com/

<comment><USER2> This is why I love the Internet.

</comment><comment><USER3> Also provides a great catalog of bang-up-to-date web design cliches....

</comment><comment><USER4> _Key Partners: Apple, Facebook, Yahoo, Google etc_

</comment><comment><USER5> Chuckling to myself.

<comment><USER5> Then being a little sad.

</comment></comment><comment><USER6> ahahahah!! seriously.</comment>


This is why you should learn to code (TEDx talk) - <AUTHOR> http://rugb.com/post/24200770266/the-coding-revolution-tedx-talk

<comment><USER2> Awesome stuff guys. Inspiring to hear others put into eloquent words many of my own motivations for wanting to begin my personal coding journey.

</comment><comment><USER3> Great presentation. It's very inspiring to a new coder like myself. You've added a huge amount of value to our class at Code Academy. Thanks

</comment><comment><USER4> Very inspiring talk to anybody learning to code.

</comment><comment><USER5> Nice job! You make some great points!

</comment><comment><USER6> Good presentation, well done.

</comment><comment><USER7> Beautiful presentation!

</comment><comment><USER8> Good talk!

</comment><comment><USER9> Solid!</comment>


How Britain Exported Next-Generation Surveillance - <AUTHOR> https://medium.com/matter/how-britain-exported-next-generation-surveillance-d15b5801b79e <comment><USER2> Tracking and surveillance is everywhere.

Mobile phones: location tracking (they keep the cell IDs your phone is connecting to, with a time-stamp), texts, calls meta-data, calls audio.

CCTV: ANPR, face recognition

Internet: everything

Payments: everything except cash (I'm surprised cash is still legal)

The list goes on.. Public transport, hotels reservations, etc.

<comment><USER3> Cash still covers too many edge cases that electronic devices cannot to be illegal. Also remember less developed countries.

<comment><USER4> "Also remember less developed countries."

Don't worry. American corporations are thinking far ahead.

"Branding Nigeria: MasterCard-backed I.D. is also a debit card and a passport" [1]

[1] [http://edition.cnn.com/2014/09/25/business/branding- nigeria-...](http://edition.cnn.com/2014/09/25/business/branding-nigeria- mastercard-backed-i-d-/)

</comment></comment></comment><comment><USER5> Everytime I try to explain why privacy matters, and why dragnet surveillance is one of the worst plagues of our times, I can't help but link to Glenn Greenwald's talk which explains it better than I ever could:

[https://www.youtube.com/watch?v=pcSlowAhvUk](https://www.youtube.com/watch?v=pcSlowAhvUk)

<comment><USER6> I find this 2006 column by Bruce Schneier to be most lucid and succinct:

 _The Eternal Value of Privacy_

[http://archive.wired.com/politics/security/commentary/securi...](http://archive.wired.com/politics/security/commentary/securitymatters/2006/05/70886)

</comment></comment><comment><USER7> Very interesting article. I've been thinking about this more often recently (perhaps it's watching the 31C3 talks that do it) and I find that I'm becoming increasingly conflicted over the whole issue of surveillance.

On one level, my gut instinct is "mass surveillance of innocent people is wrong"... But the moment I think of it from the law enforcement point of view, I realise how desperately I'd want that bulk data and how damn _useful_ it would be.

I can easily see myself, in another lifetime, being the one who said "Hey, you know if we stick a camera here, I can get a computer to read the number plates and beep if it sees a car we need to stop." \- That's nothing other than a great use of technology to do what a human could do, but much more efficiently. A good hack, nothing not to like about it at all.

At first it'd seem only reasonable to use that technology ONLY to flag vehicles that were known to be of interest at the time. Keeping dates/times/plates of innocent vehicles might not be right. But then again... How seductive to sling all that data into a database. How powerful, how efficient, how god damned _useful_ it would be to be able to go back in time and, for any given number plate, rule a vehicle's presence in or out of suspicion. OK, clearly a possibility of "wrong place, wrong time" for the unlucky, but an equal chance of such historical information actually verifying an alibi, proving that a person of interest is as innocent as they claim.

The extent to which you could get a whole lot of law enforcement done, purely with a big database and some well-written SQL queries... It's seductive. If I were law enforcement, I'd want that /so/ bad.

I wasn't a fan of "you have nothing to fear if you have nothing to hide" before the Snowden revelations, or after. But today I find myself realising just how useful the results of such surveillance /could/ be. I wonder if I've just given in, taken the cowardly way out and somehow convinced myself to be comfortable with the idea of such intrusion because it's obviously never going to end, or whether my mind on the subject has been genuinely changed.

Quite a quandary. Still not sure where I stand on the issue now.

<comment><USER8> In an attempt to help you find out where you stand on the issue (that is, I don't expect a response):

80% of sexual abuse of minors happens within existing social contexts, that is "family and friends".

It would be useful to place cameras in every single private room and have them be automatically monitored and the live feed passed to some on-staff LEO when software considers anything suspect.

Are you at peace with that? If so, why? If not, why not?

(Yes, it's an extreme example. Both in terms of privacy intrusion and in the potential of helping law enforcement with a 'worthy cause'. It's why I think this example is particularly helpful to consider one's position)

<comment><USER9> This is not an extreme example. What is extreme is looking at the world from the law enforcement perspective. Why not just lock everybody in the prison already, perfect conditions for surveillance and control.

<comment><USER8> It is an extreme example in that everything more intense (at least of the scenarios that I can come up with) requires a qualitative shift, such as depriving people of additional basic freedoms (eg by locking them away), not merely a quantitative like moving cameras closer to home.

</comment></comment></comment></comment><comment><USER10> Meh, it's an inevitable effect of the lowering cost of cameras and image processing. In a few years we will have 'social' data sharing networks (analogous to the blockchain) that will share results of analyses of all sorts of cameras worn by regular people every day and everywhere they go, basically a 'decentralized' pervasive monitoring system, fed by cameras everywhere - shops, car dashboards, phones, on private property, ... Think Facebook tagging is creepy, just wait until you get home from work and find a website with 50 pictures of you during the day in all places you were... Just a few people who contribute footage will be enough to map the vast majority of people. Imagine 10 people walking around in a shopping mall with a Google Glass and a dashcam; with enough processing power, that would be enough to map the locations of thousands of people per day.

I used to care, years ago - but there is no escaping it. The real question is how can we deal with such pervasive monitoring? I don't think anyone has a real answer, or has even tried to answer it (note that I'm not talking about pervasive monitoring by just one actor like the state, since what we will experience will be monitoring of all, by all).

<comment><USER11> Well, think about Star Trek --let me finish!-- the computer on the Enterprise always knew where everybody was and it didn't concern anybody unduly. As ubiquitous surveillance becomes pervasive we are confronted with the task of growing into a humane and healthy world polity.

<comment><USER12> It's also worth remembering, no one on board the Enterprise was a member of the public, per se. The Federation is a quasi-military organization, and I don't think anyone wouldn't expect the military, or even a defense contractor or high-tech lab, to at least make sure they know where personnel are at all times ... and in that light, the surveillance on the Enterprise seemed almost lax.

In one episode, crew and officers were being transported while they slept to a pocket dimension and having their organs rearranged by sinister aliens. You would think at the very least, that would set off some alarms. But the computer never seems to keep track of people's whereabouts unless someone asks (for drama's sake, obviously, but still) or even that the first officer apparently was missing a kidney they had only twelve hours ago.

I don't remember getting a sense that the computer was actively keeping track on everyone's position, and constantly recording their movements, keystrokes and conversations.

<comment><USER11> You're right, of course, but as you say a lot of what we see in the show is for the sake of the drama. I think there's no way to put the genie back in the bottle when it comes to our technology enabling ubiquitous surveillance: How can you be sure that everyone is obeying policy (around how to use the collected info) unless you have a surveillance system to watch them in the first place?

It doesn't matter what we think the policy is if we can't control the "root" of the system, and we can't be sure we control the "root" without being able to check on people (ourselves) to make sure they haven't somehow wrested control from us.

"Trusting trust" gets even more crucial once nanotech starts to hit.

I don't like it but as far as my analysis has proceeded I can only imagine a humane-but-totalistic system being workable, and the best most widely-known image of such is (I think) Star Trek. ;-)

<comment><USER12> I'm not entirely sure I agree with the premise that ubiquitous surveillance is unavoidable and unstoppable. To me, that attitude seems half like a cynical cop-out and half cyberpunk wish-fulfillment. No infrastructure which requires as much complexity and cost and effort as that does, is immune to political, economic or societal forces.

Already, you can begin to see pushback from other (many themselves) government and some companies like Apple, who both may be genuinely bothered by government intrusion and see "privacy" as a near-long-term necessity for selling products domestically but more importantly globally. It's true that Facebook is creepy, but it's also true that people have known that Facebook is creepy for years now and young people are leaving in droves.

Of course, _nearly_ ubiquitous surveillance would be much more likely. Probably not all of our worst nightmares, but more than enough.

I personally believe (I even wrote a terrible paper about it that will never see the light of day) that the biggest and most pervasive threat to freedom in regards to privacy will lie in the intersection of (not strong but good enough) AI, social media, and the internet of things. Essentially, we're coming to a point at which our devices will be designed to interact with us emotionally, as well as socially, and as a result people will be trained to form deep emotional relationships with products as well as people. Imagine having a deep intellectual conversation with someone online, only that someone is a refrigerator, or a car. Imagine most of the friends you've grown up with are products, because most of your interaction is online.

Maybe it happens, maybe it doesn't, but almost certainly it won't happen the way we currently predict. The future right after the moon landings isn't the one anyone would have predicted. We were supposed to be drinking Coca-Colas on Mars by now.

Although _if_ it did happen, then i'm still not entirely certain the 'humane- but-totalistic' model necessarily works. In theory, yes, but in practice, if everyone knew everything about everyone else, this wouldn't necessarily balance power between the weak and the strong (and imbalance which exists in the real work, but not Star Trek) but would enable the strong to more easily dominate the weak. Because such systems can't be perfect, there must always be ways to exploit information asymmetry. Governments, corporations and criminals will always be more able to rig the system than will the common person.

I like Star Trek, but because it presents a Utopian ideal, i'm skeptical of using it as a springboard for describing actual potential future societies, because humans just don't work that way. Every other species on in the franchise was more human than the humans (purposely, because they were there to be mirrors on the 'unevolved' aspects of human nature.)

<comment><USER11> Very good points, and I agree wholeheartedly that the confluence of "good enough" AI, mass data on social interactions, and ubiquitous networked sensors+cpus means that we are rapidly entering a sort of intense feedback system with ourselves that calls into question the very meaning of being human, and that it could be a threat to freedom. ;-)

It is definitely neither cynicism nor wish-fulfillment that makes me think the future system (assuming we don't simply destroy ourselves or degenerate into some N. Korean nightmare) has to be totalistic, and that it will be humane.

I think it _has_ to be "total" in the sense that in order to apply and enforce _whatever_ policy we have, including policy around who gets to access and use surveillance data, somebody somewhere _has_ to be looking at _all_ the data and searching for violations.

Flipping it over, I don't see how any government can say to its people "Hey, we know for sure that no one is spying on you. (Except us.)" without spying on everyone to make sure.

So I don't see how we can avoid the technology _forcing_ the "political, economic or societal forces" to adapt, rather than the other way around. At best most people would be content with some privacy-protecting measures that other people would simply find ways to circumvent, and since the circumventors have greater ability to act without the contented people even knowing about it, how would you stop them?

Effectively the U.S. agencies and their allies are already merging into one large "trustworthy" (for some measure of trust, for some subset of humans) information processing system.

Now, if we accept that _somebody_ is going to have the panopticon the immediate concern becomes the nature of our rulers. I think the future cyber- totalitarian regime will be humane, but only because I have hope that humans are intrinsically good.

I have no hope that we can roll back or even curb the capabilities of our technology but I feel confident that we can enshrine and effect our highest values within the system we are so vigorously constructing.

</comment></comment></comment></comment></comment></comment><comment><USER13> People worried about surveillance should read the story "The Dead Past" by Isaac Asimov. Here is a link to a copy of it [1]. It makes a point, which is probably not apparent until the twist ending, that is often overlooked (although I see a few commentators here have touched on it).

[1] [http://www.redlibrary.net/ScienceFiction/Asimov41/27323.html](http://www.redlibrary.net/ScienceFiction/Asimov41/27323.html)

<comment><USER11> Also "The Light of Other Days" by Sir Arthur C. Clarke and Stephen Baxter.

</comment></comment><comment><USER14> > ANPR IS A BRITISH INVENTION: created, developed, and tested in the UK. Its > first major outing was in 1984,

1984! What a coincidence.

</comment><comment><USER15> These systems have a side purpose, some might argue a primary purpose, which is to maintain control of the generql population. People who are likely to protest, regardless of what their beliefs are, are a potential dangerous threat to the status quo. They can be used to stop and harass members of the public who have been tagged as trouble makers. Sheeple are the ideal population, not those who question authority and submit FOI requests.

Surveillance on the other hand is easy. Everyone volunteers to carry a tracking and bugging device with them at all times and pays a monthly fee for the privilege. It is called a mobile telephone.

</comment><comment><USER16> Well that clinches my decision.

I've been getting around on public transit for quite a long time, but have been thinking of getting a car.

Now I've decided not to.

I'm a generally law-abiding citizen, but I simply do not wish to be tracked. How would you feel were someone to follow you around everywhere you went? Even if they kept their distance, never spoke to you our overtly harmed you in any way, it would be very disturbing.

<comment><USER17> I guess it depends where you are but UK cities are right up there with surveillance on public transport too, both trains and buses[0]. Transport for London have a system that detects if you're still on a platform after a train to each destination has departed, and alerts a human - ostensibly in case you're contemplating suicide or otherwise need help. It stands to reason that implementing the likes of facial recognition and "Gait DNA"[1] is high on the agenda if not already functional.

Not to mention the huge incentives (>50% discount) for using a traceable RFID card as your "ticket" instead of paying with cash.

[0] [http://boingboing.net/2009/08/31/london-bus- with-16-c.html](http://boingboing.net/2009/08/31/london-bus-with-16-c.html) from 2009 - newer buses, e.g. the 2012 "new" routemaster may well have more.

[1] [http://news.bbc.co.uk/1/hi/programmes/from_our_own_correspon...](http://news.bbc.co.uk/1/hi/programmes/from_our_own_correspondent/6995061.stm) from 2007.

<comment><USER16> Fuck.

I'm never leaving my house ever again.

<comment><USER17> That's just what they want - at least you won't be out spreading nefarious ideas that they can't monitor, and starting the revolution.

 _Now sit down here like a good little citizen and watch this lovely entertaining "programming" we have for you - and don't forget to buy some of the products we show you too - you know you need them really._ ;)</comment></comment></comment></comment>