African Startups Are Increasingly Attractive to Investors - <AUTHOR> http://afridigest.com/african-startups-increasingly-attractive-investors/?utm_source=hn&utm_medium=hn&utm_campaign=hn <comment><USER2> I feel the need to make a top level comment here.

I am in West Africa right now, have been to 15 countries in 12 months, and will visit another ~22 over the next 12-18.

CNN, Fox, the whole western media are not telling you the truth about life here. They are showing you the sensational stuff that makes headlines, nothing more. Because of that, anyone that has never been has very little information about the realities.

The comments in this thread are so far from the truth they are a disgrace. People are commenting here that clearly have no actual experience, and are just parroting what the media said about africa in the 1980s. It is not the 1980s now.

Comments about constant war, "most African countries already have huge problems to provide even basic needs to already existing population", etc. just show how ignorant about the realities here people in the developed world are.

There is a massive, massive amount of development here, and hundreds of millions of extremely happy, friendly and kind people pulling themselves up into the middle class and beyond.

If you "think" otherwise I challenge you to come here and see for yourself. You will be utterly shocked (I was, after years and years of research and talking to >50 people who have done what I am doing now)

<comment><USER3> The thing is, Africa is also a huge continent. So, if something bad happens in Somalia people in the west assume that all Africa is in big trouble. In the west we have no sense of how big Africa is and work under insufficient information, e.g. I know someone who has a travel company in Uganda and when ebola broke out in West Africa, people canceled their trips and business plunged. There were no ebola cases in Uganda. The US or Europe were effected more by the ebola outbreak than Uganda [1]. The vast majority of people in western countries, don't understand Africa.

