The lack of it integrating shiny new features may be one of the factors contributing to this.
I have little story that may back this up a bit.
Recently, I had a reason to write a small command line tool that parses through thousands of xml message files looking for an out of order sequence.
I am a c#/java developer but I thought this would be a great opportunity for me to renew my scripting skills. I started scratching away at it using perl. Not long in to it I realized xml parsing/validation/xpath was going to be an issue. There was a ton of 3rd party libraries, each lacking some key feature. And all had awful documentation. I took a peek at xml support on python. It seemed a little better but it was still going to a harrowing search through various libraries.
In the end, I did it java. I am sure if I had more time I could have done it in perl or python.
I realize such an endeavor is both daunting and expensive but you may want to assess your list of issues around this topic. I've worked in several mature products and the differences are quite startling. Good architecture not only prevents issues from getting in but encourages great code.
If you don't have a detailed architecture document, this would be priority number one. As you write this document you'll also be building up a laundry list of the uglies.
Some of the interesting findings I've seen in past:
1. Duplicated code. Usually a symptom of lacking modularization or lack of architecture training
2. Change complexity - to add relatively simple change, too many files are touched. could be due to over engineering or the lack of one.
3. Slow builds, hard to configure and test. high time for componentization. cut down on the dependencies. create mocks and emulators. implement dynamic
loading/plug-ins. basically, optimizing dev testing cycle results in more testing, and better code.
Slashdot Mirror
Seriously? Let's not get carried away. It's shameful to say such things while we have countries like North Korea.
The lack of it integrating shiny new features may be one of the factors contributing to this.
I have little story that may back this up a bit. Recently, I had a reason to write a small command line tool that parses through thousands of xml message files looking for an out of order sequence. I am a c#/java developer but I thought this would be a great opportunity for me to renew my scripting skills. I started scratching away at it using perl. Not long in to it I realized xml parsing/validation/xpath was going to be an issue. There was a ton of 3rd party libraries, each lacking some key feature. And all had awful documentation. I took a peek at xml support on python. It seemed a little better but it was still going to a harrowing search through various libraries. In the end, I did it java. I am sure if I had more time I could have done it in perl or python.
I realize such an endeavor is both daunting and expensive but you may want to assess your list of issues around this topic. I've worked in several mature products and the differences are quite startling. Good architecture not only prevents issues from getting in but encourages great code.
If you don't have a detailed architecture document, this would be priority number one. As you write this document you'll also be building up a laundry list of the uglies.
Some of the interesting findings I've seen in past:
1. Duplicated code. Usually a symptom of lacking modularization or lack of architecture training
2. Change complexity - to add relatively simple change, too many files are touched. could be due to over engineering or the lack of one.
3. Slow builds, hard to configure and test. high time for componentization. cut down on the dependencies. create mocks and emulators. implement dynamic loading/plug-ins. basically, optimizing dev testing cycle results in more testing, and better code.