I have been so busy, I'm deep in the middle of a new system development with work, but as a personal side line I'm also completely re-engineering a different system, you know when you've worked on something or in a field as long as I have it becomes second nature to want to do things your own way... So I've been doing just that.
I picked a coding standard & style, I've stuck to it, I've pulled in SDL and Boost, it's all C++ and it's around 100x faster than the original system and amazingly more simple to access.
The problem, the boss doesn't want it, he doesn't trust it. More importantly he doesn't trust me.
My previous boss has seen the system he's gobsmacked, his opinion was that it was exactly what was needed four or five years ago, and to have done it alone with no support in parallel with my real daily work just blew him away.
So what was my current bosses argument? Well, it's one I can't counter, his point is that the current system I want to replace has been out on the market with real customers for years, nearly twelve years in fact, and I ported it to cover five different platforms. He's right, it is, it has been, and it will be again, but that doesn't make the system any good. All it lets a manager in his position do is quantify the risk versus reward, and I can not argue or knock him for that.
However, what I can knock is when you have an employee, like myself, who lives and breaths this technology, who writes books and blogs on the topic, and they've worked for you for 14 years... They're investment in the product is vastly more than the product risk for taking up the new system, especially when the new system would only go to trusted customers for trials, it would not immediately go out to the full estate of customers. You reduce that risk you've presented drastically, there is less risk, but the reward for introducing that new system is vast, acceptance of it is equally as likely as giving customers the original old system in a new skin.
They are 100% compatible by the way, content for one works on content for the other, they work in the same sequence and order, they are the same except the underlying code is vastly better in one and a squelchy pile of over cooked spaghetti in the other...
So, to managers out there, the world over, yes evaluate your risks, but your developers are a huge component of that risk, if you have a good one, trust them when they do 40+ days of leg work on something, they're not doing it just for their own sake, they're doing it because of a driving need.