3 ms·

Another lesson that may apply: fad driven development isn't necessarily a good idea. Sometimes "old" (i.e. established, tested, widely used) technologies are be

Another lesson that may apply: fad driven development isn't necessarily a good idea. Sometimes "old" (i.e. established, tested, widely used) technologies are better choices than whatever the latest fad offers.

ams6110 12y ago
Especially for a pre-investment MVP. Use what you know and are best at. You can later port to Node/Angular or whatever everyone is orgasming about this week.
mackwic 12y ago
I think you mean "easy to hire"-technology. One time it was Java, then it was PHP, now it's becoming node.js and angular. Maybe it's a bit soon, but it's far from insane to bet on these technologies nowadays.
- Iftheshoefits 12y ago
  Yes, that is one very big reason to go "oldschool:" there are more developers who have more experience. It is nuts to follow fad driven development on a tight budget and hard time deadlines without significant understanding of the technologies involved. I'd argue that it is nuts in general to go with fad driven development. Choosing a technology structure based on fads is a dumb idea. One should choose a structure that makes sense for the project and team.
- mercer 12y ago
  True, but it might not actually be a bad idea to hire based on an 'easy to hire' technology and actually use a technology that the developers are more experienced in. For example, I've worked in a number of environments that hired for node.js, but where the devs were actually recent RoR converts who were moderately proficient in node.js and its ecosystem. In the case of getting an MVP out quick, it might still be better to use RoR.
jules 12y ago
And another lesson: the founder(s) of a startup you should probably know at least a little bit about development.
wpietri 12y ago
Yes. There is a very high probability that everything that gets written in the early days will be thrown out. If the company fails, then there's no benefit in being in the hip language of the moment. And if the company succeeds, both scaling needs and the vast amount you'll learn about what your audience really wants mean that little of the original code base will likely remain. If today I were putting together an MVP with an eye toward getting funding, I'd only use things that somebody on the team knew very well. Learning new stuff is great, but it means you will be unpleasantly surprised a lot more often. Those WTF delays really add up, and they often come at the worst time.

ams6110 12y ago

Especially for a pre-investment MVP. Use what you know and are best at. You can later port to Node/Angular or whatever everyone is orgasming about this week.

mackwic 12y ago

I think you mean "easy to hire"-technology. One time it was Java, then it was PHP, now it's becoming node.js and angular. Maybe it's a bit soon, but it's far from insane to bet on these technologies nowadays.

Iftheshoefits 12y ago
Yes, that is one very big reason to go "oldschool:" there are more developers who have more experience. It is nuts to follow fad driven development on a tight budget and hard time deadlines without significant understanding of the technologies involved. I'd argue that it is nuts in general to go with fad driven development. Choosing a technology structure based on fads is a dumb idea. One should choose a structure that makes sense for the project and team.
mercer 12y ago
True, but it might not actually be a bad idea to hire based on an 'easy to hire' technology and actually use a technology that the developers are more experienced in. For example, I've worked in a number of environments that hired for node.js, but where the devs were actually recent RoR converts who were moderately proficient in node.js and its ecosystem. In the case of getting an MVP out quick, it might still be better to use RoR.

jules 12y ago

And another lesson: the founder(s) of a startup you should probably know at least a little bit about development.

wpietri 12y ago

Yes. There is a very high probability that everything that gets written in the early days will be thrown out. If the company fails, then there's no benefit in being in the hip language of the moment. And if the company succeeds, both scaling needs and the vast amount you'll learn about what your audience really wants mean that little of the original code base will likely remain. If today I were putting together an MVP with an eye toward getting funding, I'd only use things that somebody on the team knew very well. Learning new stuff is great, but it means you will be unpleasantly surprised a lot more often. Those WTF delays really add up, and they often come at the worst time.