brikis98

As with any term that becomes a "buzzword" (e.g., DevOps, Lean, Agile), the definition of MVP definitely gets muddled and everyone has their own take on it. I could replace the term with "how to build products by repeatedly identifying your riskiest assumptions and building the smallest possible experiment to test them", but I think "MVP" is a bit easier to read.

> This article is more about "how to find out what an MVP might be".

This sounds a bit tautological. An MVP is the smallest possible experiment to test your assumptions. To find out what that experiment should be, you have to do an experiment to test assumptions...

Also, one of the key ideas in the article is this is not something you do once to build a single MVP. It's a process you use over and over again to develop every aspect of your business, including the product, marketing strategy, software architecture, etc. For example, to build a large software system, you don't write 100,000 lines of code, then hit compile, and hope it works. Instead, you do it incrementally. Write a few lines of code, test them, make sure they work; write a few more lines of code, test them, make sure they work, and so on. Or to quote John Gall, "A complex system that works is invariably found to have evolved from a simple system that worked."

> Adding an extra feature nobody needs means you've not built a minimum product.

This reminds me of the No true Scotsman fallacy [1].

"No MVP should have unnecessary features."

"But that successful company's MVP had all sorts of unnecessary features."

"Yes, but no true MVP should have unnecessary features."

This sort of critique isn't wrong, but it's not useful. How do you figure out which features are necessary and which ones aren't? The best way I've found to do that is to pick your riskiest assumption and to test it. And to do that over and over again, incrementally building up your product as you go. If you don't like the term MVP for that, I suppose that's fair, but then please suggest a better term to replace it.

[1] https://en.wikipedia.org/wiki/No_true_Scotsman

As I've written before [1], I find it confusing that some people believe "10x" or "rockstar developers" are a myth. Are star athletes, artists, writers, and, uh, rock stars, a myth? Why would the programming profession be the only one where there are no major differences in performance?

[1] http://www.ybrikman.com/writing/2013/09/29/the-10x-developer...

Nice! I maintain a list of startup idea lists [1]. If I get some time, I'll add your list too, but if anyone else is feeling up to it, the repo is open source [2] and I'd gladly accept PRs :)

[1] http://www.hello-startup.net/resources/startup-ideas/ [2] https://github.com/brikis98/hello-startup-site

Ah, thanks for the heads up! Doesn't look like I can edit my post anymore, but the proper link is: https://www.goodreads.com/user/year_in_books/2015/1363537

My full list of books, including reviews, is here: https://www.goodreads.com/user/year_in_books/2015

From that list, my favorite ones were:

The Four Steps to the Epiphany: https://www.goodreads.com/review/show/827338560

Made to Stick: https://www.goodreads.com/review/show/897777811

How to Measure Anything: https://www.goodreads.com/review/show/698402984

The Non-Designer's Design Book: https://www.goodreads.com/review/show/1170518622

Masters of Doom: https://www.goodreads.com/review/show/899580915

The Martian: https://www.goodreads.com/review/show/1136330196

The Mistborn Trilogy: https://www.goodreads.com/review/show/1388373037

That's a very interesting point that I never fully considered. Of course, there is no doubt that some content providers already are taking money to reflect someone else's agenda, but it's definitely worth considering what happens if advertising fails as a business model for the majority...

Nice. It really seems like static typing and functional programming are winning [1]. For the most part, I think that's very a good thing, and may help move the software industry forward.

[1] http://www.ybrikman.com/writing/2015/02/06/are-static-typing...

Depending on where you are and the size/stage of the startup, those numbers seem roughly in the right ballpark. To compare, check out the salary resources[1] and equity resources[2], which have calculators and tables that show you typical numbers.

  [1] http://www.hello-startup.net/resources/salary/
  [2] http://www.hello-startup.net/resources/equity/

Most developers are hesitant to accept new programming paradigms, so it takes a very long time to change how people write code (something Brett Victor captured brilliantly in his talk, The Future of Programming [1]). Therefore, I can't really say if "ten years from now" is the right time frame or if it's more like thirty years.

