@hopefully - caution contains a rant about corporate IT
Clearing out some of the duplicate IT systems is a step in the right direction, as there are far too many leftovers (20-30 year old leftovers) still being maintained from all the different mergers, it's just a shame people will have to be lost to do it.
I would have thought its a fairly standard IT department for a large organisation, management who can't see that doing it right, is better in the long run than doing it quickly & cheaply, deciding arbitrarily that we are spending too much time testing and so lopping 20-30% off the time allocated.
A lot of the developers who 'just fell into it' and so have no idea that there is a difference between coding something that just does what it's supposed to do and coding something well. (although there are a lot of coders out in the wild who need to learn this too - It's the difference between someone who, when presented with a greater than problem would hardcode the vaue (quick'n'dirty) or someone who would setup a parameter file and load the value from it - more time upfront but can be changed in seconds if needed)
However, there are a few of us striving to hammer home that coding for stability and maintainability is quite important for systems that, due to the industry, have a good chance of still being in use 20+ years from now.
That technical skills are not secondary skills for IT staff, that anyone with interpersonal skills can easily pick up. (developers went from being technical wizzes with no people skills, to people with brilliant interpersonal skills, but the technical aptitude of a mouldy turnip, now at least, it's levelling out to sit somewhere in the middle. although i still think it should lean more towards the technical side for developers).
That projects that might not have any immediate gains, can save lots of money in future. 2 months or so of time from a good developer, in any system, could streamline the codebase and make future development so much simpler, but noone will ever approve it as it's not a benefit that can be quantified.
That a project delivery date can't be set before anyone in IT has even heard of it, knows what it involves or has given any indication as to how long it will take.
That systems should be designed as new systems initially and then checked to see what can be taken on by existing systems, not designed with existing systems in mind from the start as that leads to things being designed badly.