Jim Plush's Programming Paradise

By now we've all seen that AIG has removed their logo from their main corporate headquarters in New York. The name is tarnished and they will be forced to re brand themselves to attempt to gain trust from investors and clients again. Phillip Morris just recently made the same move. So how does this help you with your application? We've most likely all had to maintain someone else's code base at some point. You're the new guy and you get stuck on the project no one else wants to do. Sometimes this project has high integrity and has a good reputation within the organization, then there are times where you are tasked with re-tooling or re-implementing an existing tool.

I find myself in a situation here where there is an existing tool that was contracted out to be built without supervision, not in a standard framework of any sort. It's a huge tool at this point over 200,000 lines of php code, javascript mixed in with php, no separation of code, functions declared in individual pages, Numerous security holes, really just an unmaintainable mess at this point. Let's say the application is called "X123". X123 has a horrible reputation here. Customer complains, internal complaints, etc... no one has faith in this tool. As we start the requirements gathering process for an internal rewrite the first order of business I wanted to get done was re-brand the new application. You don't want people mentioning X123 anymore. It's name is tainted, you want your new application to instill confidence. Now we can call it "A987" (names changed to protect the innocent).

No one knows "A987" it has a clean slate with our user base. It's up to us to keep that name untarnished. Re branding has already enabled us to work with stakeholders without the negative feelings X123 brings, people get exited knowing there is a new project to replace it. Sometimes you're in a position to re-brand these legacy internal applications, but what if you can't? What if the name is set in stone but is a tarnished name? The best thing you can do is let the user base know there is a new sheriff in town and you want to work with them to address existing issues they have. Create a bug reporting link on your application, treat each customer complaint like a stage 1 missle alert. Give constant feedback to users on the status of their bug reports, make sure you track all changes and send out release notes to show progress. Make sure you show people the app is moving in the right direction. Everyone has a customer, even for internal applications your co-workers are your customer, make sure you treat them as such.

Remember you and your team control how you are viewed to the outside organization or world. Professional programmers value that reputation and want to see it stay solid. Scripters are there for a paycheck and aren't overly concerned with customer satisfaction. Be a pro.