
Don't solve the solved problems - tonyx
http://blog.collections.me/post/46373756896/dont-solve-the-solved-problems
======
InclinedPlane
Sigh.

"Don't reinvent the wheel." Classic advice. And it has some merit. But it's a
broken idea.

Google? Not the first search company. The iPod? Not the first mp3 player. The
iPhone? Not the first smartphone. Hacker news? Not the first tech oriented
community site.

"Don't reinvent the wheel...

unless you think you can do much better."

Also, if you're merely iteratively improving the wheel, do so whenever you
like. We don't drive around on hand-carved roughly circular hunks of wood any
longer, and that's good.

~~~
alexjeffrey
I read this post as less "don't reinvent the wheel", more "if you're building
a car, don't build your own wheel when you could buy one from a wheel
manufacturer" - maybe if you did it yourself you could make improvements, but
it's far more likely that a company where the problem you're trying to solve
is their bread and butter will provide a better solution.

~~~
InclinedPlane
I think the core problem is that the question "build or buy?" is formulated in
a way such that it rests along the incorrect axis. It's like giving people
advice on whether they should go outside or not, whether they should fall in
love or not, whether they should start a company or not, etc.

The proper answer is: "it depends." But that's unsatisfying because it's too
complex. But in reality you can't eliminate that complexity, it's an
irreducible complexity. Just as there isn't one simple, objective system which
you can consult to reliably get an answer to the question "should you go
outside or stay indoors?" there isn't one for whether you should use something
off the shelf or build something yourself. Look at, for example, SpaceX, who
built the first generation of engines for their Falcon 9 rockets using
turbopumps (one of the most complex components of a high performance rocket)
provided by 3rd party companies. However, in the subsequent generation of
engines (the Merlin-1D) SpaceX has designed and built the turbopumps
themselves, and this is responsible for significant improvements in the
engine.

Ultimately I think it's more important to take a step back and make a
conscious effort to avoid making big decisions based on instinct or inertia
and begin to cultivate a set of processes, elements of corporate culture, and
habits which encourage thoughtful analysis and introspection about these
choices. People should be more thorough about evaluating the advantages and
disadvantages of doing things different ways and be mindful of when it doesn't
seem to make much difference. And also mindful of the opportunity to change
your mind in the future. Sometimes it can be worthwhile to rebuild a tool that
already exists in the industry just for the purposes of acquiring the
experience and knowledge of having done so. And sometimes even when taking
something in house might easily save millions of dollars a year it still might
not be worth it due to other opportunity costs.

It's a complicated question, and it's always going to be a complicated
question. Instead of pretending it's an easy question people should be working
on acquiring the skills to make sure they can answer the question well with
some degree of reliability.

~~~
alexjeffrey
I think your example also speaks to the argument I put forward to some extent
- SpaceX initially chose to use a 3rd party turbopump as building an efficient
turbopump isn't their objective. However, at a later stage when the 3rd party
turbopumps became an issue (whether that be because they were faulty, not
efficient enough or any number of reasons) SpaceX decided to build their own.

This seems like the correct way round to me for the majority of cases where
subcomponents of your product could be externalised - a 3rd party should be
the primary go-to choice unless a company cannot be found that fits the
requirements. The issue I see in development (and have been guilty of in the
past) is simply building everything when libraries could easily cover the use
case - "not invented here" syndrome. That's the real problem.

[edit] Also I think it's clear that there'll always be cases where the default
doesn't apply, for example when working with a new field/concept or where the
3rd party options are too far from the mark, but for the majority of
development (especially web development) there's likely a library/service to
match many of your requirements.

~~~
chacham15
What you are missing is that every library has its own dependencies and set of
libraries. Gitlab uses nginx, unicorn, mysql, and a few other technologies.
Ganglia uses apache, python, perl, and a few others. If you continue to add
components you end up with seven different web servers, application servers,
and little spare system resources and we havent even started talking about how
to get these components to play nicely together! In conclusion, yes, it is
nice if you can simply outsource to a library, but many times you have to bend
over backwards to do so and it simply isnt worth it.

