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

3 Thoughts to “Leveraging Code”

  1. There is no call for any hate mail in what you have written. I think anyone who has been around the software block will tell you that upgrades are usually not your friend. For our own client base, we do not do upgrades with regularity. Each client is optimized to what they have and we do not make changes lightly. They usually get rammed down our throat and usually because of some bonehead decision from Microsoft with their browser.

    Stability and reliability are the most important thing to all of our clients and therefore change for change sake or some obscure coding practice is simply not accepted.

    So if you get some hate mail, you turn them over to me, I will set them straight and then some.

  2. Brian Meadows

    If faced with a pile of lousy code, I think the simple approach is to estimate for your client the extra overhead it took for you to work out what was going on and then do the work compared to if the code had been well-written and commented. Also give them an estimate of how long it would take you to remedy the situation. Then they can balance the extra cost of each new person who has to work with the code against the rewrite or reworking. You need to give them some fairly concrete examples of just what’s wrong any why, though. Otherwise I’m entirely in agreement with you, if the client thinks that continuing to work with a heap of scrambled code is the way to go, then stick with it. After all, unless it’s so bad that you don’t *want* the repeat business, you’ve got a positive incentive there for them to come back to you for any further work! 🙂

  3. […] ago, I wrote a post on leveraging code where I discussed the issues of casually throwing code away: https://outonalims.com/2014/09/16/leveraging-code/ Today, I’ll talk more about when to rewrite the […]

Comments are closed.