Ask HN: Missing needed skills for startup | Hacker News Reader

Ask HN: Missing needed skills for startup

17 pointsyalurker23 comments

This is partially a technical question and part business.

I have a business idea, which will require a non-trivial database. I have a CS degree but almost no db experience. I'm considering moving forward with the project with plans to hire an expert to redo the database later if the business gains traction.

I'm curious if anyone on HN has been in a similar situation and am curious how you handled it. Would you take several months to gain expertise before beginning rather than learn while doing with intentions to replace the code later? Are there utilities to do some of the heavy lifting for the database portion that are good enough for use in production? What would you do if you were in my place?

View on HN

I made three attempts at replying, but they all boil down to the same thing: just wing it.

If it's bad, you'll learn from your mistakes. If you study up beforehand I can guarantee that the knowledge will do you no good. You'll forget the good parts because you can't relate them to real world scenarios, and you'll remember things you'll never need. Common sense and divide & conquer will get you to the point where you need an expert.

You said it, venturing into the unknown isn't easy, especially for those that with a lot of pride; getting over your ego is tough and if this video [http://www.shadowcat.co.uk/archive/conference-video/yapc-eu-...] doesn't help you realize that many beginners share this same sentimental fear of failure than at least hear this, you will fail. . .irregardless of you expectations, failure is inevitable; however, here is the trick, if you set yourself up for a lot of little failures upfront (sorta like lesson plans or exercises from a textbook) then at least you have a foundation for knowing what works and what doesn't.

Lastly here are three rules of thumb that have helped me along the way: 1) If you want to read then you need to write. 2) If you want write then you need read. 3) Read, write, fail, and vigorously iterate until your ideas and expressions get executed in real-time

Most companies don't fail because of their database. Just build the damn thing and focus on the really big risk, which is that nobody will use it.

You can learn as you go. Schema are rarely static anyway. Get a book, learn some SQL, and network aggressively to find help in this area. Join user groups. Get some momentum behind your business, promote it aggressively, and you'll find someone to fill this gap if you need to.

You don't need to build for scale now anyway. You need to get something working in front of someone that tells you they will pay for it.

Reach out, contact customers, get coding. Nobody's initial database makes it into a successful product unchanged anyway. Thats a fantasy.

> I have a business idea, which will require a non-trivial database.

Non-trivial in what sense?

If it's non-trivial in size and you're worried about scaling, just build the simplest thing that will provide the desired functionality and start shipping.

Why? Because you'll have money to solve scaling problems before the db stops working because it has gotten too big.

Customers and money are the solution to most problems.

Thanks for the advice, you're almost certainly right.

Also, I might use the line "Customers and money are the solution to most problems" as the mantra for my venture.

At least for prototyping & early development, I'd say you want the schema flexibility & rapid development that a relational database can give you.

SQL lets you issue very complex queries incredibly easily (both for production & for measuring your own metrics). With alternative systems you'll have to do a lot more work to get the same results; I'd say SQL is invaluable for getting something working.

Once you've locked down your schema & have a good idea of the queries that run, then you're in a much better position to evaluate the various technologies. If you choose an 'alternative' DB, it'll be fairly easy to get your data out of MySQL, whereas the converse often doesn't hold.

Finally, it seems to be the fashion to underestimate how much data a relational database can handle, while taking it on faith that alternative databases can handle a lot more. Once you have real data, you can do your own comparison, rather than just buying into the hype.

I have a really really good db expert as a co-founder, but we still started out with a simple mysql when we got started. the very simple reason being that specs are never obvious and we wanted to keep things as fluid as possible. We were very iterative - mysql, federated mysql, and now we are moving to a bigtable like system.

Summarizing - Just do it with a DB implementation that is as simple as you can.

If it is a web app, use Google App Enigne. You don't have to know dbs for that (in fact it would hurt because you would have to unlearn stuff) and it is much easier to change than a traditional db schema.

It will also save you from doing lots of admin stuff that you probably have no experience with. And it will scale out of the box.

If you're talking about a database in terms of a web application or something similar, it's very simple. I remember I learned my way around MySQL in a matter of days. Check out w3schools.com and go over the quick MySQL tutorial.

>I have a business idea, which will require a non-trivial database.

Non-trivial. So that's almost certainly not a relation db. Probably something really scalable like Tokyo Cabinet or Berkeley DB.

If you have no db experience, it seems likely that actually your idea does not require that complicated of a database. Why don't you post more specifics and HNers can see if there's an easy solution.

I spent some time looking at the issue today, and you may be right. I sketched out a very naive design which would be very simple but quickly grow to millions of rows, I suspect with a little research I may be able to solve it easier than I initially assumed (I'm giving myself a pre-emptive RTFM here)

What I need is to track an exercise regimen. Some issues are basic- columns for user ID, exercise ID, but I don't see how to keep track of things like number of reps & weight without growing quickly. I want to be able to log every day how many repetitions of each lift a user does and how much weight was used. Anyone spot an easy solution I'm not seeing?

What is wrong with growing quickly? The incremental size of an additional row like you are describing is so small that you'd need thousands of users before you even noticed the disk space usage.

Learning is cheap, replacing all the code, however, is not.

Not necessarily: time cost.

And yet it is a certainty that eventually, incrementally, most of the original code will be replaced over time if the product is successful. So perfection shouldn't be where he focuses. He should work with those skills he's got to make maximum progress quickly.

Customers don't see schemas.

This is a good point, but I think taking a few days to look into it would be more rewarding than wasteful.

Definitely the case.

True, but what if the Startup is promising? what if it has a big profit? In this situation it's all about Time.

True, but learning without doing can also be a waste of time. It's kind of like reading four books on iPhone programming before you write a line of code: you can be almost sure that an hour into your iPhone programming, you're going to start thinking of things that the books didn't make you think about, or problems that they don't tell you (specifically) how to solve. Doing while learning will be doubly-effective because you'll have book learning at the same time that you're running into real-world problems.

It's like writing a full spec. before writing any code for a project. As soon as you get a layer or two into the complexity, you start coming up with different problems and different requirements (that you never thought of before you started).

you might also want to try qrimp.com don't need a lot of database experience and it's easy to build it then tear it down, then rebuild it until you get it right and since you don't have to write a lot of code, you don't lose all the time recoding stuff to match your data model.

If you don't need a terabyte of data stored, just use an in-memory data structure, and have 1 server process in whatever language you're using, and manipulate whatever you would do in memory, and work from there. Maybe SQL is the right choice, maybe not, but you'll at least have a better idea of the problem space that you're interested in.

Reply on news.ycombinator.com