Leveraging Code

When I was speaking to a customer about “leveraging the code” I realized that not everyone thinks about how to do that – to get the most out of the code that has been written to run their system. With systems that still require many, many lines of code, whether we call it “configuration” or “customization” it’s still quite a lot of programming done to make the systems run. To have the best, most efficient system, we must think how to best use that programming. The larger the implementation, the more important this becomes.

Surprisingly, I find that many people don’t think of this. I don’t merely mean that people new to the industry don’t always think of this, but even those people who are doing implementation-after-implementation sometimes have a “let’s just get this to work” attitude about new programming and modifications. On the other extreme, we have people who look at old code, get frustrated, and merely insist it be entirely rewritten.

The problem with the rush-to-finish approach is that you need to spend the time to make sure you’re doing your best work with that code. The other approach is just as bad as it just takes up time that might not be necessary to replace something that might not be best replaced.

Here’s Where I’ll Get Some Hate Mail
I get real heat from saying this, but I absolutely don’t agree that programming should automatically be thrown away when there is a new module that replaces it.

First of all, the new modules never fully offer the same features as the current code. Second of all, it’s not just the rewriting of the code that takes time, but all the testing that needs to take place. It’s not just about paying money to someone to do all this work, but it’s also about finding time internally to get this all properly tested and accepted.

More Hate Mail
Additionally, I’ll make another controversial statement: programs should not automatically be rewritten just because they’re written terribly.

Once again, to spend the customer’s money to rewrite something that’s working isn’t trivial. Additionally, the money spent on rewriting something that is working could be spent to give users some of the features they’ve been asking for. While I agree that making code “better” helps its administration, this is a truly subjective thing to do.

Let me just say that I’ve seen plenty of code that I merely don’t agree with the way the person did one thing or another. To me, that is NOT a reason to rewrite it. Others would disagree. If they do not agree with what another person did, they feel that is license to entirely rewrite it. This is partly an ego issue, where the person reading it is so egotistical that they believe they are the only person that can write a program, properly. It is also due to greed. Quite often, the person is glad to extend the work they’re doing to keep charging the customer with whatever excuse they can come up with.

On the other hand, I’ve also seen some truly horrendous code that is so awful that I wish I could show it to the world to shame the groups (software vendor or implementation services company) in front of the world. That isn’t possible, as it violates the NDAs (Non-Disclosure Agreements), but I dream about it when I see the most egregious examples. Even then, I don’t automatically tell customers that we MUST rewrite the whole thing.

Bottom Line
The customer and the person making the changes (such as myself) need to talk about the goals of how the money being spent should be applied. If the customer is up for a rewrite and tidying-up to make their system more manageable, that’s great. If they truly just want to spend money to get a few extra features to make their process more efficient, we should respect that.

While there are people in our industry who seem to make a living off finding ways to just rewrite what the last person has done, and more power to them if the customer lets them do that, but most of us should be spending our time working to make the best of what the customer already has. Hopefully, some of the people who just don’t care and write truly horrible code would get some lessons in doing a better job so that we can spend our time merely building on the code customers already have. However, let’s be honest – in our industry, any warm body who can spell “IF” and “THEN” is put to work programming with little to no oversight and we’re going to have to keep moving forward, regardless.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/