>"Maybe I'm one of the typical young people. I don't know. But when I come to a Company and see thing that can be improved why not improve them?"
There's absolutely nothing wrong with wanting to improve things, but there's plenty that can go wrong and hurt everyone involved depending on how you go about it.
>"It should be more like a transition. Take one peace make it shiny and then take the next."
Sure, so long as whatever is working continues to work to whatever extent that work implies along with all the connected concerns including, but not limited to:
* Maintaining equivalent expertise in the development, administration, operations and support teams.
* Discovering and accommodating connected systems, whether they themselves are documented or not.
* Complete documentation of the solution.
* Setting and meeting realistic schedules.
* User training.
* Testing.
Most of those things are not nearly as sexy as rewriting old code in a fast new language or implementing some kind of bleeding edge system, but they are absolutely necessary.
It's not just write, compile, launch and move onto the next.
I don't want to accuse here, but it's hard to imagine full cycles of those sorts of things happening for a project of reasonable size, relating to currently broken systems in multiple jobs within two years.
>"At the and its not just about the revenue. The people how make the revenue should have a good nice workspace plus nice software which helps them not throw stones on there path. If people are not so frustrated they work better (I think)."
There's absolutely nothing wrong with wanting to improve things, but there's plenty that can go wrong and hurt everyone involved depending on how you go about it.
>"It should be more like a transition. Take one peace make it shiny and then take the next."
Sure, so long as whatever is working continues to work to whatever extent that work implies along with all the connected concerns including, but not limited to:
* Maintaining equivalent expertise in the development, administration, operations and support teams.
* Discovering and accommodating connected systems, whether they themselves are documented or not.
* Complete documentation of the solution.
* Setting and meeting realistic schedules.
* User training.
* Testing.
Most of those things are not nearly as sexy as rewriting old code in a fast new language or implementing some kind of bleeding edge system, but they are absolutely necessary.
It's not just write, compile, launch and move onto the next.
I don't want to accuse here, but it's hard to imagine full cycles of those sorts of things happening for a project of reasonable size, relating to currently broken systems in multiple jobs within two years.
>"At the and its not just about the revenue. The people how make the revenue should have a good nice workspace plus nice software which helps them not throw stones on there path. If people are not so frustrated they work better (I think)."
I'm not sure what you're saying here.