Hacker News Reader

If you had been able to choose Python/Backbone etc. in the big company, chances are that it would have taken even longer. In big companies, everything is different, and they have to take other things in regard than mere development time. They are most likely prepared for one or two kinds of tech stacks, and everything is in place for that. If suddenly they have to deploy new technology, they for example have to:

* build custom monitoring for the components in the new stack

* look at support contracts and patching procedures for these components

* figure out how to be able to respond to security incidents with these new components

* train and _keep_ training people specifically for this new special snowflake you just created for the years to come

* look into how various operational concerns are implemented with this technology: scaling, separation of concerns (can I deploy the admin part separately?), logging and log rotation, and so forth

In startups, developer cost and time to market may be the most important things. In bigger companies, a lot of other things start to matter.

The arguments of most of these types of posts can be hand-waved with "use the right tool for the job."

But honestly, plumbing and electrical infrastructure is a terrible metaphor for a development framework. There is no situation in which a handyman would be praised for advocating complex systems. They complicate every single layer of the build.

A sizable chunk of the "hype" tech facilitates faster, more efficient development at fairly low cost (maybe sacrificing some scalability or stability).

It would be reticent of me not to mention how much the deluge of JavaScript frameworks pisses me off. It is overwhelming trying to keep up.

You can always ignore them - trying to keep up with every new javascript framework (where 80% wont be around in 2 years) is gonna piss anyone off : )

I can fully understand why big company does not want to tie itself to app engine or other Google services, especially if they are able to keep their own infrastructure. If they are European company, having customers data on app engine might not even be legal. Google was not able to guarantee that they will not move data over border and there was regulation about it. Not sure about current status.

Big company has to maintain many projects. Managing too many technologies and contracts with too many suppliers is huge hassle.

Outsourced maintenance was probably simply incapable, there is huge amount of parasitic service companies living off typical big companies decision making faults. It probably had nothing to do with technology. Long term before deployment is also probably product of big company processes, other projects competing for administrators time etc.

That being said Python + app engine + backbone is much easier technology to start with and learn then java spring mvc + sencha. When you do small project in isolation, then former seems like much better choice. Those big frameworks usually pay only if you do something big.

I don't think bsaul was saying he/she was going to use Google App Engine, just that the big company would not consider anything else other than their java/spring stack.

Here is the quote from bsaul: For the big company i had to go with java spring mvc + sencha, they didn't want to hear of any new tech that would be different from what they were used to.

Managing too many technologies with too many suppliers is huge hassle even if you remove contracts from question. One man 7 months project is not worth adding new technology to the stack.

They use their own infrastructure, so anything that can not run on it is probably a no go. If you do not use java, then they have to add python of whatever application server into mix and then maintain it forever. On the other hand, another small java is just that, they probably deploy it by one script.

Various contractors have various favorite technologies and various small projects would be done two months faster with various tools. It can add up pretty fast. The last thing they want is to run three different java application servers, two pythons and three ruby.

It should be easier to switch sencha for something else, of maybe even spring mvc for other spring compatible java mvc. However, it still is way easier to maintain many projects in spring mvc then five in spring mvc, six in wicket, three ja JSF etc.

Maintenance often costs much more time and money then initial release, even if all involved people are super capable. Having one technology for many projects reduces time needed to learn all possible quirks of all possible technologies they maintain.

Plus, one man 7 months is super small super cheap in the world of big companies. Even if whoever is leading it would want it and had enough power to allow it, it probably would not find it worth involved negotiations.

Development in big companies is always slower, even using identical technologies. Once you get to a certain size even the most basic tasks become bureaucratic.

I am currently taking some risks with new technologies building my product, so I'm definitely in favour for it (there will be no progress if everyone stays away from the unknown). But I think the author wanted to compare 2 startups using new vs. proven.

Yet, this is your experience, and I, for one, was glad to read a success story with a new tech. :)

It seems that second scenario is much better since it means more work for us, developers?

So, let's drastically reduce our productivity so that they'll hire more of us?

Sounds great! Except now you are a drop in an ocean of developers, which are all working on crappy tech with low productivity, each providing very little value to the business.

Enjoy your new, much reduced, salary.