That said, I think it's safe to say that static typing is "winning" if it ends up being used in almost every single one of the top 10 programming languages. By "used", I mean it's used in the vast majority of the core language libraries and by most major companies that depend on the language. Depending on which popularity chart you want to believe (e.g. langpop [2], TIOBE [3], or RedMonk [4]), the top 10 languages are roughly the various flavors of C (C, C++, C#, Objective C), Java, PHP, JavaScript, Python, Ruby, Perl, and Shell. With the exception of Perl (which will not be in the top 10 for much longer) and Shell (which will probably be in use for a long time), all of those are already statically typed or moving towards it.

I think a similar metric could apply to functional programming: if the top 10 languages use functional programming in the vast majority of the core libraries and by most major companies, then it has "won". This will likely take longer than static typing, but if companies keep adopting languages like Scala and Clojure, they may crack the top 10 some day.

Of course, it's worth mentioning that what's really "winning" right now is a hybrid model: a mix of static and dynamic typing and a mix of imperative and functional programming. Perhaps, in the long term, we'll find where each type of approach works best, use them side by side, and they'll both "win".

[1] http://vimeo.com/71278954 [2] http://langpop.com/ [3] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... [4] http://redmonk.com/sogrady/2015/01/14/language-rankings-1-15...

Yes, most languages have a type system, but there is a big difference between only checking those types at runtime ("dynamically typed") versus checking them at compile time ("statically typed"). After an years and years of debating back and forth over the trade-offs between dynamic and static, it looks like the most popular dynamically typed languages are all considering adding compile time checks. It may take years for these features to gain widespread usage, but it's hard to see this and not think that static typing camp is winning the debate.

As for functional programming, I mentioned in the post that adding a few functional features does not mean you have a functional programming language. But again, for years there was a debate over whether the imperative and OO styles were better and if the ideas from functional programming were too esoteric for the mainstream. Now, some of the most popular imperative languages are focusing on first-class functions, higher order functions, pure functions, and immutable data. It'll still take years for all of these ideas to gain widespread usage, but again, it's hard to see these changes and not think that functional programming is winning the debate.

Here is a guide to documentation I wrote a little while back: http://brikis98.blogspot.com/2014/05/you-are-what-you-docume...

I just tried to go through the coveredca.com application process and it was a nightmare. It took me 5 hours, spread over two days, 3 tech support calls (I never call tech support!), and 3 different web browsers to get through it.

1. Fill out the very first part of the application - just basic name and address - click "continue". Error page. WAT.

2. Notice they have an outline view of the application. Use that to get to get past the error page. Now it's asking for my "Certificate of Citizenship" number. WAT. No form I have ever filled out - tax returns, financial aid forms, employment forms, DMV forms - nothing has ever asked me for this. Spend a day searching for it.

3. Finally find the number, fill it in, click "continue". Error page. WAT.

4. Use the outline again to get to the income section. It lists me twice, as if there are two separate brikis98's in my household. It even asks me "how is brikis98 related to brikis98"? WAT.

5. Call to tech support #1. After 45 minutes of messing with the application, clearing cookies, logging out/in, we couldn't figure out how to remove the extra "me". There is no way to completely restart an application. Solution from tech support: sign up for a completely new account - new user name, password, etc - but don't enter your SSN too early or it'll detect the duplicate account. WAT.

6. Sign up for a new account. Start filling out the application from scratch. Error page. WAT.

7. Use the outline trick again. Go to income section. No duplicate "me" this time - yay! However, now it asks for "monthly income". I just left my job, so my monthly income is zero... but I obviously had a monthly income the first 5 months of this year. Call to tech support #2. They tell me to take all the money I've made this year, divide it by 12, and put that as a monthly income. WAT.

8. Finish filling out the application. Get to a page that has a button to "See Eligible Plans". Click the button. Error page. WAT. There is no outline view to get past this one.

9. Call to tech support #3. After half an hour more, the suggestion is to try another browser. I switch to Firefox. It tells me coveredca.com does not have a valid SSL cert. WAT.

10. Switch to Safari. No complaints about the cert. Log in, click the "See Eligible Plans" button. The page loads - yay! However, the UI is broken, with strange scrollbar-in-a-scrollbar setup that makes it very tough to browse the plans. Download PDFs of each one for easier reading.

After all that, I found that the plans were all way overpriced for the comically bad benefits they offered.

Thanks for the feedback. I updated the post with notes that mention these corrections.

Re-read my reply above. You're comparing a fraction of Gretzky's contribution to a fraction of all the professional hockey players, even if you only look at forwards. Even then, he ends up 2-3x better than this already elite group.

250th on the list of all time NHLers? That's still a tiny percentage of all players that have every played (~1500/year, obviously with some overlap from year to year). And that's only counting those in the NHL; there are many hockey "pros" who could only dream of making the NHL. Factor them in and the Gretzky performance is even more remarkable.

And you're only looking at points scored. How does a star's leadership affect their team? How did their mere presence affect the other team's entire strategy? How many seats does a star fill in the stadium every time they played? How many jerseys and other merchandise did they sell? Hockey, like software, is a business and I'd be that someone like Gretzky brings in an order of magnitude more money than an "average" hockey pro.

Denying the possibility that there could be someone 10x better than you is the real ego stroking. I know there are developers an order of magnitude better than me. I find that inspiring, as it gives me something to work for every day.

Actually, in the case of Gretzky and Lemieux, I believe they did average ~10x more points (and other contributions) per season than the average player. Also, don't forget that the NHL is just the best of the best; there are many hockey players that are "pros" but never make it to the NHL. When you factor them in, players like Gretzky may be several orders of magnitude better than average.

>> it blows my mind to think there's a large number of people out there who in just a few hours could knock out everything I spent all of last week on.

First of all, as I wrote in the post, 10x programmers are rare. There isn't a "large number" of them.

Second, it's not about producing more lines of code per minute or per week. It's about producing the maximum value (for lack of a better word) in a time period by making good decisions.

I'm not a 10x programmer and the results on my own work week are pretty obvious: when I look at it closely, I realize that I spend a lot of time dealing previous mistakes. I lose days because I made a solution that's too tightly coupled and it's hard to adapt the code to a new situation; I didn't add enough tests and waste lots of time fixing regressions; I didn't add enough documentation and can't remember why I made certain decisions; I've created designs that don't scale and need to be replaced entirely; and so on. Since it's harder to read code than to write it[1] and since the cost of fixing defects increases dramatically later in the software process[2], these bad decisions eat up an enormous amount of time.

However, as I learn more, I've noticed that I spend a much higher proportion of my time solving the "real" business problem instead of dealing with previous mistakes. In other words, I'm becoming dramatically more productive than I used to be, not because I'm typing faster, but because I'm avoiding/reducing entire branches of work that used to eat up my time.

These sorts of effects multiply: for the 10x programmer, the gain in productivity can be huge and they will be able to get an order of magnitude more done than the average coder.

* [1] http://www.joelonsoftware.com/articles/fog0000000069.html * [2] http://en.wikipedia.org/wiki/Software_testing#Economics

First of all, some star athletes are statistically far more than 10x better than the average. For example, the average NHL player scores less than 50 goals in his career [1] whereas Gretzky scored 894 [2] and Mario Lemieux scored 690 [3]. And that doesn't even count their assists, leadership, defense, name recognition (bringing in fans), etc. And I'm not even comparing these guys to other pro hockey players, such as the minor leagues and leagues outside of the US.

However, not all sports have "points" that scale the same way, so the 10x number is not as easy to apply. For example, Usain Bolt is not literally 10 times faster than the average professional sprinter; his best 100m is 9.58 [4], where as any moderately fit male can easily hit sub 20 seconds, and I believe any professional sprinter will go under 11 seconds. Nevertheless, I'd guess that in the 100m sprint, a difference of 1 or 2 seconds represents an order of magnitude (or two) difference in ability, even if it's only 10-20% of the time. What kind of odds would you give him in a race against an "average professional"? 10:1? 100:1? 1000:1? Usain is roughly as far above other pro sprinters as Gretzky and Lemieux were against other pro hockey players.

I'd also mention that "fame" is a bit of an x-factor. The world is not a perfect meritocracy and there is so much luck and so many external factors that go into being famous that it's not necessarily true that only famous scientists/musicians/writers are the only ones who are 10x. Of course, the famous folks are the only ones I can reasonably use as examples, and fame likely correlates with talent, though that talent may just be at being famous :)

