"This way of thinking is not about what is easiest for you as a developer" - ok, but this is what makes it a losing way.
All other things being equal with respect to the outcome given business requirements, things should go with what's easiest for a developer.
Easiest for a developer (as long as architecture is respected) translates into quicker time to market and lower development costs. Long term costs should be addressed by architecture and other business constraints (such as hiring market, other costs, etc).
Unless there's a significant impact to the end result for that business requirement, I see no reason to go against a developers toolset.
But you should always consider the cost from the end-user point-of-view. Think about accessibility or browser support for example. It's not fun or easy for you as a developer, but it makes it possible for your (possibly paying) users to use your service!
I disagree. You don't. That's a business decision that depends on how the product was defined to target and support. What you (eg: developer / architect) should do is present the options and constraints to business to make a decision.
Doing in this way means a certain time-to-market and development costs but it may leave out or otherwise impact users.
Doing it the other way may come with extra costs in terms of development but may results in other advantages.
Middle way: we could start one way but there may be extra overhead to design it in a way that allows a reasonable time to change later on.
Then the business decides. It's perfectly reasonable to knowingly limit browser support for example if it's cost effective to market earlier. It's not a development decision.
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.
"This way of thinking is not about what is easiest for you as a developer" - ok, but this is what makes it a losing way.
All other things being equal with respect to the outcome given business requirements, things should go with what's easiest for a developer.
Easiest for a developer (as long as architecture is respected) translates into quicker time to market and lower development costs. Long term costs should be addressed by architecture and other business constraints (such as hiring market, other costs, etc).
Unless there's a significant impact to the end result for that business requirement, I see no reason to go against a developers toolset.
But you should always consider the cost from the end-user point-of-view. Think about accessibility or browser support for example. It's not fun or easy for you as a developer, but it makes it possible for your (possibly paying) users to use your service!
I disagree. You don't. That's a business decision that depends on how the product was defined to target and support. What you (eg: developer / architect) should do is present the options and constraints to business to make a decision.
Doing in this way means a certain time-to-market and development costs but it may leave out or otherwise impact users.
Doing it the other way may come with extra costs in terms of development but may results in other advantages.
Middle way: we could start one way but there may be extra overhead to design it in a way that allows a reasonable time to change later on.
Then the business decides. It's perfectly reasonable to knowingly limit browser support for example if it's cost effective to market earlier. It's not a development decision.