You've all heard the adage/joke, right? "That's the nice thing about Standards - there are so many to choose from!"
Back in November 2017, in response to a Slashdot post covering a story that Eric Raymond saw three viable alternatives to the C programming language, I wrote a post which I titled "The Problem With Me-Too Languages" [slashdot.org].
I think part of that post might be useful in this discussion:-
"So whilst I'm always interested in learning about developments in programming language design, I think it hel
Any line of code that makes it to Production is technical debt, regardless of how "new" the technology is.
When it comes to legacy replacement I like to ask how many person-years of development are sunk into the system? Assume 60-75% of that cost to replace. And risk, add 1% per person-year as the chance of some level of failure (including complete failure).
I've been expecting Cobol and other legacy jobs to see pay spikes due to lack of talent as people retire. What's happened is that talent is moving to consulting companies and clients don't mind high $ per hour for this. It's far cheaper and MUCH safer than a rewrite.
This approach to staffing can work but a lot of embedded knowledge is not retained in the organization (a very bad thing).
Regarding a specific legacy approach, functionally slicing legacy systems to try a step-by-step approach to modernization is the fastest way to unmanageable integration code (and mapping table proliferation).
I don't have very much experience of working with large AD Teams, which is to say that all my experience with AD Teams has been earned within just two organizations.
But one observation that I would make would be that with Developers as a subset of the broader community of technologists, I've found them to be among the earliest of early-adopters; a community of people who love new and emerging technologies. This flows through to the workplace and results in the idea that the moment a new (language/IDE/too
The N+1 Problem (Score:2)
Back in November 2017, in response to a Slashdot post covering a story that Eric Raymond saw three viable alternatives to the C programming language, I wrote a post which I titled "The Problem With Me-Too Languages" [slashdot.org].
I think part of that post might be useful in this discussion:-
"So whilst I'm always interested in learning about developments in programming language design, I think it hel
Re:The N+1 Problem (Score:2)
I appreciated your final comments.
Any line of code that makes it to Production is technical debt, regardless of how "new" the technology is.
When it comes to legacy replacement I like to ask how many person-years of development are sunk into the system? Assume 60-75% of that cost to replace. And risk, add 1% per person-year as the chance of some level of failure (including complete failure).
I've been expecting Cobol and other legacy jobs to see pay spikes due to lack of talent as people retire. What's happened is that talent is moving to consulting companies and clients don't mind high $ per hour for this. It's far cheaper and MUCH safer than a rewrite.
This approach to staffing can work but a lot of embedded knowledge is not retained in the organization (a very bad thing).
Regarding a specific legacy approach, functionally slicing legacy systems to try a step-by-step approach to modernization is the fastest way to unmanageable integration code (and mapping table proliferation).
Re: (Score:2)
But one observation that I would make would be that with Developers as a subset of the broader community of technologists, I've found them to be among the earliest of early-adopters; a community of people who love new and emerging technologies. This flows through to the workplace and results in the idea that the moment a new (language/IDE/too