~~~
InclinedPlane
It depends a lot on scale. If you're just throwing together a web app that
isn't going to have crazy amounts of traffic or business then maybe a big
messy dependency chain is ok. But every one of those dependencies is a risk
and a liability, and the more valuable and significant your project becomes
the more important it is to lock down risk and reduce liabilities. Which means
tracking down and eliminating dependencies.

------
azov
That's a hell lot of things to change, break, go down, lose your data, start
charging ridiculous prices, be discontinued, etc... I'm all for SaaS and not
re-inventing wheels, but I'd be nervous if I had to rely on so many external
dependencies.

~~~
pbiggar
Presumably when any of those things happen, that's when you bring it in-house.

~~~
Hansi
I don't think that's a viable solution. Some of these are quite complicated
and replicating them in-house is not something you just up and do in a short
time. That tactic might expose you to significant downtime.

~~~
pbiggar
I agree they take a long time to replicate. Which is why it doesn't make any
sense to me to suggest that you should build them in house before you get your
product out to the world.

~~~
jiggy2011
It depends, sometimes you really do need the big complicated thing and you
don't have time/money to develop it in house.

Sometimes though you can make do with something significantly simpler if you
restate the problem slightly and move the pieces around.

You might be able to do the core of the job with a cron job and some command
line tools rather than the fancy SaaS platform with graphs and everything.

Building on top of the fancy SaaS APIs and then trying to scale down when you
want to move away is a lot more difficult than starting with the simpler
approach and then scaling up when you really need that extra functionality.

Believe me, I've done it in both directions.

------
devindotcom
I was hoping for a slightly higher-level look at what problems not to solve.
It seems that Collections.me solves a solved problem - convenient online
storage. It iterates a bit on it, but you seem to be building something that
is largely a pile of already-solved problems, both in its implementation and
use cases. Just my opinion, of course, and that is how many services advance,
but I thought I'd voice it in light of the purpose of your post.

~~~
Too
Try [http://www.codinghorror.com/blog/2008/10/programming-is-
hard...](http://www.codinghorror.com/blog/2008/10/programming-is-hard-lets-go-
shopping.html)

The OP doesn't really talk about "solved problems", it talks about the
companies core competencies.

------
redemade
most of these services wouldn't be around if they had taken that advice ;)

~~~
jayfuerstenberg
I just so happen to be working on a product that significantly overlaps with
Collections.

I've spent almost a year on it and don't think I'm going to take their advice
if it's all the same to them.

------
pbiggar
OP: thanks for mentioning us (<https://circleci.com>)!

That's a lot more 3rd party services than most use - do you find major
differences in reliability?

------
benjah
I second most of the listed services. Just because you can code or host your
own systems, it doesn't mean you should. Any time spent on extraneous internal
devices is a disservice to your core and customers. Lastly, shameless plug but
I think we have a better accounting solution in <http://cheqbook.com>

------
niggler
"MongoDB is how we store things"

Is mongodb really a good solution for storing things? IIRC one concern about
coinbase (YC) is that they used mongodb for storing financial information.

~~~
tonyx
We like to embrace different technologies and use each for its strength.
MongoDB is excellent for a whole class of use cases and we like it a lot, but
we also use other persistence solutions as well. Check out Polyglot
persistence post by Martin Fowler, it's an awesome read.
<http://martinfowler.com/bliki/PolyglotPersistence.html>

------
kevinastone
How do you get any of the benefits of redis over a Wan link? So confused by a
hosted redis solution...

~~~
lennydizzy
I have the same question...

~~~
pbiggar
Latency to another server in the same AWS availability zone is 1ms.

~~~
kevinastone
So it's really just a deployment solution for EC2?

~~~
pbiggar
I think other providers have similar speeds, and that the redis and mongo
providers provision on lots of provider's machines. But I'm not sure how far
that goes.

------
huhtenberg

      The Bolt-On Engineering for Dummies.
    

Granted, some people find it interesting.

------
jaddison
If I can ask, what's the general monthly run rate of those services you use
combined?

------
Qantourisc
How about the unimpleted problems ? Or does that fall under unsolved ?

------
banachtarski
This speaks better to how well heroku is able to sell add-ons.

