I work with both revamping/fixing of legacy systems and developing new customized system for medium sized businesses.
I've seen all the bad points in Greg's list many times over the years. The thing is I've even seen it in the code I write myself - please give me a chance to explain.
Most of the systems I've delivered with poor maintainability has been on a tight schedule (should've been done yesterday) and on a limited budget.
It's the same story everytime: You get what you pay for - and you get it in a condition your schedule allows.
If a library or system has stupid dependencies it's because that is what was available at the time - no time to wait for version 2.smartshit. If I deliver something written from scratch it's because I couldn't find a framework or foundation that met the requirements at the time.
Documentation is luxury - even in the clients own eyes - all my clients usually opt-out on it because of schedule and price.
I do use version control and staging environments but not always in favour of any programmers taking over - why? Because of the nature of the production environment (which is usually build on top of other hard to maintain legacy software running on a server OS that can't be upgraded in fright of it will stop working etc.).
Trust me you actually spend quite a lot of time and effort to investigate and make the best out of your time and money given - and usually you leave with happy clients - and yes the programmer taking over your shit will be fustrated and have some good laughs (I know because I fix other peoples legacy code as well - I've seen a lot of funky stuff in my time) - but hey you make a living out of it so that's part of your job :)
