Ask HN: Why is not allowing iMessage on Android not an antitrust violation? - <AUTHOR> Certainly seems like anticompetitive behavior.<p>Not having iMessage is by far the main reason I haven't switched to Android <comment><USER2> Yes, this is the Apple "Walled Garden" philosophy, which can be looked at as (a) Apple make no money off it, so why allow it? But Apple can sell apps on Android if they wish. (b) Android security is so bad for the safety of all IOS users we must guard it well.

Added together, Apple can act in an antitrust manner if it wants to, everyone likes to shoot fish in a barrel, and it would take 5 years of litigation to change it - unless some Government body can decide to do it

<comment><USER3> > act in an antitrust manner

Only possible if you have a monopoly.

</comment></comment><comment><USER4> Apple wrote the application, and runs the servers on the back end to support it.

Why shouldn't they be allowed to choose where they should port that software?

Should they be forced to port it to Windows? Should they be forced to port it to Linux? Maybe they should be forced to port it to plain old analog telephone systems?

</comment><comment><USER5> Why is not releasing Mario Party on Playstation not an antitrust violation?

Certainly seems like anticompetitive behavior.

</comment><comment><USER6> Anticompetitive behavior is only illegal when practiced by a company with a monopoly.

</comment><comment><USER3> For the same reason it wasn't an antitrust concern with Blackberry Messenger (cross platform now, but not until 2013; before that it was one of the compelling features that kept many on the Blackberry platform)

</comment><comment><USER7> IANAL: As I understand it, Anticompetitive behavior is tied to proactive actions that a company took; including actions to block others.

Apple is simply choosing to focus their efforts on their platform.

</comment><comment><USER8> Apple has a small market share, something like 15%, and the rest is Android.</comment>


Show HN: Email Cost Calculator – Compare costs across different email providers - <AUTHOR> https://mailswift.io/email-cost-calculator/ <comment><USER2> Email Cost Calculator is a tool that helps you calculate your email marketing expenses over a period of 12 months. Simply choose number of subscribers you have, frequency at which you send emails & your subscriber growth rate and the tool will show how much it costs across different service providers & many related useful metrics.

</comment><comment><USER3> Really nice little service. I was going to create a service myself and was thinking of using Mailchimp but when I saw the comparison to AWS I will no longer do that thanks to this service! Great job!