[1] [https://en.wikipedia.org/wiki/West_African_Ebola_virus_epide...](https://en.wikipedia.org/wiki/West_African_Ebola_virus_epidemic#/media/File:Ebola_Outbreak_Map_\(ongoing\).png)

<comment><USER2> > _The thing is, Africa is also a huge continent. The vast majority of people > in western countries, don 't understand Africa._

I agree 100%.

Said in another way, the Western Media is doing a terrible job of informing people in Western countries about Africa.

Having been here a year, I now go so far as to say the Media are doing a negligent job. It's disgusting and is causing real harm (as you illustrate).

<comment><USER4> > the Western Media is doing a terrible job of informing people in Western > countries...

</comment></comment></comment></comment><comment><USER5> As an expatriate Kenyan, looking back at home over the last few years has shown a huge increase in investment by both MNCs setting up there and investors flocking to back local companies. But it's usually a huge wave of euphoria, helped by a government that wants to appear welcoming, which then peters out as the company projects get bogged down in corruption, resource volatility and inconsistent outflow of human capital. Eventually it becomes a sunk cost but the company continues to operate there low-key while they look for other strategies.

I suspect a very similar situation is happening in many other African states that are pro-investment.

I would say that a key thing to bear in mind is that investments in Africa are first and foremost just that: investments. They could fail. And treating it as a homogeneous body is akin to saying you're investing in North America instead of saying you're investing in a specific company in South Carolina because of xyz economic, social and political factors.

</comment><comment><USER6> I'm a very happy investor in Ensibuuko, mentioned in the article above. My hypothesis is that Africa over the next two decades will look like India and China the previous two decades. There will be a large Alibaba-like company that emerges from Africa.

<comment><USER7> I've seen this prediction about Africa for the past 20 years. And it's probably even older than that. It's not a particularly bold one, in my opinion, but it is a flawed one.

Africa is not a country, it is a continent. Comparing it to India or China (whose economies haven't really paid off for foreign investors as much as you'd think) is a major flaw. China and India have an incredibly consistent society from corner to corner and well organized governments. Africa on the other hand is a few dozen sovereign countries, without a common culture or language between them. They are constantly at war with each other and within each other.

I think in order to extract the full economic potential of Africa you'll need to see unification at levels that put the EU to shame and at least a decade of trusted, non-corrupt, forward looking governance.

I think it'll happen, but not for a very, very long time. Until then, follow the Chinese govt investments in Africa and try to tag along.

<comment><USER8> _India have an incredibly consistent society from corner to corner and well organized governments._

That is literally the first time I have ever heard anyone, Indian or not, describe India that way.

<comment><USER9> I've been to India several times, and as a foreigner looking from the outside, I can say that it has much more consistent society than it may look to the Indians. The government, however corrupt, is still way better than what most African countries have.

<comment><USER10> And India is far less fragmented than Africa.

<comment><USER11> They have like a dozen languages in like 5 different scripts. Their advantage is that English is ending up as the common tongue of India, so there's lots of English there.

<comment><USER12> More like 22 official languages in 10 scripts.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> And they should be. It's a big continent with lots of people a growing middle class and lots of room for all sorts of development. Im sure there will be some pushback about foreigners investing and making money off locals, but that's kind of the price of progress. Someone has to be the miss moneybags, be it locals or non locals.

<comment><USER14> Africa's population is projected to ~quadruple to approx 4 billion by 2100 (will have almost as many people as Asia at this point), and will account for most of the world's population growth to 2050 (1.3 bil+). [1] It's a huge opportunity, and good luck to anyone who can provide value for the burgeoning population.

[1] [https://esa.un.org/unpd/wpp/Publications/Files/Key_Findings_...](https://esa.un.org/unpd/wpp/Publications/Files/Key_Findings_WPP_2015.pdf)

<comment><USER9> Considering how most African countries already have huge problems to provide even basic needs to already existing population, I can't see how that is a good thing. It seems to me that Africa does not lack headcount now, it lacks stable society and opportunities to emancipate vast masses of dirt poor people...

<comment><USER15> I agree. Out of control population growth can of course be spun as an economic opportunity, but it first and foremost feels like a humanitarian disaster waiting to happen. Not only for Africa, but for the world at large.

On the bright side, economic investment, growth & development might be one of the best ways to eventually curb said population growth.

</comment></comment></comment></comment><comment><USER16> The best way to know what demand for a product is to ask yourself, "What do I need?" The people who know what demand is in Africa are people in Africa who ask that question. We can't answer it in San Jose. The solutions to their problems will come from within.

<comment><USER17> Other countries can help. "What do I need?" Answer:"scalable, mobile first (only) blah blah." If you don't know any of that, the how's, you can get outside help. Hopefully outside mentorship that comes from outside money.

</comment></comment><comment><USER18> Very encouraging to see this level of interest in investing in African startups from SV investors and not just from traditional impact investors.

There is an incredible amount of opportunity to build mobile digital services targeted at markets where offline functionality is a must and low-end Android devices are the norm. Hopefully the interest and investment in fintech will also mean that payments infrastructure will continue to improve and get relatively cheaper over time.

</comment><comment><USER19> Reading some of the overly negative comments, I'd like to add some perspective. Africa might not make sense to compare to India and China earlier, but I like to often compare it to another troubled region, the middle east.

We have seen far more positive developments towards democracy in Africa than in the middle east. Military conflicts in Africa seems to be winding down, while they just seem to get worse in the middle east.

More religious diversity, not just Islam, I think is a gain for Africa. I don't think they will get bogged down in religious extremism as in the middle east.

To those who claim unified India and China as such a big advantage. I think being unified has just short term advantages, but lots of longer term problems. Look at Europe. A key reason Europe sped past China in the past, was because it was NOT UNIFIED. No single stupid leader could ruin European progress. It worked like a free market of ideas where bad ideas get weeded out. In China you had emperors who would declare that going overseas is bad. And then with a brush stroke, an area the size of a continent stops trading or exploring overseas completely, leaving that to the European upstarts.

The advantage of Africa being divided is that it provides a big sandbox to experiment with what works and what doesn't. We see many smaller countries have success like Rwanda. This allows other countries to evaluate what works and copy good ideas and discard bad ones.

Another key advantage today, is that we are passed the naive western aid of the past. Today we got China making big investments in infrastructure, mines etc getting the economies going. And I think it is a positive thing with all the people they are sending in as it allows Africans to learn from other countries how they work and do things. China not being as developed as the west is probably an advantage as it is easier to understand each other.

Western countries are so far ahead that we often have no clue about how to operate or do business in less developed countries. We make a lot of stupid assumptions, which only work in modern well developed economies. I think the Chinese understand a lot better of to get things working in Africa.

And finally lets not forget another advantage. Unlike the middle east, African countries can take advantage of their heritage of English and French from colonial times, which makes it easier for them to connect to the global economy.

<comment><USER20> > More religious diversity, not just Islam, I think is a gain for Africa. I > don't think they will get bogged down in religious extremism as in the > middle east.

The biggest religion in Africa isn't islam, it's Christianity. Meanwhile, the biggest religion in Asia is Islam and it does just fine. The middle east's problem's aren't religious, they're political. Nationalism and geopolitical conflicts get wrapped into the most convenient us vs them wrappingpaper available, in the middle east it's often religion. But let's be frank here, Saudi Arabia and Iran aren't in conflict because they believe in a radically different way of religious life.

Your stuff about unification conveniently skips over the part where China sped past every other poor country in large part because it was unified and could move in one direction.

Rwanda is tricky... it's probably home to the absolute worst tragedy in my lifetime. 70% of a peoples was eradicated. Beyond that, it's still dirt-poor, 90% of the population is engaged in subsistence farming, 80% live on less than $3 a day, 60% less than $1.90. I assume you're referencing to economic growth which has been really nice, but it's tricky to see it separate from the foreign aid which represents 30-40% of the budget. It's not particularly hard to improve income levels from $1.90 a day to $2 if you're pouring in $100 of foreign aid per person per year and lots more financing. (a great playing ground for Chinese companies to build an economy indeed.)

Beyond that, there are 25 different countries who've had at least 75% of the average growth rate of Rwanda in the past 10 years, its economic growth has been great but things have actually gotten quite a bit better in Africa across the board. When Rwanda's foreign aid was temporarily cut a few years ago after accusations of aiding rebels the growth rate halved.

I don't see the Rwanda (0.9% of Africa's population) necessarily as a model for the rest (99.1%) of Africa.

Agreed on all your other points.

</comment></comment><comment><USER21> Lots of very promising ideas here.

I particularly like this one: [http://twigafoods.com/](http://twigafoods.com/)

We're so focused on solving the middle class problems in my country (India) that we've forgotten about the problems lower class people serving the middle class go through.

</comment><comment><USER22> Could they put solar panels everywhere in Africa and sell power to other continents by undersea cables like internet that would be interesting.</comment>


Ask HN: How did you solve the "messy office kitchen" problem? - <AUTHOR> I guess most of us know the problem of a messy office kitchen. Be it that the dishwasher is not filled or emptied, surfaces are dirty or full of used dishes, empty milk cartons are not disposed of, etc.
I've never worked in any office where this worked. Instead I regularly saw passive-aggressive notes or "Let's all work together" emails by office management that mostly got ignored.
Now my question is: has anyone successfully solved that issue? If yes, how did you actually pull it off? <comment><USER2> Have your janitorial staff clean them on a regular basis and be brutal about forcibly cleaning out the fridge every friday and literally throw away everything that is expired or unlabeled.

That's what I've seen that actually works.</comment>


The Science of Why No One Agrees on the Color of This Dress - <AUTHOR> http://www.wired.com/2015/02/science-one-agrees-color-dress/ <comment><USER3> Well, without knowing the light source, it's _impossible_ to accurately measure color. They mention applying white balancing to fix it, but this makes an _assumption_ of some characteristic light source:

[http://www.cambridgeincolour.com/tutorials/white- balance.htm](http://www.cambridgeincolour.com/tutorials/white-balance.htm)

Beyond that, there is processing done by the sensor, the photo app, the person who put it online, etc...

<comment><USER4> That's not quite it. More precisely, it's always impossible to measure "color", because color is a perception in the brain, not a physical fact about the environment.

But it's certainly possible to make a good guess at the light source by looking at objects in the scene. In this particular case, we can look at the black and white dress at bottom left, which we can reasonably expect will appear neutral to human eyes and most "properly white balanced" camera images.

I'll agree that the camera used here has a relatively crummy sensor / processing pipeline though.

<comment><USER3> Yes, but the spectrum of the light hitting the eye _is_ a physical thing.

The physical problem is that multiple environments can make the same spectrum, e.g. is it a bluish light source & white dress or white light and bluish dress. White balancing can fix this if you know the light source, e.g. the sun, but that's either an assumption or something calibrated separately from the image.

That said, the perceptual issues are certainly a problem as well :)

</comment></comment></comment><comment><USER5> Looks like someone has rediscovered what Edwin Land pointed out in 1959 [1] which is that the perception of a color depends on what is around it. There was a great video of Land walking with a square of one color from background to background in a single shot and the color of the square appears to change as he changes backgrounds.

[1] [http://www.millenuvole.org/f/Fotografia/Per-quali-ragioni- ve...](http://www.millenuvole.org/f/Fotografia/Per-quali-ragioni-vediamo-i- colori/edwin_land_1959.pdf)

<comment><USER6> But the perception is different per individual, not per "what's around it."

Further, the image's colors is changing somewhat spontaneously for some people, including my girlfriend.

<comment><USER5> Edwin, who went on to create the Land Camera (Polaroid) noted exactly the same thing. And he realized that the _reproduction_ of color was not nearly as straight forward as people thought it should be ('just add the primary colors'). This particular image is a great example because it sits right on the edge of what you're eyes perceive.

Everyone is seeing this image through a color reproducing display. And that display has approximations in terms of the color frequencies it can display. That combines with the way our eyes perceive color and gives us different views of it. On my Moto G for example I can change the color people perceive by changing the brightness of the screen. Same picture just different brightness levels.

</comment></comment></comment><comment><USER7> Initially I saw white & gold, and I kinda still see it that way. The assumption I noticed I had is that there is a window behind, which gives out a bluer shade of light than the store lights. On closer inspection, the blue tint doesn't quite match that assumption and that the dress must have a blue tint. I cannot unsee the gold shade, but thinking about it, it could very well be the store lights that cast the yellowish tint.

</comment><comment><USER8> I can see the blue and the white but I cannot see black. Even the darkest images I'm still seeing a gold tint. Can anyone help me out?

<comment><USER4> The "gold tint" is due to the camera white balance. Does it still look gold if we adjust it so that the background white + black dress is neutral?

[http://i.imgur.com/jtjECtR.jpg](http://i.imgur.com/jtjECtR.jpg)

<comment><USER8> I still see gold tint to that image, and it is far from black, which I verified by opening the color in photoshop.

And I'm confused about your point about the camera white balance. It doesn't matter what is causing the "gold tint" only that I am seeing it and others vehemently claim they see no gold tint. The point is there is a perception difference that is not being accounted for. I mean, I understand how the shoddy white balance makes what in reality is black fabric shift gold/orange in a photo, but objectively in the original photograph the bands of fabric are not black or gray but a muddy gold color, so I do not understand how anyone sees it as black.

</comment></comment></comment><comment><USER9> I saw this a few hours ago and the dress was _very_ clearly white and gold.

I just looked at it again and it is black and blue.

This is quite the trip.

The only difference I can think of is that earlier I was in a bright, well-lit room, and now I'm sitting in bed in a pitch black room (other than the screen). Maybe my adjusting to the change in my own ambient lighting led to the change in perception?

<comment><USER10> I saw it on my iPhone, I thought it was clearly gold and white.

Had a discussion about it with a colleague (he saw it as clearly blue and black). I got up to go check his monitor and as I got closer it changed colour right before my eyes.

I went back to my desk and checked my phone and it had ___changed_ __to blue and black. MIND = BLOWN

I've not been able to see it as gold and white ever since...

I'm so confused lol

<comment><USER9> It's back to white and gold for me.

I'm also now in a well-lit room next to a large window with natural light as well. I'm curious to see how long this correlation continues.

</comment></comment></comment><comment><USER11> I used computer vision to prove the image shouldn't be perceived as black and blue to us.

[http://austingwalters.com/that-dress-is-gold-and- white/](http://austingwalters.com/that-dress-is-gold-and-white/)

A bit about myself, I've been doing research into this very thing for the past two years at UIUC.

<comment><USER4> I hope you're joking. Speaking as someone who has spent many hundreds of hours reading color science papers, and another several thousand hours color- correcting photos in CIELAB space, your analysis is absurd.

If you ever come to San Francisco, I'll be happy to explain why over a coffee.

<comment><USER11> Perhaps I went a bit eccentric, the same way the news stories were going :)

</comment></comment></comment><comment><USER12> Still interesting is the differences in who perceives it differently. Take the survey : [http://digitalorchard.co/dress/survey.html](http://digitalorchard.co/dress/survey.html)

<comment><USER13> I see it as more gold and a blueish white hue. So not taking that survey cause it seems to constrict me into some weird combination I can't agree with.

</comment></comment><comment><USER14> I haven't seen this link posted in this discussion about this dress.

[http://news.yahoo.com/debates-rage-over-color-dress- photogra...](http://news.yahoo.com/debates-rage-over-color-dress-photographed- rare-light-163138620.html)

The reason it's interesting is it shows a storefront window with the dress. I think it really helps put the original image into context. Especially check out the contrast between the blue dress and the very white mannequin. Nobody who sees that picture will ever think the dress itself is white.

</comment><comment><USER4> I'm so confused. Is it people looking at the dress in person that think it looks white?

Someone looking at this photo on a reasonably standard (or reasonably well characterized) LCD display which their eyes have adapted to is going to pretty much see all of the three versions falling between "pale blue" and "dark blue". Given the yellow background, proper "white balance" would make the dress look even bluer (see example below). Either way, seems like the photo was taken with a pretty bad-quality cellphone camera. Maybe people have just learned to predict color in pictures from some specific cellphone cameras with awful sensors and processing? Or maybe someone spent 20 minutes staring at something bright blue, and then switched quickly to looking at the photo?

What am I missing here? Does anyone here think the image makes the dress look white?

(Also, there's not much "science" in this wired post at all. Edit: in response to the below comment, the businessinsider post is also pretty shoddy "science".)

Edit:

One of the nicest online sources about this topic is [http://handprint.com/HP/WCL/color4.html#chromainduct](http://handprint.com/HP/WCL/color4.html#chromainduct) ; the rest of that site is in general the best online source about human color vision. (There are better sources, but you'll need to go to a university library to read them.)

I wouldn't claim to be a professional color scientist, but I'm about as much an expert on this topic as you'll ever find among amateurs. If someone wants a 3-hour lecture in person about the science of human color vision, I'd be happy to oblige (but you have to come to an SF coffeeshop for it; could also be a shorter or longer lecture, depending).

Here's the original image vs. one I "white balanced" to make the obviously white & black dress in the background appear neutral. Does the foreground dress still look white + gold?

orig: [http://i.imgur.com/g461GBr.jpg](http://i.imgur.com/g461GBr.jpg) ; white balanced: [http://i.imgur.com/jtjECtR.jpg](http://i.imgur.com/jtjECtR.jpg) (and I actually cheated a bit toward leaving the blue less intense than I would typically make it if color correcting this image)

In any event, I still can't explain why people are seeing this dress as white. I now think that it's likely to be unfamiliarity looking at digital photographs and/or some weird adaptation effect, e.g. looking at a dim phone screen while outside in the shade on a sunny day. Or maybe perception is being colored by a general expectation of white dresses (people often substitute colors in this way when they look at e.g. fire hydrants, human skin, clouds, or grass, interpreting the color based on past experience despite weird lighting conditions).

<comment><USER15> Yes, to me the dress looks gold and white. Granted, we're looking at a side of the dress which is in shade (thus there's a tint). But, in my mind, the dress is clearly white and gold.

My wife, on the other hand, first saw it as blue and black. Later it seemed to change for her.

<comment><USER4> The only way you'd get a "tint" like this on a white dress in the shade, indoors, in a room with yellowish lighting (look at the background) is if you shone a bright blue spotlight at it.

<comment><USER16> In real life, you are right. However, this picture was taken with a camera, which did some auto white balancing internally. Perhaps the camera chose to use the yellow background as the reference for white-balancing, causing the less "white" dress a bluish tint.

You cannot just consider the natural image here. I am sure that if we got everyone to examine the dress in real life, there would be a lot less confusion.

I bet a good part of the confusion is caused by faulty in-camera white balancing.

</comment></comment></comment></comment><comment><USER17> The only thing this scientifically proves is that marketing agencies are getting better and better at viral marketing.

Imagine that, that very same dress is now back in stock. Purchase one today! [http://www.romanoriginals.co.uk/](http://www.romanoriginals.co.uk/)

</comment><comment><USER18> It looks like a white and gold coloured dress, which was accidentally washed with a blue sock :)

</comment><comment><USER19> Slightly tangential, are there any computer vision algorithms that react to optical illusions in the same way human vision does?

<comment><USER4> You'll need to elaborate. There are hundreds of different "optical illusions", because human vision is extremely complex with numerous processing steps and many types of adaptation. There's no single "algorithm" that responds to images the way a human responds.

If you can narrow your question down to a few effects, and figure out what you want your algorithm to do (classify images? print a nice picture to hang on your wall compensating for different scene lighting? detect object boundaries? predict what color name a human will attach to a particular object?), then it should be possible to find or make a program that does that. (At least in principle. Really depends how sophisticated your goals are.)

<comment><USER19> I don't want an algorithm to do anything. I am not in the field, and I was curious whether any computer vision systems account for any (not all) optical illusions that humans are susceptible to. It's just a curiosity.

</comment></comment></comment><comment><USER20> What I haven't seen mentioned as a factor is eye color.

I have blue eyes and see the dress as blue and black.

<comment><USER4> The pigment in your iris has nothing to do with the colors you see.

<comment><USER20> Eye color affects contrast and glare perception.

</comment></comment></comment><comment><USER21> There's a joke on film sets: Why don't more Directors of Photography smoke? Because it takes 3 hours to light.

Typically the director chooses one or more angles for viewing the action of a scene, and then the production designer makes sure that whatever appears within the frame (wallpaper, props, furniture) looks right. Then the Director of Photography's, or DP's, job begins.

The basics of lighting involve setting up areas of light and shadow, of the kind you know if you enjoy black-and-white films. But from there, building a consistent color balance for a scene is an enormous amount of work. There are multiple different sorts of lights (incandescent, flourescent, LED, HMI), each with different color temperatures (often switched in and out within the same fitting), which are in turn modified with varying thicknesses of colored gel and which have to match the diegetic light sources - ie those which will appear on screen as part of the 'story world'. Sunlight is blue. So's moonlight, but not _as_ blue - if it's too blue then it looks like a blue light instead of a white moon. Interior lamps have their own color temperature, which usually tilts orange. Then you have to deal with multiple lights; typically there's a key light illuminating the subject, a back light which helps to isolate the subject from the background (so the actors don't look like they have a tree growing out of their head or something - <USER2> lenses flatten perspective and make it hard to differentiate foreground and background at narrow apertures) and a diffused fill light to balance these more intense point sources and obscure their artificiality, without losing the selective quality of the illumination. Each of these has to be color-balanced separately. Complex scenes sometimes require 6 or seven light sources. If you're shooting interior scenes and it's not essential to look out the window, it's often preferable to just black out all the windows or shoot at night, and employ artificial lights instead of the sun.

Here's an example of what it takes to make a scene look 'natural': [https://plus.google.com/photos/109568505224923852682/albums/...](https://plus.google.com/photos/109568505224923852682/albums/5884382003578185713/5884427087396987378?banner=pwa&pid=5884427087396987378&oid=109568505224923852682&authkey=CJbl8Ne5t7vGcQ) What you can't see here is that the lower halves of the windows are covered with multiple sheets of neutral-density filter gets, gut to size (whereas the unfiltered upper parts of the window are just a glow of overexposure). that's several hours of work before it's even worth turning the camera on.

Shooting outside in sunlight should be simpler, right? Nope - you need reflectors (White? Gold? Silver? it depends), flags to take light _off_ the hot spots, large silks for diffusion (which require extensive rigging to hold what is essentially a small parachute and prevent it flapping in the breeze), and people able to reliably adjust everything during the shot if the camera or the subject is moving. Also, the motion of the earth around the sub means that the position of everything needs to be tweaked about every 15 minutes as you do more takes and shoot things from different angles, all of which have to look completely consistent later on even if the source footage was shot hours apart. Also the color of the sun changes depending on the time of day.

Lighting for film is a massive headache most of the time* which is why you just don't see certain clothing combinations on film. A dress like this is enough to make an industry veteran cry.

* unless it's mild and overcast. Moderate cloud cover basically doubles productivity for daylight photography.

</comment><comment><USER22> To me it is clearly blue and gold/brown. So what does THAT mean?

</comment><comment><USER23> It looks blue and black to me. Can't see any white.

Very interesting analysis.

</comment><comment><USER24> Today's xkcd: [http://xkcd.com/1492/](http://xkcd.com/1492/)

<comment><USER9> I don't think this explains it fully. This shows how the perceived color has a dependence on the background, but not how it has a dependence on the observer as well.

In fact, for me, I saw it as white and gold at first. Now, several hours later, it's black and blue and I can't see the gold at all. The background of the image didn't change.</comment></comment>


Show HN: Follow multiple live crypto charts on single screen - <AUTHOR> https://multiplecharts.com <comment><AUTHOR> I've built a simple tool to follow multiple coin charts on single screen. I'd love to hear what fellow cryto traders think about it :)</comment>


The hidden FM radio in your pocket and why you can't use it - <AUTHOR> http://www.npr.org/blogs/alltechconsidered/2015/04/16/400178385/the-hidden-fm-radio-inside-your-pocket-and-why-you-cant-use-it/ <comment><USER2> _But Jot Carpenter, vice president of government affairs for CTIA-The Wireless Association, resists the move to turn on the FM chip... "What Americans really want is the ability to stream, download and customize music playlists to meet their personal preferences," Carpenter said..._

I wonder if the people whose job it is to make these sorts of patronizing arguments privately feel embarrassed when doing so.

<comment><USER3> I work at a telco that constantly makes ridiculous patronizing arguments.

The people making those statements are drinking so much kool-aid they honestly don't even know they're talking nonsense. They actually believe it to their core.

<comment><USER4> I'm 32, pay $10/month for Spotify, and T-Mobile doesn't count music services towards my data cap. I haven't listened to the radio in my car in over a year.

Even if I'm an outlier, Spotify still has a free tier. Why would I go back to the radio? That would be like trading Netflix back in for Blockbuster Video. _shudder_

<comment><USER5> How enticing would it be if T-Mobile's net neutrality violation were stopped?

<comment><USER6> Its only a violation if its a paid exchange or an affiliate, no?

I don't know if that is the case or not in this situation, but it could be. Not everything becomes a violation

<comment><USER5> If there's money changing hands, it's bribery or extortion. If there's no money changing hands, it's still at least non-neutrality: the ISP is picking winners by determining which service providers get a competitive edge.

</comment></comment></comment></comment></comment></comment><comment><USER7> While half-baked conspiracy theories are fun, a good journalist would've consulted a few more sources to get to the bottom of this story.

FM radio requires a large antenna. It will not work without one. The 5th generation iPod nano (2009) was the first iPod with an (enabled) FM radio. We used the headphone wire as the antenna. It worked well enough. While there was a tiny speaker in those iPods, headphones were the only practical way to listen to audio.

That's not the case with phones. People listen to the built-in speaker, and they listen over bluetooth and WiFi. It's becoming less and less common to plug headphones into these devices. That being the case, including an FM radio feature would just be a horrible experience for the majority of users: they'd hear nothing but static, all the time. I don't know about the other smartphone makers, but Apple will not ship something that will likely be a horrible experience for most users. Couple that with very low demand from users (as the article points out) and there's no FM radio on iPhones.

<comment><USER8> I dont see why we cant include a software feature to prompt the user for headphones and still allow sound to the loudspeaker.

<comment><USER9> Because having to attach headphones only to not use them as headphones makes for a stupid-looking user experience. Most users don't comprehend "antennas", much less using headphone wires as such. Prompting for headphones but using the speaker would result in most users coiling up the headphone cable (in bewilderment) which pretty much defeats the point of having an antenna.

Never mind the fact that not all users would use headphones not suitable for use as an FM antenna (too long or short, wrong impedance matching, etc).

</comment></comment></comment><comment><USER10> This is poor journalism, particularly coming from NPR.

The NAB (including NPR) are lobbying to force all phones to include an FM radio.

Since they can't say, "we want this to increase our ad revenue," they're using the tried and true, "it's a must for national security" approach. They've previously tried to get language added to Homeland Security bills that would force phone manufacturers to include radios.

Besides, forcing phone manufacturers to include a radio won't save the radio industry. Radio audiences are declining for the same reason broadcast TV audiences are: it's a one-size fits all product on a strict schedule that's overflowing with ads. It was in decline well before the smart phone.

[https://recodetech.files.wordpress.com/2014/04/arbitron-1980...](https://recodetech.files.wordpress.com/2014/04/arbitron-1980-2008.png)

<comment><USER2> There's a difference between including an FM radio and simply turning on a pre-existing one via a software update, which apparently is possible on at least some phone models.

And regardless of NPR's motives, their "it's needed for emergencies" argument is a pretty good one.

<comment><USER5> And selling hardware that's been crippled in some way always makes people uncomfortable. Whether it's an FM tuner being turned off, tethering being blocked, CPU features turned off, or whatever, manufacturing a working product and then selling it in a less-working state is worrisome and shouldn't be automatically considered acceptable. It's a strong indicator of a possible market failure and a sure sign that the consumer's ownership rights have been compromised.

<comment><USER11> The hardware isn't crippled; you can root your phone and install an FM Radio app yourself.

<comment><USER5> In _some_ jurisdictions you can sometimes root your phone, if someone has put the effort into defeating the technical obstacles put in place to enforce the crippling. Other phones include a tuner that is disabled through hardware means.

</comment></comment></comment></comment></comment><comment><USER12> This article is misleading. While it is true that almost every smartphone has an FM radio on the SoC, it's not true that it's _always_ up to the carriers to enable the radio. Many unsupported phones are lacking the trace between the FM input to the headset jack, meaning this issue can't be fixed in a software update.

<comment><USER13> "This article is misleading." ^Yes this is NPR's classic bias against corporations.

<comment><USER5> This is a corporation v corporation dispute: broadcasters against carriers and streaming providers.

</comment></comment></comment><comment><USER14> My phone (Samsung Galaxy S3) has an FM radio. Unfortunately it's really difficult to use because it uses the headphones as the antenna, which means you have to literally stand in a certain way with your arms in a certain position to hear anything. But anyway, it has an FM radio ...

</comment><comment><USER15> Even if the chip supports FM, does the phone have an FM antenna?

I seem to remember that my old pre-MP3 devices used the headphone cable as the antenna. Would it be easy to have good reception in a smartphone without using a headphone cable?

Given how I use my smartphone using Bluetooth speakers for music and seldom headphones, I doubt that the FM chip would work for me. (And if I did often use headsets, I would get a Bluetooth one.)

<comment><USER16> Yeah I don't think most phones have an FM antenna. All of the phones I've seen that expose FM radio end up using the headphones that are plugged in as the antenna. This means you have to use headphones, which is a bit of an annoyance when you want to stream music to a bluetooth speaker or even just use the phone's internal speaker.

<comment><USER17> You only have to have headphones plugged in. At least the Windows Phone radio app has software switch for where you want the audio output to go. You can plug in headphones and play on the speaker. If other radio apps don't have this, it would be easy to add.

</comment></comment></comment><comment><USER18> What's the downside of turning this on? From the article it just seems like it would mean more capabilities, more consumer choice. Is the only "downside" that it allows you to bypass cell networks when getting content?

<comment><USER11> It only works if there are headphones attached, which confuses users.

Plus, Google or another company has to pay an engineer to write an app for it, and test it against the hardware in the phones, etc. etc.

Usually this functionality is a byproduct of some random other chip on the phone that is multifunction, usually Bluetooth. So people who don't use Bluetooth get confused/upset/paranoid/tin foil hat when their FM Radio app tells them that Bluetooth needs to be enabled to use it.

Many users who really want FM can already do it today, but it involves rooting their phone and installing something like Cyanogenmod.

<comment><USER19> >which confuses users

So users are why we can't have nice things.

Also, on Nokia N900 they simply didn't do an app at all. Lots of them were quickly written by community and everyone was happy.

</comment></comment></comment><comment><USER20> I would argue that analog FM radio has a pretty bad user experience, and I completely understand a manufacturer not including it because of that. The audio quality is usually poor, it's location and environment sensitive, and the system for distributing and the RDS text is slow to update, and often incomplete.

<comment><USER21> I generally agree with you that FM radio is not a very good user experience (except during emergencies, when it suddenly becomes incredibly useful). But that doesn't mean I get to tell other people whether they want it or not. Enabling the FM radio tuner chip doesn't have to affect the user experience at all for users who don't want to use it. The carrier doesn't have to include an FM radio app pre-installed. Users who want FM radio can install an app for it.

</comment></comment><comment><USER22> As always, no mention of Blackberry, who do have FM radios on several of their current models including Passport, Leap, Classic and Z30.

<comment><USER23> For about the same reasons my blog doesn't show up in "check out this new internet trend!" articles.

</comment></comment><comment><USER24> I'm very surprised that many seem to simply accept the rhetoric of this story and its talking points.

Exactly why are these chips being included and disabled, as opposed to not including them in the first place? No one seems to be questioning this part.

Can anyone shed light on this? What is the back story here?

<comment><USER25> It's one part of a multi function chip and there's no reason to special order a version without FM.

Fun fact: at least for small orders you can get PICs cheaper than 555s.

</comment></comment><comment><USER26> "NPR, along with the NAB, has been part of a lobbying effort to require this free radio feature to be enabled."

I don't want an FM radio on my phone because the internet is a superior system 99% of the time. If Apple doesn't want to make an FM radio then they shouldn't have to. It should be the people creating technology who decide the features, not lobbyists using threats of force through government based on clearly biased political interests.

</comment><comment><USER27> > "NPR, along with the NAB, has been part of a lobbying effort to require this > free radio feature to be enabled"

Do we really need a law for this? If people wanted it they would just demand it from manufacturers and/or carriers

> "Smulyan's lobbying has prompted the Indiana Senate to urge mobile carriers > to activate the FM chip."

Total newspeak. Government bodies don't "urge", they force.

> "When the power grid is out, the only lifeline for the American public is > having an FM tuner"

If you can't afford a battery powered radio, you can't afford a cell phone. And BTW if the FM tuner is your "only lifeline", you might want to reevaluate your preparedness for anything serious at all.

> "Every time you buy a phone, you've paid for that radio," Smulyan says.

Probably not true. In all likelihood the cost of the chip has no bearing on the cost of your device, and even if it did it would probably cost more to design separate chips (one with and one with the tuner) for separate markets, and that cost would get passed on to consumers

> "What Americans really want is the ability to stream, download and customize > music playlists to meet their personal preferences," Carpenter said, > according to the Las Vegas Review-Journal, "and that's not what the > traditional FM radio offers."

What an arrogant asshole. His condescending presumptuous attitude aside, neither of these options precludes the other and what consumers probably want is every option at their disposal.

</comment><comment><USER28> Am I going crazy? One day I woke up and could not find the Android app "FM Radio" (even had a shortcut on my home screen.) Looked and looked and looked and could not find it anywhere. Eventually I verified the apk was included in the original install.

Did my provider (Sprint?) or my manufacturer remove this during an update? Did Gooole remove this during an update?

Side note: anyone know of a good FM radio app on Android?

<comment><USER29> I just checked after seeing this and I do have the FM Radio app. I'm not from the states so, it wasn't google?

<comment><USER28> you wouldn't happen to have a link to the Google Play app?

</comment></comment></comment><comment><USER30> I have a Cat B15 phone, which runs Android, and it has an enabled FM radio. If I try to use it without headphones, I get a warning that without headphones as an antenna, reception will be poor. It sometimes works in good reception locations without an antenna, but it's a marginal FM radio. There's a "record FM radio" option.

</comment><comment><USER31> This made me realize I don't even own an FM radion anymore. I need to grab one for my emergency kit.

</comment><comment><USER32> Any idea how to activate it? Is it theoretically possible to unlock it by jailbreaking your iPhone?

</comment><comment><USER33> On the devices that do have FM receivers such as many MP3 players and so forth, why do they _never_ have an AM tuner?

There is a lot of stuff that people want to hear that only comes over AM, like baseball games, for example.

<comment><USER34> AM broadcast requires a relatively larger antenna larger antenna to receive. Though, most of portable AM radios use a bar shaped antenna inside. There are several problems with it.

1) You will have to integrate that antenna somewhere in the device, and you can't really make it "smaller" than a certain size. 2) Even if you could integrate the antenna, it is directional; with a use case for mobile devices, unless you are getting an exceptionally strong signal, you'll get varying results out of it.

<comment><USER33> The headphone wire isn't enough? The cheapo AM portables everybody has been plopping down next to the beer bucket since the 70s never seemed to have an antenna longer than 2.5 ft. I understand the wavelength is longer and the power is lower.

<comment><USER34> Those whip antennas are for FM broadcast. For the AM broadcast, the bar antenna has a coil of wire wrapped around an iron bar to compensate for requirement of a longer antenna to receive AM broadcast. It'd be actually size prohibitive to make an antenna like FM radio, but designed for AM.</comment></comment></comment></comment>


Sweden indicts four from Pirate Bay - <AUTHOR> http://news.bbc.co.uk/1/hi/technology/7219802.stm

<comment><USER2> As an American living in Sweden, I know a bit about their system. It's not heavy on giving out jail terms. Nor should it be!

These guys are going to walk. And while perhaps they do make a dollar and a penny off the ads, I doubt they are in it for the cash. They are probably idealists and will continue to operate the site from somewhere because they can.

Sweden is a place where "influence is not so influential". So don't be surprised if they continue running it from Swedish soil. Gotta love this country :-)

<comment><USER3> >And while perhaps they do make a dollar and a penny off the ads, I doubt they are in it for the cash.

While I sincerely respect their ideals and their idealism, the Pirate Bay guys are making a fucking killing. The prosecution claims they make $4 million in ad revenue a year. <http://torrentfreak.com/pirate-bay-team-charged-080131/>

<comment><USER2> That may be true. But the thing I really love about Sweden, is that I am guessing that these guys will pay at the 40% bracket and do it out of a sense of obligation. And when they go out and celebrate their spoils, they will do it with a love of society and not with a single instinct of snobbery or vindictiveness.

Jantelagen!

</comment></comment></comment><comment><USER4> Even if the recording industry manages to shut down Pirate Bay in Sweden they will just move their servers elsewhere. They have already demonstrated that they are capable of doing this - last time they were raided by the police their servers were up and running in other countries within 24 hours.

And even if they manage to shut down the Pirate Bay completely something else will fill the gap within a month. Napster, Kazaa, e-mule, the list goes on...

Don't these people have anybody looking into new businees models? Their current one seems to revolve around suing their customers, and in the long term I somehow don't think that is a great strategy...

I don't necessarily agree that it is OK to steal copyrighted work, but seen from a business perspective they are digging their own grave. The world evolves, and industries that don't evolve with it will wither and eventually die.

<comment><USER5> That's been said before, but the current industry got fat off the way things were. You can bet they'll kick and scream before cutting off a pound of their own flesh - no matter how clear the need.

<comment><USER4> Yeah it has, the comment was not so much to try and say something new as it was amazement at how a whole industry can so stubborn be walking right into its grave.

It is just totally beyond comprehension.

<comment><USER6> I'm reminded of the Niels Bohr quote (which I can't find now) about how Quantum Physics overcame Newtonian Physics in academia - something to the effect of "we waited till all those who believed in Newtonian Physics died."

Big companies are like that - nearly impervious to change. They won't change -- they'll die. They're dying now.

</comment></comment></comment></comment><comment><USER7> "The charges relate to 20 music files, nine film files and four computer game files."

I'm confused. I thought that Sweden's laws made what they were doing legal. But somehow 33 files were illegal?</comment>


The Pragmatics of TDD - <AUTHOR> http://blog.8thlight.com/uncle-bob/2013/03/06/ThePragmaticsOfTDD.html <comment><USER2> I think the only reason TDD works as well as it does is because it forces you to _actually_ write the tests. If you write the tests after the code, it would be perfectly fine.... except no one ever (hyperbole) writes tests after the code, because management/sales/support sees that the code works in the general case, and now insists you work on the next feature and/or you get excited about another feature and don't want to write boring tests.

If you write the test first, that can't happen, because you haven't written the actual code yet.

<comment><USER3> I think it's actually worse than that: people who write tests after code just write their tests to "verify" that the code is doing what the code is doing.

So, the code provides a list of numbers 1, 2, 5. Non-TDD would code a test that verifies the list is indeed 1, 2, 5.

However, the business wanted the list in reverse order: 5, 2, 1. TDD would force the developer to state this up-front. A non-TDD developer is more reluctant to change the code, since "it passes the test!"

I've done this, although I like to think I'm quite happy to rewrite something if it's not good enough (or just wrong).

<comment><USER4> I am not sure I agree with it being worse. Would you rather have code with no tests or code with tests even if they do verify what it is doing? Most regression tests are brittle because they never change and get hardened. In my previous life, I was majorly behind model-based testing which is very similar to concepts of TDD in that it forces people to think of your entire component and then it generates tests or can walk through your reference implementation to verify your actual code. However in smaller companies, I personally feel that it is important to first test the right "it" before building it right. (As Google Engineering Director Alberto Savoia used to put it).

No one is advocating releasing broken stuff, but whats the point of releasing something perfectly tested that no one wants? I think the answer lies somewhere in the continuum. And in my own startup (wello) we do go back and write tests, because testing everything manually does hurt once the feature is working well and users actually want what you are building. So we do carve out time and write tests and often times then build it right. You could argue that this is inefficient, but I could also argue that for many features we removed because users did not want them, we saved the time needed in upfront TDD.

<comment><USER5> _> Most regression tests are brittle because they never change and get hardened._

Regression tests should get refactored at the same time by the same tool that refactors the rest. Code changes should be handled the same way.

<comment><USER4> Agreed. I was only saying that mosts tests are written to codify what is expected not that they should not be changed with changing code.

</comment></comment></comment></comment></comment><comment><USER6> What has always bothered me, is that the ratio of people consistently talking/blogging/tweeting about how important TDD is to the number of actual resources that can help a junior developer learn and practice good testing habits is a million to one.

I truly believe that TDD works. I truly believe that the jury is already in and that anyone who is serious about becoming a software professional should write tests for every line of code. I really really believe it and want to use it.

That being said, it is so fucking hard to get started with TDD. Oh god, it's so difficult. I've done the katas, done an apprenticeship, read the RSpec book, watched every screencast I could find, everything you can reasonably ask a learning developer to do, and I still find it incredibly impractical to practice TDD when working on most projects, not because I don't want to, but because it's so difficult and time consuming and the resources just aren't there to help make my process quicker.

Here's an idea for the TDD crowd. Every time you're about to write a blog post about why people should use TDD, instead write a blog post about a situation where you applied TDD, the tests you wrote and the code it lead to. We need more examples of TDD in progress, more code snippets, more screencasts. I'm telling you the problem is that the resources just aren't there to encourage these habits. Instead of continuing to have this debate at a semantic level, if there were more testing resources available I think people would naturally flock to it and TDD would win out. Until then, I think it's twitter fights and bad habits for the foreseeable future.

*This comment applies verbatim to security best practices as well.

<comment><USER7> Shameless plug, since you asked for it: Let's Code Test-Driven JavaScript is an _extensive and in-depth_ screencast series about doing TDD in practice. I promise you've never seen a TDD screencast that goes this deep.

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

And if Java and Swing are more your thing, Let's Play TDD is its less-polished progenitor. <http://www.jamesshore.com/Blog/Lets-Play/>

You're right, by the way. It's much harder to do TDD for real than it is to do all those toy problems that involve maybe one class, some calculations, and nothing else. That's why I created the screencasts.

<comment><USER6> These look really really cool. I can't speak to the quality because I haven't watched them yet, but I'll definitely check them out, this is exactly the kind of thing that I'm looking for.

<comment><USER7> Thanks! Glad to hear it. Email me any time if you have questions. (My address is in my HN profile.) There's a 7-day free trial so you can try out the show and I'm more than happy to cancel it for you if it's not a good fit.

</comment></comment></comment></comment><comment><USER8> I interviewed Uncle Bob on Monday (shameless plug: [http://tiny-giant- books.com/blog/robert-uncle-bob-martin-int...](http://tiny-giant- books.com/blog/robert-uncle-bob-martin-interview-audio/?id-7)). It was mostly biographical stuff, but I did cover functional programming. There was a bunch of technical stuff I left off because of time constraints.

The topic I really wanted to cover but didn't was TDD in startups. I have a simple belief: the value of your code debt can never exceed the value of your code. That is, if you code has no monetary value, it is impossible for you to have any code debt, no matter who you are, what your code does, or what the code looks like. Think about it. It makes sense.

It's interesting that Bob took a "saw the baby in half" approach here, outlining the various things he'd throw away and the various things he'd keep. While I think there are definitely shades of gray, it would also be useful for him to directly address the question of code that has no value. If I write a function that I save on my hard drive and never use, does it need a test? I belief the ludicrously obvious answer is "no", but I haven't heard him say that yet.

<comment><USER9> He did mention if it is throw way code he doesn't write tests in his second to last point. "A few months ago I wrote an entire 100 line program without any tests. (GASP!)"

</comment></comment><comment><USER10> Write a blog post about a concept or idea in the general sense => "I need specific examples or this is just a religion/consultant-speak".

Write a blog post about specific examples => "It might work for this example, but in my experience it didn't work in this other case."

If you write in the abstract, people will dismiss it as fluff. If you write concretely, people will dismiss it because it doesn't cover their exact case.

There is no way to please everyone in the world of opinionated software blogging, so stop trying.

<comment><USER11> If you _really_ want to convince people you need to talk in concrete, not abstract. But you need a large number of examples and it should come from a neutral third party.

<comment><USER12> Trying to convince people is a losing battle in a misguided war. The fact that people out there will continue to disagree with you no matter what you say is part of life. Just make the best contribution that you can, and if someone gets value out of it, great.

The fact that some software development organizations out there aren't using any test automation* even though they would probably benefit from it might make me a little sad, but it's not a problem that I'm trying to solve.

*or source control, or deployment automation, or incrementalism, whatever.

<comment><USER11> You might not convince everybody all the time, but I don't think that trying to convince people is necessarily a waste of time if you have a good argument.

There are plenty of things that most people take for granted now that people previously would not have believed.

With enough supporting data it would be hard to argue against TDD, for example an independent study of a sizeable number of software shops which showed that developers using TDD shipped code 50% faster or with 60% fewer defects or whatever. That would put the onus on the anti-TDD person.

I think Zed Shaw wrote something about this, but can't find the link.

The closest I can find is this, [http://research.microsoft.com/en- us/groups/ese/nagappan_tdd....](http://research.microsoft.com/en- us/groups/ese/nagappan_tdd.pdf).

<comment><USER12> I guess so. It's just so easy to be defeatist when any useful tool or technique can be summarily dismissed by jaded technologists as "snake oil". I've had to come to terms with the fact that from my perspective, lots of developers are just "doing it wrong"

<comment><USER11> The definition of snake oil is basically medicine that has a claimed benefit but little/no supporting evidence.

Once you have strong backing data , it's not snake oil anymore and it becomes increasingly difficult to make that claim.

<comment><USER12> Backing data that's strong enough to satisfy some critics is impossible to obtain.

Anecdotes? Obviously not OK.

Small-scale controlled experiments can be dismissed as nothing more than pointless toy exercises that have no bearing on real-world production code.

Large-scale controlled experiments are impractical. Blinding and placebos aren't possible. Isolating confounding elements such as individual performance would be difficult.

Burden of proof is burdensome, I guess.

<comment><USER11> Basically yes. I'm sure it would be possible to do a good study but very expensive. Although if the potential upside is increasing the productivity of an entire industry maybe it's worth doing.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I've only recently started to use TDD, the biggest roadblock being the annoying steps it takes to set up the suite, directory structure (ok, that's pretty minor), and then properly use mocks and stubs. I sometimes forego the latter part.

I'm new to it but I find it an incredibly useful strategy. It forces orthogonality on me because I have to think how a function can be tested independently of the external objects that may use it...which causes me to challenge my initial assumptions and instincts about the overall application design.

In some sense, I guess, it is always frustrating to spend more time in the design stage than working with an actual prototype...but I find the medium-to- long term benefits to far outweigh the initial investment in time. And once the tests have been written, the actual functional code is almost trivial to write.

Even without the benefits TDD has in easing the maintenance/upgrade phase of a product, I find its effects on the design/prototype stage to be worth the effort alone.

<comment><USER14> Ideally mocks and stubs should be used only when the thing you're mocking/stubbing is either slow or complex.

In general, just call the real thing and don't worry about it. Otherwise you'll expend loads of time and energy setting up fakes to test relatively simple code.

<comment><USER15> Agreed, and furthermore: Mocks don't verify that you're calling external code _correctly_. Suppose you think API method does X, but it actually does Y. You won't detect that with mocks. Maybe you have integration tests (i.e. tests of the entire system working in concert) to account for that, but I say, why not catch these things at every chance you get?

<comment><USER16> >why not catch these things at every chance you get?

Because it's expensive. It takes time to write and maintain those tests. It takes time to run those tests. If you want to verify that API method works as assumed (and I assume you are talking about an API on an external system, but ultimately it doesn't really matter) then write a test specifically testing that API method.

Testing that method B also works while testing method A is, in my experience, the number one culprit of people writing bad tests. These tests are harder to set up, take longer to run, and are more prone to promoting brittle test code.

Test everything that's important to test, and nothing more. This is true whether you are talking about your entire system, or a single method.

<comment><USER14> I agree, the thing I was trying to warn about is meticulously mocking out everything you possibly can to test every single method/class in complete isolation from the rest of the system.

It's very tempting to start doing this when you get into heavy unit testing, but I find in practice this adds more cost than value.

As an example, lets take some python code I just made up which formats some input into a message, throws the message onto the queue, and returns the message ID.

        class DelayedJob(object):
            def __init__(self, queue):
                self.queue = queue
            def add_job(self, task, params, priority=1):
                m = JSONMessage({
                    task: task,
                    params: params,
                })
                self.queue.add(m, priority)
                return m.getID()

It's pretty clear that the queue service needs to be mocked out, as you don't want to be talking to a real queue for a unit test (you'll probably want some sort of acceptance/integration test to cover this somewhere).

However, I have in the past been tempted to make the JSONMessage class injectable, and then inject a mock with a stubbed implementation of getID - I've often seen other people do this as well. The code required to set-up such a fake would be fairly verbose and add little in the way of extra clarity to the test. Since the class is fast and simple (in this scenario it's just a container) then I'd just leave the concrete class in use.

</comment></comment></comment></comment></comment><comment><USER17> I've seen big company devs so overwhelmed by messy production code that any small feature change would require 2 weeks of work.

I've seen startup devs who couldn't cope with changing requirements fast enough. There was just too many moving parts at the same time.

Hell, I've been one of those devs! Great code is the exception, not the norm.

When I learned TDD, it greatly improved the quality of my code. If TDD is a bottleneck for you, maybe you need to learn to touch type.

My 2 cents.

<comment><USER18> The process of learning to TDD well makes a person code better, regardless of actually doing it.

TDD is one of the few actual disciplines I know of around coding that can't be just glossed over or faked. One either does or does not. This is doubly true in a pair programming environment. Not using one of the established patterns? One can argue around that. Not doing TDD? Justification usually has to tie with UI in some way.

<comment><USER19> How do you know whether I wrote the tests first by looking at my code?

<comment><USER7> The difference is pretty clear in practice. It's much harder to add tests to existing code than it is to TDD it, and it takes a huge amount of self- discipline to go back and add tests to "finished" code. So, without TDD, you end up with a relatively small number of tests that test a lot of things, whereas TDD (done well) creates a large number of small tests, each testing one very focused thing.

<comment><USER19> As long as I write the tests roughly the same time as the code, it doesn't really matter which I write first. And I always adopt the practice of writing a large number of small tests regardless. Going back and forth is the important part for me, not necessarily writing the tests first.

In any kind of setting with shared code, it shouldn't be a matter of self- discipline, it should be a matter of standards and best practice. You shouldn't be integrating any code without test coverage. This is a standard part of how many projects handle pull requests.

If you're only accountable to yourself and writing the tests first is the technique that works for you, I can't criticize but you really don't have much to say to programmers in general, either.

</comment></comment></comment></comment></comment><comment><USER20> I'm surprised at how much attention this bit of process dogma is getting on HN.

This particular argument about the supposed efficacy of TDD depends on people accepting the equivalence of the efficiacy of TDD with the efficiacy of surgeons washing hands, just because the blog author says so.

Oh horror, how can you challenge my dogma just because I call it a 'discipline' and _verbally_ equate it to surgeons washing hands.

Saying something is true doesn't prove it is true whether you call something a 'discipline' or not. Cults are full of such 'disciplines'. Cult members will vouch for them. A better word is 'ritual'. At best such rituals are cargo cult practices. [1]

Surgeons washing hands is a practice with empirical, unchallengeable _scientific_ evidence supporting it,while TDD is a dogmatic practice evangelized by software process zealots, with next to no scientific evidence backing it up.

Also TDD != testing and TDD != automated testing (though the evangelizers tend to blur the differences. It is easier to argue that you should write tests, than that you should write tests _before_ you write the code, which is a somewhat more shaky assertion. If you can paint your opponents as opposing _tests_ (vs TDD) you have set up an easily knocked down strawman).

Programmers have written tests, including automated regression tests for _decades_ without the blind adherence to the 'write a test _first_ , write the code, refactor, repeat' cycle that TDD consists of.

Insisting on this as some kind of _moral_ imperative [2] is snake oil, and it is natural that experienced devs push back against religious preaching.

The best 'poke holes in the zealotry gently but firmly' writing wrt TDD is at [http://www.dalkescientific.com/writings/diary/archive/2009/1...](http://www.dalkescientific.com/writings/diary/archive/2009/12/29/problems_with_tdd.html) . Bob Martin's TDD 'kata' is dealt with there in some detail. The comment thread at [http://dalkescientific.blogspot.in/2009/12/problems-with- tdd...](http://dalkescientific.blogspot.in/2009/12/problems-with-tdd.html) is hilarious too, with some familiar names popping up.

[1] <http://en.wikipedia.org/wiki/Cargo_cult>

[2] The author says as much here <http://news.ycombinator.com/item?id=5331108>

" [TDD] allowed us to go fast, and _keep_ going fast because the code stayed clean. I have come to view it as a moral imperative. No project team should ever lose control of their code; and any slowdown represents that loss of control."

<comment><USER21> This reaction is a bit visceral, and unnecessarily so. The "cult" and "dogma" accusations sound fairly outlandish, to be honest.

Part of the reason experienced devs push back against TDD has to do with patterns and habits. It's safe to say that TDD feels awkward to anyone with other established work patterns.

TDD is of course simply a methodology. It works well for some teams, and perhaps not for others. What it does do is impose a culture of testing and rigorousness, which is rarely a negative.

Sure, you can decouple testing from TDD, but IME teams that apply TDD have more extensive coverage than those who don't. Causation correlation caveats apply.

I personally dislike TDD because it disrupts the thought pattern I have become accustomed to using when developing software. I consider myself relatively junior, so I can only imagine how much of a workflow departure it must be for more senior engineers. However, just because it doesn't work optimally for me (or, optimally at first) doesn't invalidate the approach nor make anyone who uses it some brainwashed cult member.

<comment><USER22> I think the issue is that TDD is handy for a lot of people. They (wrongly) assume it is equally as effective for everyone else. Then, they use it as a metric to judge others. It has become the "moral imperative" Bob Martin spoke of. Which is truly awful, and elicits a strong response from many who do not find TDD that useful. Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs.

A couple months ago, in fact, I tripped on a blog post that said (paraphrased): If you do not do TDD, then you should re-evaluate your career as a developer. This is bullshit. It angers me because I keep meeting very smart junior developers carrying around a load of guilt over TDD.

I'm not sure what it is about TDD that make people forget that these things are all tools. You put it in your bag of tricks and pull it out when it makes sense. You don't beat each other to death over what tools they use.

<comment><USER7> "Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs."

Sorry, no, TDD isn't like vim or emacs. Your choice of vim or emacs doesn't change the code you produce. TDD _does_. Whether you agree with TDD or not, it's completely reasonable for a job to require it, just as it's reasonable for a job to require that you know and use MVC (in their app), or Rails, or any other technical solution to a problem.

If I'm hiring somebody, they have to know TDD and apply it, or they won't work for me any more. Period. Just like they have to know what local variables are and use them. Right or wrong, it's a coding/design standard, and it's perfectly reasonable for teams to choose and enforce their coding standards.

Now, that person might be able to convince me that they have something that solves my problem (a need for easily-changed code that does what the programmer intended) _better_ than TDD. Say, a fancy type system. If so, awesome! I'll listen. But "I'll use TDD when I feel like it" ain't gonna cut it.

<comment><USER21> > _If I'm hiring somebody, they have to know TDD and apply it, or they won't > work for me any more. Period. Just like they have to know what local > variables are and use them. Right or wrong, it's a coding/design standard_

TDD is a workflow implementation and not a coding standard per se. This is to say, code written with or without TDD may be completely interchangeable. This is not true of a coding standard.

Coding standards measurably and objectively affect the end product (i.e. "use local variables", "space/tab indentation", "no method greater than 500 lines", "follow an MVC pattern"). Can the same be said for TDD or [insert workflow implementation here]?

This may be a nitpick, but I feel it's important since it highlights why there is such disagreement on this topic.

<comment><USER7> You and thomasmeeks both said this (that code written with or without TDD may be interchangeable) and I respectfully disagree. Sure, in theory, you could write the same code, but in practice it just doesn't happen. There's a significant difference in the kinds of code that are produced.

Think of it this way. Imagine two different teams. One team has a workflow that involves carefully considering design possibilities and creating design models on paper, and only writing code after those design models have been iterated and refined for a good month.

Another team dismisses that approach as waste, and instead prides themselves on their ability to ship. They start coding on the very first day. Although they care about design, their emphasis is on shipping code, and they would never waste time on modeling.

These are workflow differences. Will the teams produce different code? Of course! They approach the work differently! That's what workflow differences _mean_.

TDD is a different workflow that produces different code. That difference matters.

(See also this reply elsewhere in this thread: <http://news.ycombinator.com/item?id=5334366> )

 _Edit:_ I don't mean to say that TDD will lead to good code. Far from it. TDD done badly leads to some gawdawful messes. But TDD _done well_ does lead to code that is qualitatively different than other workflows _done well_ and that difference--the result of using TDD--is useful to me.

<comment><USER22> Well, yes, if you take it to the ship first vs what amounts to waterfall extreme, there will be profound differences in the code. I suppose if you make it your mission to analyze code to determine whether or not your programmers are using TDD, you could figure it out. But then we're getting into a pretty artificial situation.

Who cares if the code is clean and the project is successful? TDD may be a useful way to get to clean code for /some/, perhaps /most/. But this is not true of /all/. I'm not arguing against its usefulness for someone like you. That's silly, you obviously value it. I'm arguing against the "moral imperative," which is utter nonsense.

TDD is neither necessary nor sufficient for success, and we should stop pretending that it is. I create a class, it has an interface with a purpose, and I test that interface. I don't write tests first, and I don't have trouble writing tests after I write the code. I organize my thoughts on pen and paper, and use very light documentation to test the size and purpose of my methods. The projects I work on are successful, everyone's happy. This is true of several other programmers I work with on a daily basis, but not all. Several also practice TDD, and it works for them.

<comment><USER7> You're moving the goalposts. I didn't say anything (and I'm pretty sure I _never_ have said) about TDD being a moral imperative. Nor did I say it was necessary for success, nor sufficient.

I said "It's reasonable for a job to require TDD... because the TDD workflow results in a qualitatively different code base." I chose an artificial example of how workflows change code to make the point obvious, but the real-world effect of TDD is night-and-day obvious in my experience.

I value that difference to the point where TDD skill is a core part of my hiring decisions. I'm okay with you making different choices.

<comment><USER22> Well, sure, I'm not sure I really care about what particular employers require of their employees. I think it is silly, but I doubt you care much about what I think, either. It was a minor point to me (not to you), which is why we've diverged I think. My moral imperative comment is toward the overall topic, not you.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> "I don't write tests for one line functions or functions that are obviously trivial. Again, they'll be tested indirectly."

The funny thing about this is when I read this bullet point I thought, "Bob Martin would disagree with this". His rules for TDD ( <http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd> ) would force that method to be tested whether he wants to or not. Then I scroll down to see who wrote the article... Bob Martin

EDIT: But maybe he meant to emphasize "indirectly". Maybe it was under test at first but then got extracted into a simple method under refactoring.

<comment><USER24> I only test public methods. These are often composed of private methods which I might pull out of a method once I get to green and I'm working on readability. A particularly common source of one line methods is to extract query methods(replace a calculated variable with an inline call to the new method). A nice side effect of only testing public methods is that if you find you don't have test coverage on the private methods you know you can delete them(because the public methods that used to use them have all been deleted).

<comment><USER25> In my experience if you find yourself wanting to test a private method it probably means it is time to bud off a new class.

</comment></comment></comment><comment><USER26> For me the greatest benefit of TDD is that I can first specify how a unit of code is expected (by me the implementer) to behave. Then I write the code that fulfills (just) those specs, without writing any unnecessary lines of code. If you've read the specs then you know how the code behaves. Yes, you can write the code first then the tests, and I do and have done that. But there's something to be said for letting the specifications alone determine what makes it into code. Of course, you need to know the specifications for this to work, which isn't always the case.

</comment><comment><USER27> It looks to me like another blog posting by a TDD evangelist, most of which I ignore because he ain't preaching my religion. He did, however, touch on what the important part of the pragmatic vs dogmatic question. This jumped out at me:

> In general I don't write tests for any code that I have to "fiddle" into > place by trial and error.

It is congruent with a some general rules I follow to decide if I should write a test for something:

1) Do I care if this code doesn't work on the non happy-path? Maybe I'm writing some isolated prototype code that will probably be thrown away, or perhaps I'm planning to rewrite it later. I'm not going to bother writing tests.

2) How important is it that this code is bug free, and how soon should there's a bug. If, say, the code is in a highly used part of the program that is required by the rest of the app to function properly. Or it is part of the main feature set. I definitely will write tests.

3) I'm under time constraints. If I don't have the time to write tests for a particular part of the code, then I don't have time.

4) How solid is the architecture/interfaces? If I expect them to change quite a bit, then I will not write so many tests, or perhaps any. I once worked on a project that was heavy into unit testing/tdd. There was hundreds of tests written very early on in the project, and since the code was changing so much, we spent a lot of time re-writing tests. It eventually got to be a huge time sink.

5) How much money does the project have? Writing lots of tests takes time, and time is money. I've worked on some projects that have budge (or time) constraints, so I don't have the luxury of such dogma.

All that said, I often dislike programming religions or dogma, because they often advocate following a practice somewhat blindly, without understanding when the rules/precepts should be applied.

</comment><comment><USER28> TDD is a fundamental learning technique. It teaches the principles of modular design. Notice! One can learn modular design in a variety of ways. I make no claim that TDD is "the only" nor "the best" of these, but I claim that it works for enough people to merit attention.

Learning requires investment. Investment carries risk. Risk aversion/tolerance is a very personal and contextual thing. There's almost no point arguing about when it's good to be risk averse and when it's good to be risk tolerant, because of this heavy coupling to the context. Better to be aware of the phenomenon and work things out case by case.

Some people generally don't like to learn. Nothing you do will force them to like to learn. You can invite them to try to learn; you can try to make it comfortable and safe for them. That might work.

Some people find such value in a learning technique that they continue to use it, even after learning 99% of what they will ever learn from it. Continuing to use the technique provides them comfort. Whatever works. Others eventually break free of the learning technique, knowing that they can fall back on it when they feel pressure.

I care about this: people who want to practise TDD should be free to do it; people who don't want to practise TDD should not be forced to do it. Everything else is noise.

</comment><comment><USER29> _I usually don't write tests for frameworks, databases, web-servers, or other third-party software that is supposed to work. I mock these things out, and test my code, not theirs._

If your software has a dependency on a third party component, then you should include that component in your tests. It's not about testing the component, it's about testing your integration with that component. For example, if you upgrade that component, and the API changes in a way that breaks your integration, you want your test suite to break as well.

Sometimes if a component is too slow or requires network access, you have to mock it out. But as a general rule, it's best to leave your dependencies in place.

<comment><USER30> This gets into the differences between unit testing and integration testing. Sometimes it is worth just making sure that your repository class can actually insert, find, and delete data. It's just a different part of the "testing pyramid" (<http://watirmelon.com/tag/software-testing-pyramid/>)

<comment><USER29> A unit's dependency is part of that unit. If a unit test mocks out all the dependencies, that test is running in a fantasy world.

</comment></comment></comment><comment><USER31> My greatest reservation about TDD is one that's almost never referred to by its practitioners: the need for strong refactoring skills. To do TDD right, you've got to be really good at refactoring your code. But many developers know only basic refactoring techniques. So if they do TDD, they end up generating code that looks like it was written to satisfy lots of small requirements, and it lacks the cohesion and clarity that it should have.

I think TDD is taught the wrong way around. First, they should teach refactoring. And only when those skills are thoroughly mastered, should they move on to teaching TDD.

</comment><comment><USER32> >I don't write tests for getters and setters. >I don't write tests for member variables. >I don't write tests for one line functions or functions that are obviously trivial.

I don't disagree, but I often have at least one test that explicitly exercises all of the public interface (of a class/module/whatever). The point is when I change that interface I want tests to break and not have to rely on my memory on what changed when writing release notes / incrementing version number. I mostly test python, YMMV.

<comment><USER7> Those tests are less necessary in languages with static typing, which is Bob Martin's background.

</comment></comment><comment><USER33> What I find fascinating in all this is the sheer amplitude of the invectives. Apparently TDD pushes some people's buttons. I think that's a good thing.

</comment><comment><USER34> The measure is: Find a startup that uses TDD religously, find one that just uses it when it suits them, find one that doesn't use TDD at all. Fix all other variables. See which startup does the best. This is a hard experiment to do but if anyone want to offer me a grant for the research, get in touch. Thanks.

<comment><USER35> > Fix all other variables.

That's literally impossible to do in a straight one to one comparison. If nothing else, you have different people working at each one.

A broader study might get enough data to make meaningful comparisons, but I think strict TDD is too rare to get more than a few samples. It's a tough problem. I think you'd have to set up a completely artificial environment if you truly want to measure the relative efficiency of TDD.

<comment><USER34> Apologies, "Fix all other variables" was supposed to be a joke. Not obvious enough I guess.

</comment></comment></comment><comment><USER7> The cost/value tradeoff of TDD keeps coming up. My comments on this last time were well-received. The question was "Should I TDD an MVP?" but the answer is really appropriate to any question of when and whether TDD is worth it:

This is a really good and interesting question, and it's one I've been struggling with myself.

The problem boils down to this: TDD makes your software more maintainable (if you do it well) and it lowers your cost of development. However, it also takes significant time and effort to figure out how to test-drive a technology for the first time. Everybody can TDD a Stack class; TDD'ing a database, or a web server, or JavaScript [0] is a lot harder.

So the answer seems simple: use TDD for the parts you already know how to TDD.

But it's not so simple! It's much harder to add tests to existing code than it is to TDD it from scratch. Sometimes, it's flat-out impossible. The expense is so high, there's a very good chance that you'll never get around to adding tests to the un-TDD'd code. It will hang around causing bugs, preventing refactoring, and sapping your agility forever, or until you rewrite... and a rewrite of any significance will halt your company in its tracks, so you won't do that.

So the reality is that, anything you don't TDD from the beginning, you'll probably never be able to TDD. Companies that go down this road find themselves doing a major rewrite several years down the road, and that's crippling [1].

There's another wrinkle on top of this: manually testing code and fixing bugs is _expensive_. Once your codebase gets above a certain size--about six developer-weeks of effort, let's say--the cost to manually test everything exceeds the cost to TDD it. (The six weeks number is a guess. Some people argue it's less than that.)

So the real answer is a bit more nuanced:

1\. If your MVP is truly a throw-away product that will take less than six weeks to build and deploy and you'll never build on it after that, use TDD only where it makes you immediately faster.

2\. If your MVP is the basis of a long-lived product, use TDD for the parts you know how to TDD and _don't do_ the parts you don't know how to TDD. Be creative about cutting scope. If you must do something you don't know how to TDD, figure it out and TDD it.

3\. It's okay to be a bit sloppy about TDD'ing the edges of your app that are easily rewritten or isolated in modules. But be very careful about the core of your system.

That's my opinion based on 13 years of doing this stuff, including building five successively-less-minimal MVPs over the last nine months for my JS screencast. The first three MVPs were zero coding, the fourth was a throw-away site, and the fifth was TDD'd with aggressive scope cutting to minimize the number of technologies that had to be TDD'd.

[0] Shameless plug: I have a screencast on TDD'ing JavaScript. <http://www.letscodejavascript.com>

[1] Rewrites are crippling: See Joel Spolsky's "Things You Should Never Do, Part I." <http://www.joelonsoftware.com/articles/fog0000000069.html> (There is no Part II, by the way.)</comment>