What do you say to those who say "Boring is Good"? i.e. choose the less exciting, older database over the new one except when it's intensely unsuited for the task at hand.
In terms of innovation, it's the product or real pain points/provable big wins in the development process that should drive this.
Example: I wrote the backend for a user chat feature quite quickly with postgres. With default config it's not the optimal database for the job. Chat has append only semantics and low locking requirements so the right kind of database can get many multiples better latency. But crucially, taking this step would have no appreciable effect for the user with the low traffic we had. The risk and learning time cost of introducing unfamiliar new tech would have been considerable and required much more complex code to get to the fully optimised async version.
In practice, that part of the backend has worked away faithfully for nearly 2 years, not exposing bugs and with lower latency than any other user interaction.
I see part of my job as resisting the urge to learn new fun stuff on someone else's dime without great justification.
All things software & product, honestly - FrontEnd, BackEnd, DevOps, ML - as long as we're solving massive problems.
My code is used by millions of users globally - Potatoes make me happy
I say, choose a tool that is correct for the job, if its old, but it is the tool needed to do the job due to backwards compatibility issues.
I was watching a youtube video from the cofounder of wufoo yesterday who gave an example of another incredible company where they would keep tech support phones in the middle of the dev floor, because if the devs are directly involved in supporting solutions for customers they will best find a great solution to fix the issue.
Perhaps I should mention/overcommunicate that this mindset should be when your firm is in growth mode and is specifically looking to improve their current practice because it needs to improve. I personally would never wander into new waters when building a new product, I wander into new waters when my current approach isn't enough for the outcome i want to deliver to my customers.
So in short, you are absolutely right to do what you have done in your example sir! In the end elegancy doesn't mean "new" shit, it means building things that work better than before, BECAUSE it's necessary.
"People respect new solutions that are better ways to solve problems, not because they're just better for the sake of being better." 💪
What do you say to those who say "Boring is Good"? i.e. choose the less exciting, older database over the new one except when it's intensely unsuited for the task at hand.
In terms of innovation, it's the product or real pain points/provable big wins in the development process that should drive this.
Example: I wrote the backend for a user chat feature quite quickly with postgres. With default config it's not the optimal database for the job. Chat has append only semantics and low locking requirements so the right kind of database can get many multiples better latency. But crucially, taking this step would have no appreciable effect for the user with the low traffic we had. The risk and learning time cost of introducing unfamiliar new tech would have been considerable and required much more complex code to get to the fully optimised async version.
In practice, that part of the backend has worked away faithfully for nearly 2 years, not exposing bugs and with lower latency than any other user interaction.
I see part of my job as resisting the urge to learn new fun stuff on someone else's dime without great justification.
I say, choose a tool that is correct for the job, if its old, but it is the tool needed to do the job due to backwards compatibility issues.
I was watching a youtube video from the cofounder of wufoo yesterday who gave an example of another incredible company where they would keep tech support phones in the middle of the dev floor, because if the devs are directly involved in supporting solutions for customers they will best find a great solution to fix the issue.
Perhaps I should mention/overcommunicate that this mindset should be when your firm is in growth mode and is specifically looking to improve their current practice because it needs to improve. I personally would never wander into new waters when building a new product, I wander into new waters when my current approach isn't enough for the outcome i want to deliver to my customers.
So in short, you are absolutely right to do what you have done in your example sir! In the end elegancy doesn't mean "new" shit, it means building things that work better than before, BECAUSE it's necessary.
"People respect new solutions that are better ways to solve problems, not because they're just better for the sake of being better." 💪
Absolutely agree, very well said.