When it comes to using third party software you need to balance risk, cost, and potential benefits. Just like with everything else in a software project, doing that is actually surprisingly hard.
A few guidelines:
Stick with what you know because by definition the risk is lower and cost + benefits are sort of predictable if you have prior experience. If what you know is proven third party stuff, you need a really good argument to take the risk to not use that.
Minimise risk in your projects. Anything new is a risk, especially third party stuff you haven't used before. Risk multiplies instead of adding. So doing three risky things is way more risky than doing two risky things. So switching to a new nosql DB, while adopting some cutting edge cloud platform stuff, while also trying to bring in some unproven enterprise software that promises to solve all the problems you have is going to be very risky. The chance that all three work out as expected is pretty slim. So, maybe not worth doing all three at the same time.
When choosing between building new and reusing something you haven't used before, be biased to the latter unless the benefits justify taking a calculated risk by doing the former. Both are by definition risky because of unknown factors but at least the third party stuff usually has some form of track record. .
Instead of long term benefits, focus on short term time to market in your tradeoffs. The software you ship next month will have a 12 months head start on providing you ROI compared to the stuff that you will ship a full year later. If that means not reinventing a bunch of wheels and taking a few short cuts, that may be better than taking a lot of risks for 12 months and hoping it comes out nice and shiny on schedule (hint , waterfall is impopular for good reasons). Remove excuses for shipping later rather than sooner. If third party stuff helps you ship faster, by all means go for it. But if it sets you back short term (e.g. because of training), maybe reconsider your options before committing to extended training and integration pain.
Look at added value when taking decisions. The reality is that unless it is actively adding value to your product, it is not what you should be spending your time on. Added value is anything your customer would pay for that they can only get from you. Third party commodity stuff is supposed to give you more budget to spend on the stuff that actually creates value. Almost by definition any third party stuff is in the category of commodity stuff that any competitor also has access too. If most of the value of your product is actually you reselling third party stuff, what are you selling really? Also consider that any non value adding stuff you execute poorly, actively removes value from your product. That argues against reinventing wheels poorly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When it comes to using third party software you need to balance risk, cost, and potential benefits. Just like with everything else in a software project, doing that is actually surprisingly hard.
A few guidelines:
Stick with what you know because by definition the risk is lower and cost + benefits are sort of predictable if you have prior experience. If what you know is proven third party stuff, you need a really good argument to take the risk to not use that.
Minimise risk in your projects. Anything new is a risk, especially third party stuff you haven't used before. Risk multiplies instead of adding. So doing three risky things is way more risky than doing two risky things. So switching to a new nosql DB, while adopting some cutting edge cloud platform stuff, while also trying to bring in some unproven enterprise software that promises to solve all the problems you have is going to be very risky. The chance that all three work out as expected is pretty slim. So, maybe not worth doing all three at the same time.
When choosing between building new and reusing something you haven't used before, be biased to the latter unless the benefits justify taking a calculated risk by doing the former. Both are by definition risky because of unknown factors but at least the third party stuff usually has some form of track record. .
Instead of long term benefits, focus on short term time to market in your tradeoffs. The software you ship next month will have a 12 months head start on providing you ROI compared to the stuff that you will ship a full year later. If that means not reinventing a bunch of wheels and taking a few short cuts, that may be better than taking a lot of risks for 12 months and hoping it comes out nice and shiny on schedule (hint , waterfall is impopular for good reasons). Remove excuses for shipping later rather than sooner. If third party stuff helps you ship faster, by all means go for it. But if it sets you back short term (e.g. because of training), maybe reconsider your options before committing to extended training and integration pain.
Look at added value when taking decisions. The reality is that unless it is actively adding value to your product, it is not what you should be spending your time on. Added value is anything your customer would pay for that they can only get from you. Third party commodity stuff is supposed to give you more budget to spend on the stuff that actually creates value. Almost by definition any third party stuff is in the category of commodity stuff that any competitor also has access too. If most of the value of your product is actually you reselling third party stuff, what are you selling really? Also consider that any non value adding stuff you execute poorly, actively removes value from your product. That argues against reinventing wheels poorly.