A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

пре 4 година
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165
  1. title: Popularity
  2. url: http://soveran.com/popularity.html
  3. hash_url: 2e27bb3e5b294d0e6e3bf9d12977eb32
  4. <p>Donald Knuth once said: "If I find too many people adopting a
  5. certain idea I'd probably think it's wrong".</p>
  6. <p>Good tools can be popular, but that doesn't imply <em>all good
  7. tools are popular</em>, or <em>all popular tools are good</em>. We
  8. can reflect on whether the same logic applies to something other
  9. than tools: for example, are the best singer and the most popular
  10. singer the same person? Is the most sold beverage also the best
  11. one? It's tempting to distance ourselves from the problem and discuss
  12. what "best" means, but I think we could agree that, at least in
  13. those examples, we would be talking about two different singers and
  14. two different beverages. And yet, what if most people think otherwise?
  15. If most people think otherwise we would think they are wrong, just
  16. as Donald Knuth said.</p>
  17. <p>In software development, a lot of people pick the most popular
  18. tool that can solve a given problem. Popularity is measurable: you
  19. can check the number of downloads, the number of stars, the questions
  20. and answers all over the web. Quality, on the other hand, is hard
  21. to measure: you have to read the code and prove its correctness,
  22. evaluate several metrics and heuristics. It's hard work compared
  23. to counting stars. Then, as a lot of people pick the most popular
  24. tool that can solve a given problem, the popular tool gets more
  25. downloads, more stars, and more people ask questions about it.
  26. Popularity is the best trait for becoming more popular.</p>
  27. <p>If I find too many people adopting a certain software tool, I'd
  28. probably think it's bad. It would require an in depth analysis to
  29. convince me otherwise, because the mechanics at work are well
  30. established.</p>
  31. <p>A bit over a year ago, somebody pointed me to <a href="http://tinyurl.com/ov6hbgd">a conversation</a> in a forum
  32. regarding a tool I've been using for the past five years. I will
  33. reproduce the ideas here.</p>
  34. <p>It all started when the co-founder and CTO of a tech company
  35. asked for help to decide whether or not using <a href="http://cuba.is">Cuba</a> would be a good fit for his project.
  36. Here's the original post:</p>
  37. <blockquote>
  38. <p>My company hired a team of developers to build an MVP of a web
  39. app. We've talked exclusively of using Rails, but now that they've
  40. started development, they're using a microframework called Cuba.</p>
  41. <p>Is anyone familiar with Cuba? I've been vetting it all day and I'm
  42. not sure about it.</p>
  43. <p>The main benefit is that it's tiny (
  44. </p><p>If anyone has any thoughts, please share them.</p>
  45. </blockquote>
  46. <p>Many replies followed, some of them stating the fact that using
  47. Cuba would be fine, especially if the team was comfortable with it.
  48. Others replied that, as they had never heard of Cuba, it was better
  49. to use Rails or Sinatra.</p>
  50. <p>A few days later, the original poster sent this message:</p>
  51. <blockquote>
  52. <p>Thanks for all the valuable feedback everyone!</p>
  53. <p>I agree that I would prefer a framework with a larger community,
  54. but we're going to go with Cuba for a few reasons:</p>
  55. <p>1. The team is very comfortable and efficient with it.</p>
  56. <p>2. It's essentially the same as Sinatra at its core, but claims
  57. to be smaller and faster.</p>
  58. <p>3. Cuba itself is extremely easy to work with because it barely
  59. does anything. You can read the entire source in 5 minutes and
  60. understand it completely. I'm confident future teams could pick it
  61. up.</p>
  62. <p>4. Even though there's little to no community, Cuba is very well
  63. tested, and simple enough that I'm not worried about deprecation.</p>
  64. <p>I thank you all again for taking the time to share your thoughts.</p>
  65. </blockquote>
  66. <p>At that point the CTO was convinced the technology was sound.
  67. The fact that there was little code to read probably helped. One
  68. person argued that strict discipline with the project structure
  69. would be required, someone else expressed concerns that in the end,
  70. the team would have to "rebuild Rails" in order to match its
  71. functionality. The original poster then replied.</p>
  72. <p>About structure:</p>
  73. <blockquote>
  74. <p>Thanks for the concern. I've been working with
  75. the team and overseeing the repo on GitHub since the very beginning
  76. of development. I was very vocal about my concerns, which were very
  77. similar to yours. It turns out the team is very experienced in
  78. building large scale production quality apps in Cuba, and are very
  79. organized, which is a relief!</p>
  80. </blockquote>
  81. <p>About rebuilding Rails:</p>
  82. <blockquote>
  83. <p>I was worried that the team would have
  84. to "rebuild Rails" as well, but the thing is, many parts of Rails
  85. aren't required by most apps, and they've done this before, so their
  86. toolbox is already full of handpicked solutions for common problems
  87. that a web app would face. If I was doing the development, I would
  88. absolutely choose Rails because I'm not comfortable enough with the
  89. microframeworks to be able to achieve any sort of efficient result,
  90. but so far we've been in development almost a week and I'm quite
  91. pleased.</p>
  92. </blockquote>
  93. <p>He posted the original message because he had the same concerns
  94. other people expressed in their replies, yet after only one week
  95. of development those concerns were addressed and he was happy with
  96. the decision. That didn't prevent further criticism, and many
  97. comments followed recommending Rails and Sinatra as alternatives
  98. based on familiarity and popularity.</p>
  99. <p>Finally, an extremist suggested to fire the team:</p>
  100. <blockquote>
  101. <p>If you have an agreement that they use Rails—get them to use
  102. Rails. Simple as that. They just can't decide to use something else
  103. without discussing that with you. Since they are not keeping to the
  104. agreement, don't pay them. Even the Sr. Engineer can't make such a
  105. decision without discussing it with the customer. I think their
  106. behavior is very very unprofessional.</p>
  107. </blockquote>
  108. <p>If you care about your tools and recommend what you think is
  109. best, somebody may still think you are unprofessional and you deserve
  110. no pay.</p>
  111. <p>Rails, Sinatra and Cuba are tools with different traits, and
  112. it's expected that people will recommend whatever works for them.
  113. But we should be extremely cautious about taking what is popular
  114. for what is good, and conversely we should not disregard something
  115. just because it didn't gather enough stars. I'm not claiming here
  116. that one of those tools is better than the others: even if I have
  117. a strong preference, the question should be open and the code should
  118. be analyzed by the potential users.</p>
  119. <p>When Rails was created, Ruby wasn't mainstream. When Twitter
  120. launched, Rails had been out for just four months. Adopting Ruby
  121. and Rails were bold moves made by people that didn't care about
  122. popularity. They were forced to assess the quality despite the lack
  123. of stars.</p>
  124. <p>Technical analysis is hard work. Following the crowd is easy,
  125. but it's often a shortcut to the wrong place.</p>