<comment><USER2> Thank you very much for the feedback! You can use AWS in combination with MailSwift ([https://mailswift.io](https://mailswift.io)) to get up and running with zero coding or maintenance efforts.</comment></comment>


HLayer.js–no dependence,easy use JavaScript dialog library - <AUTHOR> https://github.com/huruji/Hlayer <comment><USER2> Where is the documentation, the how-to-use examples, screenshots, feature list?</comment>


Ask HN: What are problems inappropriate for iterative solutions? - eric-hu

I just watched Gary Bernhardt's talk "A Whole New World" [1].  Two-year old spoiler alert: he introduces an editor and terminal that doesn't actually exist.  His thesis: that some pieces of software--specifically developer infrastructure--take long periods of dedicated thought (without user discovery) to improve upon.  Case in point: Clojure.<p>To you, what are other kinds of technology that can be clearly improved upon, but not "iteratively" in the agile and lean software sense?<p>[1] https://www.destroyallsoftware.com/talks/a-whole-new-world <comment><USER2> Waterfall style development (non-iterative) is appropriate for well defined problems, where there are few unknowns. Here it makes sense to do the majority of the planning up front, since it'll let you consider the design in its entirety. The iteration here comes in the planning phase. Programming languages and text editors are good examples of this - most surprises should be caught in the design phase.

In contrast, where iterative development shines is where there's an external feedback loop somewhere - this is the user discovery that you're referring to. If you don't know what the customers really want, build something, give it to them, and get feedback. The risk to iterative development though is that it's gradient descent - it ends up converging to a local optimum but won't get you to a global one.

Of course, very little development is purely iterative or purely waterfall, but rather it's a spectrum. Programming languages and text editors have version 1.1, 1.2, etc., after all. One of my annoyances with iterative development is that it's often used as an excuse not to plan - so people end up walking into problems that easily could have been known upfront, and ultimately spend more time building a worse solution. Imagine building a house - that the house needs plumbing should be something the architect realizes upfront, not something that should be discovered half way through.

</comment><comment><USER3> Anything where stability is more important than features. E.g. I would be incredibly angry if work paid me a few weeks late, or paid me significantly less than they should, or couldn't process my leave, etc, because the payroll processing software devs took the attitude of "move fast and break things".

</comment><comment><USER3> Any software where backwards compatibility is important requires a lot of "thought" up front. Otherwise you end up supporting half baked solutions for years.

I'm still supporting half baked solutions from 10 years ago because we don't want to break our customers systems.

</comment><comment><USER4> Crypto. You have to get it right, and get it right at the first time.

</comment><comment><USER5> Accounting/record keeping/informatics systems, industrial controls - <AUTHOR> that would lead to a catastrophic loss of some kind.

<comment><USER3> Yep, and if important (to the user) data is involved you better be super sure you don't corrupt/lose it.

I'm still mad at Evernote for losing my data years ago and tell everyone I talk to not to use it.

</comment></comment><comment><USER6> Software that will be used for a long period of time. For example medical devices, or vehicle parts.</comment>


Tappist (WIP) – Email alerts when your wish list Untappd beers are nearby - <AUTHOR> http://tappist.herokuapp.com <comment><AUTHOR> Hey guys,

This is a simple web app I made recently and would love any feedback regarding experience on different devices. I'm sure there are issues so feedback is appreciated!

EDIT: I forgot to add "Show HN" to the subject, but HN isn't let me edit my post. Sorry about that.</comment>


Ask HN: How do you determine potential market size for a web app? - <AUTHOR>

More specifically, what type of information do you look for to inform your guesstimate?
I've started by looking at the analytics of our (future) competitors, specifically unique visitors. This information has varied significantly and am wondering if there are other sources that could help put my guesstimates on a more solid footing..?
Our web app will cater to individual investors, focusing on stocks. So, I've tried finding out the number of individual investors in the US, the size of investment information market, etc, without much luck. Any suggestions about what direction to take would be hugely appreciated!
I, like many before me, am looking to the HN community for help. :) <comment><USER2> Here are some general ideas (applicable to any space) and then some thoughts specific to your domain/sector of investment.

General ideas to help sizing efforts in any market:

\- Are there any public market comparables? If yes, their P&L and financial statements may be useful. Even if there is not a pureplay public competitor, if they have a business unit that competes with you in some sense, you might be able to download their 10k (annual report) or 10q (quarterly) and get some insights in the notes that management must provide or business unit level financials they might provide. This is available for free on sec.gov or even Yahoo finance I imagine.

\- If there are public market comparables, look for equity research about them. In particular, look for reports entitled "Initiating Coverage". These reports when a bank or fin institution starts covering a company usually start with a market overview which can be pretty amazing for intel about the market. Warning: These reports are expensive so best to find a buddy on Wall Street with access to Bloomberg or Reuters who can find download them for you.

\- As a proxy for interest in the space, you might want to see if VCs have recently invested in companies that are similar. Their interest is both a good validator of the market and based on their investment size, it's a proxy for how big the market opportunity might be. This doesn't get you to your specific numbers but maybe a proxy for market interest.

\- Google it. Kind of lame, and I'm sure you've done it but just google "number of investors in the United States" and you may get some places to start. Sometimes even eHow or yahoo answers will be the first breadcrumb to finding something useful

Now to more specific sources for your market:

\- Goto the website of FINRA which is for Financial Industry. It's mainly for brokers and wealth managers I believe, but there will probably be some line on there about how Finra was established to protect the X million US investors. There may be other regulatory bodies with data. These government sites are a treasure especially if you dig around. They'll prob give you investable assets, # of people, etc etc.

\- See if you can find the going public documents of some past successes in the online investing space. I believe TheStreet.com went public. Maybe you can get their S1 filing for when they went public and you can find some stats in there. They are trying to "sell" their IPO at the time so they may provide some stats on how big the market is.

Hope that is helpful.

Have you found research reports that might be valuable but are too expensive? I'd imagine a space this big would have tons of research reports about it. Perhaps an incorrect assumption.

<comment><AUTHOR> Thanks for the advice! I went through TheStreet.com's IPO prospectus and they pointed to the number of online brokerage accounts as proof of the growing number of individual investors. A real gem.

As a result, we're going to use the current number of U.S. online brokerage accounts as a measure of our total potential market.

The only difficulty we have now is cutting that down to our particular segment of the market. We focus on value investors. I haven't been able to find any statistics on value investors but perhaps the number of people googling various value investment related keywords could provide legitimate evidence. Any other ideas?

Thanks again!

<comment><USER2> Here's a terribly unscientific idea since you have an idea of total potential market.

Look at ratio of assets in value mutual funds to all other mutual funds. Might give a sense for size of the "value" market.

</comment></comment></comment><comment><USER3> Once I've determined, qualitatively, which markets might be most appropriate for my web application I try to calculate the maximum possible size using data from the U.S. Census Bureau (for US markets obviously.)

The 2007 Economic Census gives a pretty strong industry by industry breakdown and it's good for coming up with a "maximum possible market size by industry / sectory / region" estimate.

<http://www.census.gov/econ/census07/>

The Economic Census is astonishingly comprehensive, and it's freely available - well worth the look.

</comment><comment><USER4> I wrote something up about this a short while ago, hopefully some of it is some use (I particularly like using the Facebook Ads data to estimate market size - it's easy, accurate and free):

[http://contentini.com/web-app-strategy-why-market- research-i...](http://contentini.com/web-app-strategy-why-market-research-is- important-and-doing-it-for-free/)

</comment><comment><USER5> Yahoo finance (last year) had 20 million unique readers. That probably gives you an idea of the scale of how many people are individual investors or interested in investing.

[http://gigaom.com/2009/07/16/yahoos-number-ones-so-much- more...](http://gigaom.com/2009/07/16/yahoos-number-ones-so-much-more-than- search/)

<comment><USER6> I would bet a large % of those 20M are passive traders, I suspect the author of this thread is looking for active traders?

<comment><AUTHOR> We're looking for investors, rather than traders. We're more focused on the long-term horizon.

The only issue I have with Yahoo Finance figure is that the greater majority of those uniques will be there for news on the financial markets, which is a service we will not provide, at least in the near term.

</comment></comment></comment><comment><USER7> American Association of Individual Investors has 150K members. <http://www.aaii.com/aboutaaii/>

Though most likely, there is a specific segment of that 150K that will really like your product. I'd try to pin down their profile. How do you do it?

Hustle to get a list of names/phone/emails of 100-200 of these individual investors. Call them and collect some demographic info about them along with some industry specific info. Schedule a demo of your tool. After you do a few dozen demos, you will pick up on the trend of the profile of your ideal client who really needs your tool.

It's the general process I'm using right now to do sales and it's working out well in the initial stages.

<comment><AUTHOR> Great idea! We're going to do this once we have a working demo. Thanks!

</comment></comment><comment><USER8> Check out google.com/sktool

This tool will tell you how many people are looking for your solution (or whoever you will steal market share from) with specific keywords.

<comment><USER9> Only 20k/mo searches for "online trading" ?

<comment><USER10> <https://adwords.google.com/select/KeywordToolExternal> suggests 1,500,000 global searches, 368,000 local searches per month for "online trading".</comment></comment></comment>


Ask HN: Why aren't more contact tracing apps using GPS instead of Bluetooth? - <AUTHOR> Many contact tracing apps are only trying to use Bluetooth to decide which devices you're near.
Is that really a good approach?
I don't think so. It doesn't really matter if you're physically near me, if I cough on something and an hour later you touch that, you're very likely to get infected.
Shouldn't the apps trace a persons movement? Then once a case is encountered ping all the individuals who crossed paths?
The persons movements wouldn't necessarily have to be sent to a central server, they could be stored locally.
Are there other concerns or limitations that I'm missing? <comment><USER2> > if I cough on something and an hour later you touch that, you're very likely > to get infected.

Not if you wash your hands regularly and avoid touching your face.</comment>


Goodbye DFJ Esprit, Hello Tim Draper's Increasing Interest in European Startups - <AUTHOR> http://tech.eu/brief/dfj-draper-esprit/

<comment><USER2> I've had a chance to meet Tim Draper multiple times. He's awesome and clearly a veteran VC. Can't wait to see what companies he invests in!</comment>


Unit Testing Doesn't Affect Codebases the Way You Would Think - <AUTHOR> https://blog.ndepend.com/unit-testing-affect-codebases/ <comment><USER3> Love this article. Very interesting, and I love how the results are able to be quantified.

Coming from some projects that had a very heavy unit testing culture, I can agree that unit testing doesn't always necessarily have the intended results on "quality" and can really shape a codebase.

I feel the root of the reason is that testing is not the same thing as development. Truly testing things involves a mentality that is different, it involves understanding how mulitple pieces fit together and operate in reality, not in some unit testing framework. A lot of developers look at unit tests the same way they look at development, once they work, it's done. But testing is proving they work in all the right conditions, not just getting it to work once.

I've personally seen very simple code convoluted so that it could be unit tested, and how those convolutions can easily add bugs and additional layers of indirection that hurt performance (as well as add unnecessary code, which needs maintenance). Many times these tests could have been written with the existing code as long as it used some other component... but then it wouldn't be "unit testing" only to see these components not work together on the first runtime. (For some reason, places that rely heavily on unit testing seem to have fewer overall or integration tests, because they spend so much time and effort on unit testing)

I'd love to see a study on how many lines of code change because of unit tests vs in non unit tested codebases. Both in terms of how many unit tests need to change and the size of the change itself.

<comment><USER4> It's crucial to keep in mind that unit tests are only one part of a healthy test and even TDD-diet. Especially if you write "true" unit tests that use doubles for test collaborators.

The plus side of using doubles in your unit tests though is that the outcome insinuated by your last question should likely be different. I've found that changes typically only impact the unit test of the class or sometimes direct collaborators and a very small number of integration or acceptance tests. If you follow the open/closed principle those changes become even fewer.

<comment><USER3> Totally and completely agree.

But everywhere I've worked in the past 10 years has always asked me to unit test everything, and unit testing is specifically called out all the time.

Other types of tests are rarely even discussed, because many developers don't do a lot of testing beyond unit testing. Sometimes there are other organizations that pick up this slack, like a dedicated test organization, but many times there are not.

Perhaps it's just my experience, but I've found unit tests often give a false sense of security when most of the issues I have to fix (which are frankly the hard issues, not simple logic bugs) heavily involve how the code interacts with its environment. I'm talking OS level, user level, privilege escalation (such as UAC in Windows), networking, load, perf and stress.

It's not that I think that unit tests aren't good, they are, but I think people focus on them too much, to the detriment of other testing. Integration testing should catch all the things the unit tests would catch as well, the only difference is you have two copies of the test, and the unit test will give you more granularity into what is failing when you look at the test suite results. But as soon as you have a call stack or a logging facility (especially around error conditions), which is best practice, most of this is obvious as soon as you look at the result of the test.

<comment><USER4> I totally agree that unit tests for bug prevention in new code are overrated. I mainly like them because they 1. Encourage decoupled code and 2. Make future refactoring easier especially in dynamically typed languages. Not having other tests is a huge mistake. I think I'm spoiled because I've spent my entire career at places that cared deeply about testing and proper TDD.

</comment></comment></comment></comment><comment><USER5> Disclaimer: unit-test proponent hypothesizing.

> But taking the data at face value, the trend lines speak clearly. More test > methods in codebases predict more cyclomatic complexity per method and more > lines of code per method

My initial reaction to this is that having more tests means your code accommodates more and increasingly complex cases and edge-cases in general, because you're not going to write 10 test-cases testing the same logic (or combination of logic).

That's going to mean more code and more complex code either you like it or not.

The projects with fewer test-cases may not handle as many edge-cases, and maybe they don't have this complexity (and the associated tests) because they don't need it yet?

If so, tests themselves are not bad, but may just be indicative of the real world cost of real world complexity?

<comment><USER6> I'm a heavy proponent of writing tests - even if it's not full-on TDD - <USER2> work, to the sometimes annoyance of my co-workers, and my reaction before even reading the results was that for those two, his prediction was wrong.

It seems obvious to me: If you have (good) automated tests for correctness, a method can handle more complexity without the programmer needing to handle all paths in their head at once. The tests should let them know if they made a mistake somewhere. On the other hand, if no such tests exist, those methods would be more likely to be written as smaller methods that call each other (maybe one "driver" and a couple "helpers"), so the programmer doesn't need to hold the whole thing in their head at once.

The odd part is that the second way can often be better for clarity/maintainability, since those helpers can be reused and the driver can be written at a higher level. But it seems like automated tests give people an out where they don't have to think about that anymore.

<comment><USER7> Just to expound on your hypothesis (from another OOP TDD-ish proponent):

Google defines Cyclomatic Complexity as " _a software metric... [that] is a quantitative measure of the number of linearly independent paths through a program 's source code._"

It seems to me that swapping out a dependency, abstracting it, and then feeding multiple variants of the same dependency to some code would greatly increase the number of linearly independent paths through the code. These kinds of refactorings/improvements also tend to greatly increase maintainability, clarity, flexibility, and your programs featureset...

By way of example: taking some DB insert code and updating it write to a simplified interface and then injecting components to handle writing to the DB, a local file for testing, AWS S3, and such... A well-factored, clean, reusable, persistence ignorant solution will have a higher cyclomatic complexity than a hard-coded, raw, INSERT. I know which one I want to maintain, though ;)

</comment></comment></comment><comment><USER8> I love that this post is quantifying results over actual data—a huge improvement over the speculative/anecdotal pattern that a lot of these analyses have.

But the conclusion that complexity and LOC both are higher in codebases with much unit testing... seems very weak. The complexity graph in particular looks very level, with the trendline driven almost entirely by the very low datum for 0-10%, and the LOC graph looks almost as suspicious. That low datum definitely demands further explanation before any conclusions are drawn on those two.

To me, it also inspires two further questions about the LOC methodology:

1) how sensitive is the measure to different coding styles? Does it include the method header? Does it include the closing bracket for the whole function? Does it include open bracket for the function when on a line by itself? Does it include _any_ bracket on a line by itself? With the average method length ranging from 2 to 5, coding conventions on brackets could make a substantial difference, and if coding conventions correlate with testing philosophy at all (for whatever reason), that's a possible threat to validity.

2) Could these averages be dominated by a few larger projects? That is, is the average computed as

      average (length of all methods, all projects)

or

      average ( for each project, (average (length of methods)))

? If the former, larger projects would dominate the average. (True of all the other questions that involve counts and averages too, actually.)

<comment><USER9> In additions to the methodology concerns you raised, I have to question the use of a "linear" trend line, particularly when one axis is arbitrary buckets of unequal size.

</comment></comment><comment><USER10> The consistent bump in the 0% bucket suggests that there is a significant measurement error going on here.

The author acknowledges this:

> So if any of these codebases are using a different framework, they'll be > counted as non-test codebases (which I recognize as a threat to validity).

I'm inclined to say the 0% bucket should be thrown out, since it's impossible to disambiguate between "no tests" and "tests I can't detect". All of the other buckets are quite likely to be correctly classified.

</comment><comment><USER11> Interesting article but I think the number of projects (100) is very low for valid conclusions.

If you have already automated the process maybe you should try adding more projects.

>Unit Testing Appears to Make Complexity and Method Length Worse

I think it is the other way around. People are forced to write unit tests for complex and big methods. So not as negative as your present it.

<comment><USER10> > I think it is the other way around. People are forced to write unit tests > for complex and big methods.

Intuitively this seems correct to me, at least for the code-first paradigm. I do wonder if this holds in the TDD paradigm though, since in that case there are (should be?) tests for everything regardless of complexity.

It would be interesting to try to answer this question with further experimentation along the lines of the OP, though I can't think of any way of detecting/classifying projects as TDD vs. not-TDD without contacting the repository authors (which would be time-consuming, potentially prohibitively so).

</comment></comment><comment><USER12> The results are compatible with "risk homeostasis" or "risk compensation" theory. People who use unit tests have an increased sense of safety, so are more comfortable living with less-safe designs and code-bases.

"Risk compensation is a theory which suggests that people typically adjust their behavior in response to the perceived level of risk, becoming more careful where they sense greater risk and less careful if they feel more protected. Although usually small in comparison to the fundamental benefits of safety interventions, it may result in a lower net benefit than expected" \-- [https://en.wikipedia.org/wiki/Risk_compensation](https://en.wikipedia.org/wiki/Risk_compensation)

[http://injuryprevention.bmj.com/content/4/2/89](http://injuryprevention.bmj.com/content/4/2/89)

</comment><comment><USER13> I like the idea of this study. I wish there were more data behind it. I'd love to see comparisons based on language, or testing tool, for example. Or code base size, age, author count, etc. There also needs to be some weighting of confidence based on how many code bases are in each group. eg, Since there are only four code bases in the >50% group, it's dangerous to draw conclusions based on a trend line when that group is equally weighted with the far more populous groups.

Still, I'm hoping the author expands his datasets and analytical methods as time goes on and I'd be interested to see this topic revisited with a larger sample.

</comment><comment><USER14> What about causality? It seems plausible that people would be more motivated to write unit tests for complex functions that are hard to gain cofidence in otherwise.

<comment><USER15> It seems plausible that people would write shorter, clearer functions that have no possibility of being incorrect if they had no tests to gain the confidence of them being correct.

Also, designing for testability only gives you testability. If you ditch this requirement, suddenly you're free to design directly for ease of use, not for some proxy like testability.

<comment><USER16> > _It seems plausible that people would write shorter, clearer functions that > have no possibility of being incorrect_

This seems exceedingly implausible. If people were capable of writing perfectly correct functions consistently, they'd do so.

Also, in my experience the people who write tests are generally the ones who write good small functions. The people writing massive dense functions are rarely writing good (or often any) tests. (This obviously diverges from the study's results, though, so grain of salt.)

<comment><USER17> In my experience the people who are the strongest advocates of unit testing write small functions. I left off "good" because I don't agree that "small functions" are "good" necessarily.

Often the functions are in fact _too_ small. They properly belong in a larger function as part of that function's implementation, but are "factored out" solely for the purpose of unit testing that piece of the algorithm inside the function.

Usually these small functions are also only called once. In that case especially it leads to messy, bloated code that is in fact harder to reason about, harder to maintain and less efficient besides.

<comment><USER18> > Usually these small functions are also only called once. In that case > especially it leads to messy, bloated code that is in fact harder to reason > about, harder to maintain and less efficient besides.

the flipside is that if this approach is done well, you end up with things broken down along the natural abstraction lines you'd use, and if you trust that your small functions do the right thing (are tested themselves) and are called correctly (their callers are tested well), it tends to make it much easier to reason about the code, IMHO.

but yeah, also, sometimes larger functions and more integration-y tests are the way to go. or the above fine breakdown + unit tests + integration tests. depends on the situation, i think.

<comment><USER19> The tendency is to lock in the first abstraction line that you thought of..which rarely ages well with future experience.

My rule of thumb is that something needs to be a function if it is called 3x, doesn't if it is only called from one place, and if it happens 2x it is a judgement call whether to leave cross-referencing comments between the spots or to factor it out into a function. (If it is unlikely that I will need a third and the common code is difficult to extract, I will leave comments.)

</comment></comment></comment></comment></comment></comment><comment><USER20> Unit testing tells you what you already know. It's kind of pointless, when you think about it (unpopular opinion). If you have a handle on your code there's rarely any need for it.

<comment><USER21> No. Software evolve and there's value in knowing your assumptions still hold after the change/refactor.

<comment><USER20> I don't understand that but thank you for your opinion.

<comment><USER22> The simple way to say it is that once your code gets too complicated to keep all the execution paths in your head (sooner than you think), tests are what enable you to make sure you didn't forget an assumption you made about how it should work.

Do you like going back to manually verify things still worked after you make a foundational change? Or do you just trust yourself to know you've not impacted anything negatively? Do you honestly believe that's good use of your brain power even if true? Do you enjoy being married to that code? Because that's exactly what happens as nobody but you can work on it. That strategy works out well for employees to become key men and get big retention bonuses so there is some merit to your approach :-)

Not to mention the team impact to cowboy coding. It's a selfish approach to software development and is often undertaken by bully developers that say things like "use the source" as a way to make you feel dumb for not wanting to spend all day trying to untangle their likely insane code. All because they were too lazy to use a little empathy and be a good teammate.

To recap: Tests document and improve your design, verify functionality, provide leverage to accelerate development, and reduce "bus factor" risk. I don't care what a small sample data set says to the contrary there's really little debate that when wielded properly these tools and techniques do improve software on multiple dimensions that go beyond the software itself and heavily impact the business.

20+ years of product development experience in lots of teams/products inform this opinion. Let's see the data on how your business grinds to a halt when these tools aren't used and the code base gets increasingly larger and complex and people leave. Tell me about how you don't need those automated tests as you approach technical debt bankruptcy and all your key people have left. "Use the source" is a terrible response to that problem.

Rewrites can be fun though so maybe that's the answer. It sure worked out well for Netscape. ;-)

<comment><USER23> Unit tests are a poor way to validate code behavior. 30+ years of development has taught me that validation tests within the code itself are far better.

1) They run whenever the product runs. Good logging code tells you when it fails, even on customers devices.

2) By being part of the production code, they are far easier to keep up to date as the code changes even through refactoring.

3) They don't force you to change anything about how you code.

<comment><USER24> Agreed. I like to test the validity of a function's input and throw an exception if it fails. It catches most regressions with a nice error message.

</comment></comment></comment></comment></comment></comment><comment><USER25> Interesting article, but too many uncertainties: 100 examples only, the 30 code bases w/o unit tests might have tests the author didn't check or see, and there is likely a cluster effect in this sample to be found. But interesting enough to warrant a large scale investigation to see if those results would really hold.

</comment><comment><USER26> If you define unit tests as tests which test non-divisible units on a low level, then by definition they are a form of tight coupling.

The most loosely coupled form of test would be an end to end test (most loosely coupled, but obviously not without its disadvantages).

Since the pain of dealing with one form of tight coupling is magnified by having another form present, the presence of unit tests act as a sort of canary in the coalmine: if your unit tests are extra painful today, that's probably because the part they are connecting with has a high degree of tight coupling. That might (or might not) lead you to refactor and decouple the rest of the code base in an attempt to mute that pain. Either way you'll feel the pain.

I believe this effect is real. I also don't do this myself, because I don't believe in self flagellation as a means to enlightenment. The best thing to couple your tests to depends upon a range of factors, IMHO, and getting religious about where to couple anything is the worst thing you could do, _especially_ if that religion dictates tight coupling (unit testing all the things).

Method length and complexity probably go up because if you focus on loose coupling (to mute the "unit testing pain") to the exclusion of other good code qualities - less code/less complex code - then those qualities will be sacrificed.

</comment><comment><USER27> Very cool, I'd love to see a more scientific approach to understanding software development methodologies.

What might be interesting is a metric to see how 'refactorable' a codebase is - i.e once a class is created what is the probability there would be significant changes in the future for highly tested vs untested code.

Also the same metrics along a dimension of typed vs untyped languages (my hypothesis would be that unit testing would show more benefits for untyped languages like Python than .NET).

</comment><comment><USER28> The author mentions that they only analyzed the collection of C# repositories that they used in their study on Singletons, but I would expect the results to be different depending on the language used.

In my experience with Python, unit testing is essential to catch careless errors (typos, bad ducks, etc. that can't be caught by a linter) that would cause your program to crash at runtime, so there's a slightly different motivation for writing unit tests. It's a less restrictive language so you don't have the issues with private methods like the author mentioned, and is (at least to me) a bit less of a strain to write tests. Unit testing might correlate more with good hygiene for a Python codebase because testing is vital to check correctness and there are fewer situations where you have to mangle your code for the tests, whereas it may not in C# because you get guarantees from the type system that makes testing less vital and writing tests is more of a nuisance.

</comment><comment><USER29> I was curious about _You can't (without a lot of chicanery) unit test private methods_.

Why is that? Maybe you can't test them directly but private methods should be executed and thus indirectly testable by public methods. If there is code in private methods that can't be executed by any public method invocation, it's unnecessary code isn't it?

<comment><USER30> I've had a similar debate. Someone kept trying to exclude some of our data objects from test coverage reports. I agreed we shouldn't bother testing getter/setters. But, those object better be used in other tests we are writing.

<comment><USER31> The typical argument for getters/setters is that there is some logic that should be performed and that's why the fields should not be public. If there's logic, they should be tested. If there's no logic, they should be public fields.

<comment><USER32> No, the point of getters and setters is that the interface to get and set fields should be the same whether or not logic is being performed behind the scenes, and the caller should not need to know.

Making fields public makes it impossible to add logic in the future without changing other code. That breaks encapsulation and is generally non-idiomatic in languages with getters and setters.

</comment></comment></comment></comment><comment><USER33> My guess is that both variables in these results are almost entirely driven by external factors. Team size, whether it's pro or side project, deadlines, experience/talent of developers, whether tests are required or optional, the language. Hard to draw direct correlations given the sample size.

</comment><comment><USER34> I can speculate as to why this would happen. People expect unit-tested code to have shorter methods because it's easier to write tests for shorter methods.

However, writing a new test for a new method can be harder than just stuffing that code in some other method that already has a test. Depending on how testing is enforced, you might be able to at get away with not having to do anything at all if the existing test still passes. If you're in a hurry and the test fails, just change the assertion to whatever happens. Is it right? I dunno, the test says it's working.

</comment><comment><USER35> I believe you came to a result to quickly by the way you measure the code bases chosen. Lot's of things here that you rund over very quickly without showing anything to back up you right/wrong results.

And sure, tests is of course having an impact on design. As it should have. There is consensus around, at least for the oop paradigm, that this is the case.

I also belive you try to make a once size fit all for measuring tests and that is simply not fair in terms of how differently these codebases are designed and implemented.

</comment><comment><USER36> Awesome article, so interesting. I wonder how language design affects this, I write much better code in Elixir than I do in Node for example.

Maybe though the solution is simple; if you value having low cyclometric complexity/method length/etc. don't let people commit stuff unless it passes the required level. This is certainly working well for me with prettier+eslint... I'll look into other tools based on the code smells in this article I think!

</comment><comment><USER4> I would love analysis like this based on all the data that codeclimate must have. The fact that the test coverage buckets and at 50%+ makes me think that the number of projects that were actually TDDed is very low. I've never seen a project that was truly TDDed with less than 98%. Typically the 2% come from a config file or something like that.

</comment><comment><USER37> A generally interesting study subject.

But it seems not quite thought through.

Projects might only invest in unit tests once a project exceeds a certain complexity, or has seen refactorings with age which made the need for tests clear.

I'm not sure how to normalize properly, but maybe projects solving a similar problem could be compared. Like different ORMs or Databases or Kernels.

</comment><comment><USER38> This is a great direction for research, but wake me when there's been any measurement of significance in the results. Trendlines are interesting but until we've proven that the variation we're seeing is actually statistically significant with regard to the sample size, these aren't actionable results.

</comment><comment><USER39> When I was writing device drivers for the middleware people, I found that unit tests were useful for testing the code and making sure the hardware was doing what it was supposed to. Along with the drivers, I released the test code to middleware so they could use it in their own code.

</comment><comment><USER40> This is just my experience, but the engineers and managers who are the biggest proponents of unit tests don't write tests themselves for their own work. I've noticed this many times in many different jobs and I'm curious as to why it is?

</comment><comment><USER41> While an interesting read, I can't help but wonder about two things:

1\. This is obviously .NET projects only 2\. 100 is a drop in the bucket even if we take C#-only projects. How good are statistical results, is it representative?

</comment><comment><USER42> Why do we expect fewer lines of code with more unit tests? I don't quite follow this.

<comment><USER43> Per function, not overall. A function with more lines of code is doing more, and so is harder to test

<comment><USER44> No, a function can be long but have a low cyclomatic complexity score [1] (being a list of do_this(), do_that(), do_somethingelse(), etc) while a short function can have a higher cyclomatic complexity score (lots of fiddly logic).

[1] [https://en.wikipedia.org/wiki/Cyclomatic_complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity)

<comment><USER45> You could deliberately do that. But most of the time length and complexity correlate. More importantly, when you're _splitting up_ functions to make them testable, you're very much reducing complexity and length in tandem.

<comment><USER17> Splitting up functions just to make them testable is like a code smell, in my experience. It has correlated highly with cultish adherence to testing for the sake of testing rather than to achieve an engineering or quality goal.

It might be reducing "cyclomatic complexity" but not necessarily overall complexity. Often the opposite is true: reduced locality imposes its own costs in maintenance and efficiency for example.

<comment><USER42> I don't think that makes sense, if I had a longish method or a task that could be decomposed into smaller pieces to clearly identify what's happening I would prefer to break it up and test those pieces if it made sense. Obviously this depends on how you do it. DDD talks about this in terms of services and such which might be what your long function really is. In which case you _do_ have to test this large chunk of logic.

</comment></comment></comment></comment></comment></comment><comment><USER46> This is exactly what I want to talk about.</comment>


Ask HN: Web app microtransaction vs. subscription? - <AUTHOR>

Instead of a monthly subscription, anyone can use the site but advance functions require credits/micropayments. For example, Basecamp - if you add more people its $2 per month per person. if you like to add 50mb or 100mb add $2 or $4 month. Would this work? This has happened in the MMO space. whats stopping it from working in the web app space? <comment><USER2> The fact that users hate microtransactions with a passion outmatched by a thousand burning suns, and that for the same amount of effort to convince a real business to buy $5 of credits, you can convince them to sign up for a $20 a month subscription in perpetuity.

</comment><comment><USER3> I've often wondered this too, so I'll take a stab at why it hasnt:

\- in mmos the transactions are impulse buys and often not major decision points for the purchaser. The "do I need this?" question isn't a high priority. Of course you need your virtual crops to grow faster.

\- with web apps, especially saas apps, this isn't an impulse buy. You've been trying the app out for a while and every dollar you spend is accountable. You're much more likely to ask "do I really need this?"

</comment><comment><AUTHOR> How about if it a consumer web app like say Flickr or Picnik or Dropbox?

One benefit of microtransaction payment providers is that they have a multitude of payment method including load cards, pay thru sms, etc.

I would think that consumer web app would have better revenue if it was ARPU instead of 2-5% conversion rates. Does this make sense to anyone else?</comment>


Using evolution of neural nets to get artificial intelligence [video] - <AUTHOR> http://www.youtube.com/watch?v=_m97_kL4ox0

<comment><USER2> The book Blondie24 is an interesting popular science style account of this type of AI.

[http://www.amazon.com/Blondie24-Playing-Kaufmann- Artificial-...](http://www.amazon.com/Blondie24-Playing-Kaufmann-Artificial- Intelligence/dp/1558607838/)

They partially trained their checkers algorithm by playing it online against humans. The funny part was that they couldn't get many opponents until they changed their handle to Blondie24, then game requests came flooding in...

</comment><comment><USER3> Transcript available? No Flash here.

I suspect this is a resurgence of the decades-old idea of using evolutionary algorithms to find weights for neural network nodes.

<comment><USER4> Google on Polyworlds and/or virgil griffith or go to virgil.gr for more info.

</comment></comment><comment><USER5> Very, very cool. I'd love to get into this field (I'm tryin!).</comment>


Show HN: Afx player - <AUTHOR> http://afx.complected.software <comment><USER2> Never thought i'd see Aphex love on HN.</comment>


Show HN: NowVia – Save, organize, and discuss the things you find interesting - <AUTHOR> https://www.nowvia.com/

<comment><USER3> Great design work!

But I have to wonder, how is this different from Pinterest?

<comment><AUTHOR> Thanks!

When you save something on NowVia, you see who else has saved it and what people are saying about it.

So imagine 19 people from around the world save a great design resource - <USER2> doing so, they discover each other's channels, and can all discuss that resource in the same place. The 20th person to save that resource also sees that discussion and can join in. The focus on connecting people through interests and trying to encourage discussion is the differentiator.

<comment><USER4> Like delicious used to be?

<comment><AUTHOR> Yeah, that's kinda what we're aiming for.

</comment></comment></comment></comment><comment><USER5> [http://jokund.com/](http://jokund.com/) oops...

<comment><AUTHOR> The image? Haha yeah, we got it from [http://unsplash.com](http://unsplash.com) \- I'm guessing they did too!

<comment><USER5> I see :)</comment></comment></comment>


Aquatic habits of the extraordinarily long-necked Triassic reptile Tanystropheus - <AUTHOR> https://www.cell.com/current-biology/pdfExtended/S0960-9822(20)31017-4 <comment><AUTHOR> >Making Sense of 'One of the Most Baffling Animals That Ever Lived'

>Important mysteries have been solved about a reptile with a giraffe-like neck that hunted prey 242 million years ago.

[https://www.nytimes.com/2020/08/12/science/reptile-long- neck...](https://www.nytimes.com/2020/08/12/science/reptile-long-neck- fossil.html)</comment>


'Clock kid' sues Texas school, city: did they violate his constitutional rights? - <AUTHOR> http://www.csmonitor.com/USA/Justice/2016/0808/Clock-kid-sues-Texas-school-city-did-they-violate-his-constitutional-rights <comment><AUTHOR> Disclosure: There are dozens of sources for this news (several local outlets possible as well) following the Press Conference. This is an Associated Press write-up so figured it was going to be palatable. Feel free to change where it points & the title if something is...well...more appropriate I guess.</comment>


Scientists improve smart phone battery life by up to 60 percent - <AUTHOR> https://techxplore.com/news/2018-11-scientists-smart-battery-life-percent.html <comment><USER2> ...for certain apps. Not for the OS, nor for extending the lifetime of a dormant phone.</comment>