Excellent post. Would have left a comment on the original article but I'm not about to give permissions to a new app just to leave a comment. Please consider an alternate comment system.
Thanks ndunn2. When I built the commenting system, I figured that asking people for the bare minimum information from their twitter account would be enough to get them to sign up, but it really seems I was wrong. I worried anon posts would result in too many "stfu nigger fag" type comments, and didn't want to give up any design to Disqus. And sign-up on the site I figured was too much of a hastle. Ugh......
When you reach a certain size, no amount of due diligence on your part can ensure that your changes aren't going to break something in some other part of the code base without automated tests. Do you think Google or Amazon gets by without unit tests?
I'm not saying they're not useful, pinterest is hardly a giant in my opinion, they do one thing and clearly do it well. I'm sure their position on unit tests will change, hopefully before they are burned.
It is not impossible to have a large code base without unit tests. I'm sure my employer's code base is in the millions of LOC. At least 99% is not covered by unit tests. Probably 99.9%.
That might work for you, but is a bad idea in 99% of cases (I am not implying that most code has tests in place). I guess your code changes very rarely.
If you have to change something in core part of application with a lot of dependencies, good luck. Also, when several programmers are working on the same part of code (perhaps in a span of 5-6 years), they will need some time to understand code to be changed, then think more where something might break if they change it. At the end, they will lose a lot time and still not catch all the interactions with other code.
It took me a lot of time to understand why people want to write tests first, then code. It was more natural for me to make optimal code, then test expected/unexpected inputs and edge cases. The answer turned out to be that code ends up much cleaner and all code paths end up tested properly because you never write a single line of code which isn't explicitly there to satisfy a test.
It's interesting but I don't know if I agree with the conclusion that writing this small function in C would make maintenance too hard. How often do you expect to have to change it?
Maintainance in this case involves the effort of deploying to servers, compiling it as necessary, and similar efforts. The deployment process is complex as is (internally, of course --- it's one script to run --- but that doesn't help if something obscure breaks). I suppose it would be possible to produce it as a python package and use those standard methods, but at that point it makes sense to open source and then it should be beefed up and so on and so forth.
I second the design comment. Extremely easy to jump in and start, no log-in bs, nothing to get in your way. The minimalist aesthetic is nice as well. If only I knew how to play chess..
