There are some ugly screens in your applications. Your users know them all too well. They’re the screens where users have to copy information with a pencil and paper, or where one wrong keystroke will wipe out 15 minutes of work, or where the application can suddenly freeze for no apparent reason.
Your developers know those ugly screens, too. They’ve tried to fix those screens for years. But the code is a kludgy, convoluted mess, and simple fixes won’t work. Ripping those screens out and making them right would cost a bundle, which you don’t have to spare. Besides, users have lived with those screens, ugly as they are, for a long time, and if they have to, they can keep living with them.
So if you can’t fix an ugly screen, what can you can do with it?
Document it. Don’t pretend that these eyesores don’t exist. Keep a list of them. Track what fixes were tried and didn’t work, and when and why. That way, you’ll always know how long it’s been since someone last tried to fix one. If the application is ever completely rewritten, you won’t forget and inadvertently preserve that ugly screen’s logic.
Give your most junior developers a shot at it. Hey, they don’t know it’s impossible to fix. If they come up with an ingenious solution, that’s great. If not, at least they’ll get a taste of the worst your legacy code has to offer. That’s something you can be sure they didn’t learn in school.
Bless the work-around for it. Your users have probably figured out the best way to deal with each ugly screen. You’ve probably been too embarrassed to include those work-arounds in documentation and training. Get over it, and get the users to write up those work-around descriptions. And who knows? Once your developers know exactly what the users do to dodge ugly screens, they may even figure out a fix.
Put a bounty on it. Nothing encourages developers to take another look at problem code like a cash reward for coming up with the idea that finally fixes it. But save your bounties for longstanding problems, or you may end up with “problems” in new code that just happen to be prime candidates for bounties.
Ask users how it should work. Maybe you’re going about this the wrong way — trying to fix logic that no longer needs to be so convoluted. If users can simplify the screen’s functional definition, you might be able to make it work. But be careful to manage expectations. Don’t tell users you’re fixing it — just that you’re trying.
Junk it. OK, virtually junk it. Ask a small group of users to try using the application without touching that screen. If they can’t, you’re no worse off. If they can, maybe you can decommission that screen entirely.
Find out how important it is to the users’ managers. If it’s top-of-mind for a manager, you can discuss what it will cost to do this expensive fix right. If he didn’t know about it, your question demonstrates that you’re being proactive about solving his users’ problems. Either way, it helps you gauge how big a deal it really is.
If nothing else works, ship it overseas. Face it: You can’t fix this code in-house. And your chief executive officer wants you to dip a toe into offshore outsourcing. Your offshore partners won’t love you for sending your nastiest, thorniest problems as their first projects. But if they can fix those ugly screens, you’ll know you got your money’s worth.