[1] http://www.quanthockey.com/Distributions/CareerGoals.php [2] http://www.nhl.com/ice/player.htm?id=8447400 [3] http://www.nhl.com/ice/player.htm?id=8448782 [4] http://en.wikipedia.org/wiki/Men's_100_metres_world_record_p...

Our Play frontends are entirely reactive/non-blocking, so yes, we're using the async features very heavily. We'll have a blog post about this in the near future.

Our Play backends, if they use JDBC to talk to a database, are fully blocking, since pretty much all JDBC drivers are blocking. One of the nice things about Play is it's easy to configure the thread pool to handle this configuration as well.

Play is an open source project that has been around for a few years. In fact, that's one of the big selling points for us: we're not inventing something new, but using something the community is using, and contributing back to it.

LinkedIn has been using Grails for ~4 years. It's a terrific framework, but we found that Groovy was one of the downsides. The language is very easy to learn and use with Java, but we found that it didn't scale nearly as well to large numbers of users or developers. It's worth noting that this was pre Groovy 2.0, so I'm not sure what has changed in the latest version of the language.

We had Java services that produced JSON, some that used JSPs, and a variety of others. TDD works in some cases, but if you ever wanted to do manual testing - for example, actually see the UI you were working on with real data - that meant redeploying the server after every change.

