Ask your team if there are any areas of the system they fear to change. How could you mitigate that fear?
I've talked a bit about this and again, one has to be careful not to tattle to much on one's company. Again, I don't think this would be much of a surprise to anyone so I think I'm on safe ground here. As I've stated before, our company developed the original version of our product in 2004. At the time, it was written primarily in Perl. That was a skill that was prevalent at the time and we had a lot of the best Perl development capability on staff. Over the past fifteen years, that has changed and the prevalence of Perl has diminished. Additionally, the number of people proficient in Perl on our engineering team has shrunk while newer technologies are more in demand and we are staffing for those demands.
What this means is there are some areas of code that are legacy and, while they work well, there is a genuine concern that making changes to it will be difficult to maintain and there is also real uncertainty as to what the effects of making changes are. To that effect, we have taken a different approach of modernizing components with newer languages and shifting over to those newer components wherever possible. This allows us to slowly shrink down the dependencies on those older modules and lessen their footprint. At some point, we will reach a minimum where we will have to say "OK, we have cut this down as far as we can go and now we need to go this last mile." that is an ongoing process and one that will probably take years to fully complete.
No comments:
Post a Comment