This Is such a great article! Seriously, awesome!! Five stars!!
I have a question: do you think that, nowadays, using always tools(frameworks, for example) which have few years of life, Is a plus to developing low quality software?
Talking to a friend, an engineer from another industry(chemical), told me something that i consider really interesting:
"You, the developers, do something weird, from the engineer perspective: always using tools that just came out few years ago. In my area, we dont change anything(machinery, pieces, nothing) for something that haven't been tested for several years. Maybe because error in my area are more expensive than yours, maybe mistakes in software development are cheaper to solve and with minor consequences"
Do you think that industry should wait a little bit more before using all of these new frameworks?
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
The people in our industry are prone to adopting the new, trendy thing for all the wrong reasons. And I'm not taking just about frameworks. It also includes languages, methodologies, libraries, tools, management fads, and more. If it's new and it's got buzz we're trying it in production systems regardless of what our stakeholders think. Read You Should Build your Next App on a Boring Stack for more details.
If the stakeholders in most projects considering a new technology were consulted in a meaningful way most of them wouldn't want the risk of new and shiny. Most projects need risk reduction and schedule predictability more than they need innovation in their stack.
As a manager, I've shot down many proposals like this. The devs don't like it but I tell them that we are here to make money and meet management objectives and that they should experiment with any technology they want on their personal time.
I'm not saying that we never do anything new but my default answer of "no" to the shiny and new thing keeps us from changing without a good reason.
I think you've brought up another important dimension here. The engineers building a chemical processing plant have an expected lifetime in mind that's likely several decades. They are being paid to make sure the plant is maintainable for it's entire anticipated operating life. I've rarely met a software developer that even considers that.
On one project I worked on we had an explicit expected lifetime of 15-20 years. So every time we looked at adding a new library or tool we considered the probability that it would still be around in 20 years and what we would have to do if it wasn't. That consideration radically changed our decision making process--we became much more conservative.
I think engineering and Software development are very different areas, so it's hard to draw comparisons. Development cycles tend to be longer in the area of engineering (even though there are exceptions from this rule to be found, like rapid prototyping in engineering and maybe SAP for software). I think this has also to do with the scale and complexity of the projects and companies involved. Let's take a new car from a big manufacturer and a new app from a small Startup for example. The bigger the complexity of a project, the bigger the transaction costs of innovation. While every part of the car needs to work reliably in order to avoid huge costs down the line, a small software company often needs to be fast, the costs of an error are smaller, so there is more room and also a bigger need for innovation.
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 Is such a great article! Seriously, awesome!! Five stars!!
I have a question: do you think that, nowadays, using always tools(frameworks, for example) which have few years of life, Is a plus to developing low quality software?
Talking to a friend, an engineer from another industry(chemical), told me something that i consider really interesting:
"You, the developers, do something weird, from the engineer perspective: always using tools that just came out few years ago. In my area, we dont change anything(machinery, pieces, nothing) for something that haven't been tested for several years. Maybe because error in my area are more expensive than yours, maybe mistakes in software development are cheaper to solve and with minor consequences"
Do you think that industry should wait a little bit more before using all of these new frameworks?
The people in our industry are prone to adopting the new, trendy thing for all the wrong reasons. And I'm not taking just about frameworks. It also includes languages, methodologies, libraries, tools, management fads, and more. If it's new and it's got buzz we're trying it in production systems regardless of what our stakeholders think. Read You Should Build your Next App on a Boring Stack for more details.
If the stakeholders in most projects considering a new technology were consulted in a meaningful way most of them wouldn't want the risk of new and shiny. Most projects need risk reduction and schedule predictability more than they need innovation in their stack.
As a manager, I've shot down many proposals like this. The devs don't like it but I tell them that we are here to make money and meet management objectives and that they should experiment with any technology they want on their personal time.
I'm not saying that we never do anything new but my default answer of "no" to the shiny and new thing keeps us from changing without a good reason.
I think you've brought up another important dimension here. The engineers building a chemical processing plant have an expected lifetime in mind that's likely several decades. They are being paid to make sure the plant is maintainable for it's entire anticipated operating life. I've rarely met a software developer that even considers that.
On one project I worked on we had an explicit expected lifetime of 15-20 years. So every time we looked at adding a new library or tool we considered the probability that it would still be around in 20 years and what we would have to do if it wasn't. That consideration radically changed our decision making process--we became much more conservative.
I think engineering and Software development are very different areas, so it's hard to draw comparisons. Development cycles tend to be longer in the area of engineering (even though there are exceptions from this rule to be found, like rapid prototyping in engineering and maybe SAP for software). I think this has also to do with the scale and complexity of the projects and companies involved. Let's take a new car from a big manufacturer and a new app from a small Startup for example. The bigger the complexity of a project, the bigger the transaction costs of innovation. While every part of the car needs to work reliably in order to avoid huge costs down the line, a small software company often needs to be fast, the costs of an error are smaller, so there is more room and also a bigger need for innovation.