Play makes this dramatically faster/easier. TDD is better with Play as well: the plugin support, strong test tools, and sbt's ~test command are amazingly productive.

For simple setups, that can work. JRebel can help. For more complex servlet apps, especially those with Spring lifecycle management, this rarely works, which means a full redeploy after almost every Java change.

Play actually has a really nice plugin system, which we used extensively to integrate Play at LinkedIn. The plugin system offers lightweight support for DI. For example, to use a FooPlugin, you don't use it directly, but ask Play for an instance of it:

FooPlugin foo = Play.current.plugin(FooPlugin.class); foo.doSomething();

What instance you get depends on configuration (typically, a play.plugins file), which makes it easy to swap out implementations at test time. Much of Play's built-in functionality is implemented as a plugin too, including the DB code, so writing unit tests is pretty simple. There is strong support for "fake applications", integration tests, etc: http://www.playframework.com/documentation/2.1.0/ScalaTest

We'll blog more about Play plugins in the future.

LinkedIn is primarily a JVM shop. We believe that type-safe languages like Java and Scala are a good choice for building performant and reliable systems that scale to huge numbers of users as well as huge numbers of developers. We aren't constrained to the JVM - for example, we use node.js for our mobile server - but it has significant advantages and we have years of investment in it.

Unfortunately, we found developer productivity in the Java/Scala world to be a huge problem. We also found that most Java/Scala web stacks, based on servlets, were far behind other web frameworks (RoR, Django, etc) in terms of keeping up with the requirements of modern web development. Play helps on both fronts: it dramatically improves developer productivity and handles all the requirements of a modern web stack (MVC, web sockets, powerful routing, easy JSON handling, DRY form handling, etc).

Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive programming model is dramatically better than JavaScript's callback mess), in some ways no (e.g. it's hard to compete with dynamic/interpreted languages for pure reload time). Is it better than everything else in the Java/Scala world? We think so.

On my wimpy Macbook Air, most Java changes reload in < 3 seconds. Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. Combined with the scala console in sbt for interactive coding, the ~test command in sbt for automatically rerunning tests on each change, and the amazing error handling, this is a massive step forward for Java/Scala web development.

LinkedIn uses a service-oriented architecture; the site consists of hundreds of individual services - that is, separate codebases, deployed on separate hardware, built on a handful of different technology stacks. This lets us iterate and scale each service separately depending on its requirements.

We've moved some services to Play already and are now gradually rolling it out for others.

What errors?

IMO, SASS ~= LESS, but Compass > *. Damn shame that Twitter Bootstrap went with LESS.

Very cool. And kudos on the clean documentation.

Cars are not a good analogy for this situation, at all. The presence of software and computers in our life is much closer to the invention of the alphabet and writing. Written text gradually becomes so ubiquitous in life that being illiterate is a serious handicap for anything you want to do.

Likewise, the amount of software and technology we deal with on a daily basis is increasing at an exponential rate. It is just a matter of time before the ability to deal with it at a deep level becomes a necessity of life.

Of course, not everyone will be paid to write code, just like not everyone is paid to read/write, but you'll be handicapped in life if you don't know how to do it. Moreover, coding itself will largely change as well: programming languages are constantly adopting every higher levels of abstraction and gradually becoming more accessible to a wider audience.