During this same period, I launched 2 SaaS products on boring PHP 7 and Python for the backend and HTML, jQuery/intercooler.js for the front-end. Both profitable and growing.
I think sometimes devs don't realize the hardest parts of starting and growing a business have nothing to do with code or the tech stack you choose. Marketing, getting and retaining customers and everything else in between is way harder than writing code.
Why? Because it doesn't reduce cognitive load. One seems to require at least as much brain space to code things in Angular, as you do just writing pure Javascript. That's a no-no, that means it's not a labor-saver long-term.
I use Scala because Google App Engine didn't support PHP for example. It's an Android app, so I use Kotlin for that.
I personally do not want to spend time re-writing my app every 6 months before it is even launched. I would much rather spend the time acquiring customers. I tend to choose a stack at least to start that I know I won't need to re-write in 6 months. Unless of course it needs to be re-written/refactored to accommodate all those customers knocking at my door ;)
That generally means I stay away from the front-end flavor of the week when starting a new app. Don't get me wrong, I myself have used Angular and Vue for a couple of projects but not in the beginning and not for the core product. I don't like the instability and constant changes of a lot of the newer frameworks.
It's usually best to focus on propping up your differentiation and competitive advantages, going stock with everything else. If you rely on standard components for things that aren't your special sauce, then you get to ride market forces of commoditization which will drive the cost of those standard components towards zero.
Can you build your own backend database in Haskell instead of using Cassandra or PostgreSQL? Yeah, that would probably be really cool and do well on these boards. Then look back at how many hours you spent getting that to just understand simple SQL, and how many customer-facing features that could've been. Is it cooler to build that database than to set up an email auto-mailer? Yes! Special functional algorithms that operate on B-trees are far more exciting than simple state machines that send emails. But the latter is what the customer cares about, so therefore that's what you care about.
One interesting exception to using cutting-edge stuff may be making it easier to hire cutting-edge people.
It doesn't matter how smart you are. The opinion of the market is the only one that matters, and it expresses it in the form of repeat sales.
I want to emphasize this, and expand on it: Your cool tech startup is not about the tech.
You exist to solve a problem.
Sure, you might use your Cool Tech(TM) to solve the problem. But the salient point is that the problem gets solved. Your customers don't give a rats ass if you solve it with automatic hyperparameter selection for LSTMs, or if you solve it with an Excel macro. They just want. Their problem. Solved.
Outside of that...it's all about the business. That's why so many successful businesses are built with Ruby and not "benchmark winner of the week" because Ruby tends to deliver on almost all of the business cases around solving problems and growth.
If you're a larger business and planning to deploy at scale to an existing customer base, the business problems tend to change more towards performance and Right Tool for the Job.
There are still much faster options out there but it's nowhere near the beast that it used to be.
I just get tired of hearing the "but Ruby is slow" drum beats when it's so consistently successful. Scaling web servers is easy. Scaling the database is hard.
It being successful doesn't excuse its slowness, in my opinion. There are lots of bad products out there that are successful by many metrics. Speed is an important part of making something good, and RoR added significant hurdles to making very fast sites. There are other stacks that don't have that issue that are also successful, but have other downsides.
Anyway, not worth rehashing these old arguments, I just wanted to know if it had improved. Sounds like it has.
All mature technology will come with a known set of tools and processes to tackle almost any problem very quickly, as long as you're familiar enough with the stack.
One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming.
It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire chain around your new object base, or fork the library, use your fork as the dependency and make the change directly.
In the world of object oriented web development, Ruby was close to a miracle in time-reduction in WORKING with an ecosystem.
In some cases it is about the tech.
Instead the suggestion should be to apply the concepts of a minimum viable product relevant to your business problem.
Unless you are building tools, products, or services for other engineers.
> Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
I'm going to assume that if someone is going into business for themselves then they are planning on having customers. There are ways to show off that don't put your mortgage and credit rating on the line.
> Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
I'm going to assume, this too, is obvious. What I mean is that anyone who has written a fair amount of software has probably already realized this.
What is it that makes people think programmers are a bunch of navel-gazing narcissists that take great pleasure in impressing other programmers? We do, but we're also rather intelligent people.
I say: be seduced by technology. Programming is beautiful. Hard problems are a joy to solve and bring great value to the world. Do what pleases you. Life is short.
The specific business advice I have is: learn to be a leader. Take responsibility for outcomes, give ownership to your team, and learn to guide people. If your business grows and takes off you might find you won't have much time to program everything and will have to act more like a guiding hand and lead your team in the mission and trust them to take you all there.
My other advice is: avoid intuition and gut-instincts. Use data: analyze commit history, watch your issue manager, track performance indicators just as much as sales and marketing. A business is always shifting and changing. Rely on data to help you identify trends and make effective decisions. A gut decision should be a last resort.
It's far easier to fall into a hole of technical debt this way. The extra costs incurred could be too much for your venture to bear. Among all risks new ventures take, this is probably has one of the least cost:benefit ratios.
marketing encompasses the 4 P's: product, price, promotion and place. product is literally the finding of the fit between your offering and the market's needs. price is the portion of the value you deliver to the customer that you capture. promotion is finding and providing potential customers with info about why your product is the shizzle. place is how you deliver the product to your customer (e.g., physical store, direct sales, saas, app store, etc.).
build things that support your marketing activities, rather than building tech that you hope you can market.
I strongly believe that startups very rarely fail because they have chosen to build on a particular immature technology. Some fail or stall because they cannot bring themselves to stop redesigning and rebuilding on the next new technology or design philosophy every couple of months.
But these are completely different issues (related by psychology for sure but not by necessity)
My opinion is you should choose what you find coolest and most exciting now and then stick with it!
Of course the technology you choose should have some traction but don't choose technologies of the past! Whatever you choose will be the past soon enough and that is when you must find the strength to stick with it and get on with creating value for users.
It requires lots of energy to see these projects through, and it's hard to emit that energy on something that you don't enjoy doing. If using a less common technology is going to get you working on the problem enough to start getting some velocity, that may well be a worthwhile tradeoff (as long as it's not too out there).
The other thing to consider is that while a basic library supplied by a young language may suit your needs when you're starting out, larger ecosystems are likely to have more advanced libraries that have better performance characteristics, support more obscure use cases, etc., which will only become more valuable as one grows.
The downside is it could backfire on who you're able to hire. It could just lure people who will either want to migrate to the next new-and-shiny or just leave quickly.
In my company, we hire middle of the pack programmers for a bargain and use commonly known tech stacks.
The customers will not know the difference.
Having done some recruiting at a startup last year, even getting the top 50% to reply to an email is a tough proposition. The problem really stems from brand awareness. No one has heard of your startup, so in a sea of "help wanted" postings on Angelist, Stack Overflow or Craigslist or cold emails, it's extremely easy to be ignored.
Using novel technology and getting the word out (as Twitter and Jet.com did), can at least get technical awareness within a motivated subset of engineers who are interested in said new stuff -- and of all skill levels.
That said, Peter Norvig made a pretty good refutation of your core point[1]. Say your initial site was successfully launched by average engineers. If you're not always trying to hire better than the average employee at your company, your team just gets worse over time.
[1] - https://research.googleblog.com/2006/03/hiring-lake-wobegon-...
[edit] -- btw, using the new-shiny stuff is not all-or-none. You can still use tried and true tech along the way.
I just don't think research done from the perspective of the biggest tech company in the world has any relevance on 99.9% of small tech startups.
Your main focus should always be to ship good user tested product, and I agree you don't have to be the best programmer to build something that users want and like.
I'd like to add: if you find the time, try to have a side-project on your own time where you apply all these cool new things you were looking to apply in your company. This will help you keep your sanity and it will let you experiment with that technology so that you can make a better informed decision on wether to implement it in your company or not.
Yeah you can make a good business. Yeah you can make a living. But you're probably not going to make a unicorn.
Most entrepreneurs are happy building a good product that helps their customers while making a good living at it.
I mean, that will probably allow you to ship a bare bones MVP pretty quickly, but making improvements to said MVP in a timely manner may be a different story.
Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner. If I remember correctly shortly before I left they decided to replace it with something built from scratch using a leaner Ruby framework called Sinatra.
For that reason I'll typically write projects in Node or Golang, but typically Node. They're flexible, they're not a framework, they're not opinionated, but at the same time they both still have robust package ecosystems so I don't have to reinvent the wheel.
And actually, by all means use new technology if you can honestly tell yourself and your customers that it allows you to ship faster. Just remember, you writing code faster != you being able to ship faster. You'll probably have to bring on additional employees, so your choice of tech has to factor in how quickly you can hire and train someone to use your tech stack as well as how well they can reasonably perform with it. That being said, developers who like using your uncommon technology or tech stack are typically going to be a little more enthusiastic, just don't go too far.
This is the problem, not Rails. I've been using Rails for years since 2009 without any problems. I've also used PHP, Java, and Node. These projects have survived 5+ years not because of any language or framework but by treating code as a craft.
I think the real limitation is not jumping on trends but managing cognitive load. That is your real limitation, the capability of the programmer-mind to fathom all the states their code can get in. To optimize towards that, you have to pick technologies that force the least amount of cognitive load on the developer. Functional languages such as http://elixir-lang.org/ seem to accomplish this (according to those who have switched to it and blogged about it, example http://mattscodecave.com/posts/elixir-for-pythonistas-pt1.ht...). In the javascript space, Elm seems to accomplish this. http://elm-lang.org/
But lastly, if you pick the right technology, you might naturally get access to a pool of very high quality developers, the type who are already interested in that very technology.
I don't get the point of hiring "Java people" and whatnot, anyway. Polyglots are the way to go.
The thing that made Paul Graham a thing was his use of Lisp to edge out his competitors at the time. The fact that Viaweb was later rewritten in [whatever it was rewritten in] is irrelevant. That's my final point.
[0]. https://groups.google.com/d/msg/comp.os.minix/wlhw16QWltI/P6...
Technology is actually an advantage. I would look at it this way, if you used N tech, and it actually results in a faster, better app, meaning happier users and therefore more business.
TLDR; use technology that gives you an advantage.
Big if there...
E.g. if you make a website, it should be a unique and engaging website. But you can make a unique and engaging website with Java. Even though it's old tech, your users will not know or care.
When I read this, a voice in my head yelled PHP.
The myth that they tell themselves is that $REVOLUTIONARY_FEATURE_Y will greatly improve their productivity, but the fact of the matter is usually that no matter how revolutionary the features, it's hard to overcome the benefits that come from an active ecosystem of well-tested and widely used libraries. Even if productivity is improved 20x by the revolutionary feature, a library that has 10 man-years of effort in it will take you 6 months to implement. Rinse and repeat.
This is not to mention the availability of online references and established conventions/best practices, the impact of hitting esoteric errors, and so on.
A good example of this is probably reddit. Originally written in Lisp, they eventually gave up and compromised down to Python due to improved tooling and library availability. [1]
https://www.wyc.io/posts/just-build-it-in-django-or-rails/
It's just really hard to beat the reliability, community, ecosystem, and features that are table stakes when using a competent web framework.
When you're poking at a new market, you really don't have time to give a shit about writing CSRF middleware. That's one less customer interview or feature request to grow your business. I'm sure you can do it, and no one's doubting your capability to do so. But these are just things that are tricky to implement and takes everyone time and effort to do so correctly.
And secondly, some of the features you list the frameworks as having are questionable at best. Rails has built-in user accounts, permissions and admin interface? Since when? And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
I think you confused the two messages of "don't build your own web framework" (I heartily agree) with your assertion that a startup in 2017 would be somehow remiss to not be using frameworks developed in the time of Windows XP, with which I do not agree.
For me the current "Rails in 2006" framework is elixir/phoenix, and for the slightly less adventurous, something in nodejs - maybe meteor or plain express. Of course Rails still works, and is not an absolutely horrible choice, but it's for last decade's web, and has profound disadvantages compared to today's technology.
However, for new business owners who don't care so much about getting an A+ for technical excellence, I would still stand by this advice. The benefits of technology maturity and ecosystem are extremely compelling.
Today, for someone who just wants to let their users log in with Facebook, Elixir has far fewer user-friendly resources and will require more technical expertise to produce the same result. How many StackOverflow questions address common woes in these popular frameworks as opposed to the up-and-comers? How easy is it to hire someone to build + maintain? What about for hiring on the cheap? What existing libraries and integrations exist?
Of course, these things get better for new technologies over time. Until then, I can't tell people to use them if it incurs a disproportionate cost to achieve the same return.
Lastly, that "it's old" is not a compelling reason to me to recommend something else. GNU/Linux was created in the 90s, and it's still everywhere and growing. There's a job for an operating system to do, and GNU/Linux solves it well enough for the amount of effort required to use it. I believe the same to be true for Django or Rails in building a fast business prototype for most enterprise or consumer use cases. I think measures of suitability for the task are more relevant than age.
For the use case you're describing, I agree completely with your comments. Perhaps a useful razor is - if you can't state specifically why you can't use rails (and don't say "it doesn't scale"!) - then use rails. I concede that 90% of the time, this is probably the case.
And yes, harping on about its age was silly of me. Age does not inherently mean anything. I'd use postgres (1984!) over mongodb anyday. And erlang is older than ruby. Right tool for the job is far more important, thanks for pulling me up on that.
All that said - I still think that categorically stating "use boring technology" or "just use rails" for absolutely any new project is harmful. New technologies are not always just about the new shiny, they can provide capabilities and functionality simply unachievable with the old. Look at what you can do with concurrency with phoenix. Look at what you can do with react native. Roundly writing off the whole idea of using this new tech as "magpie development" is just lazy.
The whole point of ActionCable was that it is being used by Basecamp: https://medium.com/@dhh/rails-5-action-cable-demo-8bba4ccfc5...
And it's particularly irrelevant if the front-end or back-end is weighted more heavily than the other in terms of product value, when you might hire distinct rather than "full stack" devs someday.
1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them
2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"
Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.
In practice, Point 1 isn't too realistic though:
Front-end and back-end almost always use different build/debugging tooling, different unit/integration testing frameworks, and even different paradigms. Unless your developers are good at constantly switching modes, it's hard.
"no real upside" is wrong, as you point out, but I would stand by "no guaranteed upside" :-)
Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.