4 ms·

I worked at 2 start-ups so here are the technology stacks: The first company was started 3 years ago and our technology included: (1) Python-Flask (2) Postgres

by dqdo 12y ago

I worked at 2 start-ups so here are the technology stacks: The first company was started 3 years ago and our technology included: (1) Python-Flask (2) Postgresql (3) SQL Alchemy (4) JQuery for web (5) Objective C for IOS (6) Bootstrap In my second company we wanted to take advantage of the growing ecosystem around Node. We also did not want to have to manage a DB, migrations, and server scripts. Our rationale is that we should focus more on the customer and turning the customer requirements into the product than on the technology working. We are an enterprise software company and so the less complicated the technology the better since we are not doing anything ground breaking from a technology standpoint. Our stack includes: (1) NodeJS/Express (2) Heroku (3) Angular JS (I don't get all the negative comments about Angular lately because it works fine for us) (4) Lodash (Javascript utilities) (5) S3 - static file storage (images and files) (6) Jquery (7) Bootstrap (8) Firebase (9) Angular Fire (to connect firebase with angular) Using our current backend, we were able to build the SAAS product in about 1 month with only myself as a developer instead of 2-4 months that might be required if we had used the previous technology stack. Firebase, Angular, and the Node ecosystem really helped make the coding much faster than before.

dqdo 12y ago
In my opinion, web technology has become so advanced that the technology for the most part should not matter as much. Unless you are doing something on the scale of Facebook or Google, your technology usually does not matter. Just choose the stack that you are most productive with. And some are more productive than others. When choosing a technology stack I look to Southwest Airlines for inspiration. I might sound strange but more people should embrace the Southwest model. As an airline, they only have 1 type of plane and tries to keep things as simple as possible. So instead of building some of your products in Ruby, other parts in Python, and another part in Erlang; it is better to just stick with one or two core technology. The rationale behind this is to reduce context switching, reduce errors and bugs that occurs at the crack of technology systems, make it easy to train and onboard other people to your project, and make it easier for yourself to maintain it over the long run. My rule of thumb is that software is maintained and read more often than it is written so now I tend to take much longer to write software because I have to think about how people would read it. For every 2 days of coding, I spend about 1 day of refractoring and I do this religiously to keep the technical debt low.
- lambdathoughts 12y ago
  Thank you - that makes a lot of sense.
- robodale 12y ago
  This.
- aceperry 12y ago
  Sounds like great advice to me. I'm looking at different stacks and approaches now and coming to the same conclusion about using a single technology to reduce the context switching and simplify everything. The idea of taking time to write software for maintenance sounds great to me.
- sanmon3186 12y ago
  Southwest is a great example but lifespan of airliner models and software vary a lot. How about 80/20? Stick with one/two technologies for 80 percent and have 20 percent room to try out new things.
  - dqdo 12y ago
    I tend to decide which tools to use base on how likely I would need to maintain and refractor the code. For the core application code, I want to keep things as nice and simple as possible. For particular functionalities where once you build it, you really don't have to change things I tend to use the right tool for the job. I also try to isolate the code in a way where if I am using a unique tool or unique coding pattern, I would cluster those type of code together. This allows me to isolate the unique areas in the codebase quickly and make modifications when required. Using this strategy you can use the esoteric solution in the right case and still be shielded by the technical debt that it might bring to the project.
- akbar501 12y ago
  I have recently been going the other direction from the "Southwest model". It's on a case by case basis, but if it takes less time to learn and use a technology that is purpose built then I'll invest the time to learn / use something new. I find for some situations it's less time and effort to use the right tool for the job vs. trying to make one tool do everything.
bikamonki 12y ago
I see a trend here, I'm also solving most cases with no-backend solutions. In your opinion, what would be the downside of Firebase? Did you have to work-around any limitation? Also, did you try Backbonejs as well? Can you compare it to Angularjs? I am thinking about giving Angularjs a go but would like an opinion from someone who's already using it in prod.
- dqdo 12y ago
  There are two downsides to Firebase. The first one being price. For certain applications (e.g., photo sharing app) it does not make sense to use Firebase due to the high cost of storage. I would just use AWS in this case. The second downside is that it takes longer to run SQL-like search queries on the data. Depending upon your application, this might be important and Firebase does not do this well. What Firebase is good at is make the development process very quick and for real-time applications the set-up is much simpler than web-sockets. I have tried both Backbone JS and Angular JS and in my opinion, I like Angular's separation between the front-end html and the model. Reading through Angular is much faster than reading through Backbone code because Angular is very opinionated. I like opinionated frameworks and languages (e.g., Python) because if there is only one right way to do something, it simplifies the code greatly. Some people don't like Angular due this structured approach and opt for Backbone. As for performance, there really hasn't been any problems with Angular and Firebase. I am not sure where the complaints about performance comes from. And just one last comment. I augment AngularJS with Jquery and Lodash. For some functionalities, I like to work directly in Jquery or Javascript rather than use the Angular method. I find this much simpler than stick 100% with Angular and in order to keep this logic clean, I keep the Angular and Jquery code separate.

by dqdo 12y ago

dqdo 12y ago

In my opinion, web technology has become so advanced that the technology for the most part should not matter as much. Unless you are doing something on the scale of Facebook or Google, your technology usually does not matter. Just choose the stack that you are most productive with. And some are more productive than others. When choosing a technology stack I look to Southwest Airlines for inspiration. I might sound strange but more people should embrace the Southwest model. As an airline, they only have 1 type of plane and tries to keep things as simple as possible. So instead of building some of your products in Ruby, other parts in Python, and another part in Erlang; it is better to just stick with one or two core technology. The rationale behind this is to reduce context switching, reduce errors and bugs that occurs at the crack of technology systems, make it easy to train and onboard other people to your project, and make it easier for yourself to maintain it over the long run. My rule of thumb is that software is maintained and read more often than it is written so now I tend to take much longer to write software because I have to think about how people would read it. For every 2 days of coding, I spend about 1 day of refractoring and I do this religiously to keep the technical debt low.

lambdathoughts 12y ago
Thank you - that makes a lot of sense.
robodale 12y ago
This.
aceperry 12y ago
Sounds like great advice to me. I'm looking at different stacks and approaches now and coming to the same conclusion about using a single technology to reduce the context switching and simplify everything. The idea of taking time to write software for maintenance sounds great to me.
sanmon3186 12y ago
Southwest is a great example but lifespan of airliner models and software vary a lot. How about 80/20? Stick with one/two technologies for 80 percent and have 20 percent room to try out new things.
- dqdo 12y ago
  I tend to decide which tools to use base on how likely I would need to maintain and refractor the code. For the core application code, I want to keep things as nice and simple as possible. For particular functionalities where once you build it, you really don't have to change things I tend to use the right tool for the job. I also try to isolate the code in a way where if I am using a unique tool or unique coding pattern, I would cluster those type of code together. This allows me to isolate the unique areas in the codebase quickly and make modifications when required. Using this strategy you can use the esoteric solution in the right case and still be shielded by the technical debt that it might bring to the project.
akbar501 12y ago
I have recently been going the other direction from the "Southwest model". It's on a case by case basis, but if it takes less time to learn and use a technology that is purpose built then I'll invest the time to learn / use something new. I find for some situations it's less time and effort to use the right tool for the job vs. trying to make one tool do everything.

bikamonki 12y ago

I see a trend here, I'm also solving most cases with no-backend solutions. In your opinion, what would be the downside of Firebase? Did you have to work-around any limitation? Also, did you try Backbonejs as well? Can you compare it to Angularjs? I am thinking about giving Angularjs a go but would like an opinion from someone who's already using it in prod.

dqdo 12y ago
There are two downsides to Firebase. The first one being price. For certain applications (e.g., photo sharing app) it does not make sense to use Firebase due to the high cost of storage. I would just use AWS in this case. The second downside is that it takes longer to run SQL-like search queries on the data. Depending upon your application, this might be important and Firebase does not do this well. What Firebase is good at is make the development process very quick and for real-time applications the set-up is much simpler than web-sockets. I have tried both Backbone JS and Angular JS and in my opinion, I like Angular's separation between the front-end html and the model. Reading through Angular is much faster than reading through Backbone code because Angular is very opinionated. I like opinionated frameworks and languages (e.g., Python) because if there is only one right way to do something, it simplifies the code greatly. Some people don't like Angular due this structured approach and opt for Backbone. As for performance, there really hasn't been any problems with Angular and Firebase. I am not sure where the complaints about performance comes from. And just one last comment. I augment AngularJS with Jquery and Lodash. For some functionalities, I like to work directly in Jquery or Javascript rather than use the Angular method. I find this much simpler than stick 100% with Angular and in order to keep this logic clean, I keep the Angular and Jquery code separate.