Shaking IT Up: 10 Ways Programmers Can Ruin Your Day

Programmers are unique and remarkable beings. They work their technical magic to bring efficiency, consistency, and overall happiness to a company’s workforce. I know all this because I am one of them, or used to be. I now help ensure that happiness, efficiency, and consistency are what the programmers are producing. And most of the time, they do their jobs well. But then there are times when one programmer can ruin someone’s day. It is these times, not the good ones, that are remembered the most.

So how can we fix this problem? How can we make it so programmers use their powers for good instead of evil? No one in your company can ignore this issue. You can be a user, manager, or another programmer. It does not matter. Whoever you are, a programmer can ruin your day. I’ve listed 10 ways that a programmer can ruin your day. There are certainly more than 10, but I stopped there so that it would be easier to focus on the solutions, which, by the way, are very simple: Make your programmers stop doing these 10 things! It’s simple.

What’s not simple is knowing what the issues are and actually getting your programmers interested enough to change their ways. I’ll help you with the former, but you’ll have to do the latter. The following day-ruining exercises are not listed in any particular order. One is not any more important than another, with the exception of number 10. You’ll also notice that I only cover technical issues. This is not meant to be a technical article (you don’t have to be technical to understand the issue and help the programmer)–just knowing that these issues exist is half the battle. If you’re not technical, you can find someone who is, to help diagnose the problem. With that in mind, I give you 10 ways a programmer can ruin your day.

1. Writing programs with little or no comments in the code.

Everyone’s seen this type of code. Heck, we’ve all written it. We’re too busy to put the comments in as we’re coding, so we just don’t do it. We say things like, “I’ll go back and add the comments later.” Like that ever happens.

Poorly commented code is like a time bomb. It won’t really hurt you when the code is first written. It’s only later, when a modification needs to be made and the original author has moved on to greener pastures, that this issue will raise its ugly head. Then there are those programmers who do indeed comment in their code, but the comments are nothing more than a duplicate of the programming language syntax that was written. The comment is as cryptic as the code, and is now listed twice to double the confusion.

It seems that just as men don’t like to ask for directions, they don’t like to write them, either. Just as we’ll drive around for hours looking for a destination, we’ll aimlessly wander through code trying to find our way around it, too. The analogy stops there, though, as women, too, don’t like to write commented code. So the good news is that men and women finally agree on something. The bad news is that both sides are wrong.

2. Hard-coding data and devices in the code.

My day was recently ruined because of this very issue. Much analysis had been done to determine the necessary data changes that would have to be made to handle a modification in the commission structure. We were smart, we thought, years ago when we put the logic in the database and made everything table driven. When changes needed to be made, we made them in the appropriate tables and no code was touched. Everything worked out just fine; the sales reports were printing properly and we were even congratulated by the sales department for a job well done.

Well, much to my dismay, the month-end sales reports that ran a few weeks later were not doing so well. In fact, the numbers were ridiculously wrong (that’s right, not just wrong). We immediately put the original programmer on the prowl for the problem (because of issue 1 above and issue 9 below), along with a few of our senior programmers, because the issue was so hot and so visible. After hours of investigation, it turned out that much of the data that was so nicely stored in the database was also hard-coded inside a couple of the month-end sales reports. This type of thing happens more than you might think, and I challenge programmers and managers alike to randomly take a look at some of your programs and discover how much data is actually hard-coded in those programs. It will manifest itself in many forms, such as hard-coded printer devices or data stored in arrays that is also stored in the database, but it is there and ruin will strike you soon.

3. Not letting the database engine do its work.

OS/400 is integrated very nicely with the DB2/400 database. This was not always well known, but it has been the case since its inception. The DB2/400 database is very powerful and can be used for much more than simply storing data. But most programmers don’t use it properly. Instead, we force our programs to do all the work. No big deal, right? Why not select the data we want in our RPG programs and give the database a break?

Well, for one, by doing the data selection and filtering in our programs, we do so by hard-coding (see issue 2) and, as I just mentioned, hard-coding will end up ruining your day at some point. Another reason we should let the database do its own work is that it is really good at it, and does it much faster than our programs. So this issue might ruin your day twice. Once because it turns out that a simple change in selection criteria ends up being a major program modification and, again, because the application takes too long to get the data, therefore causing the user to take a 30 minute coffee break every hour as he waits for his screen to fill with data.

Spread the word: Let the database do the work it was meant to do. Get that stuff out of the programs. Of course, this particular issue is for OS/400 programmers only. Some three-tiered architecture systems, such as SAP, actually develop their own language so that it can do the database’s work for it and let the database simply store the data. If you are on that system, what are you doing reading this newsletter?

4. Reinventing the wheel.

Programmers can be creative, and that’s a good thing, but if something has already been written, don’t write it again. Your day will be ruined when a user asks you to change how something is calculated and naively believe that your staff will have the change done in a few hours, but are later told that 92 different programs have that calculation logic embedded in it and it will take a few weeks to get them all coded and tested. Teach your staff to re-use routines, share code, and research for the existence of something before they go off and write it again.

5. Not using modular coding techniques.

This issue might ruin a week, a month, or even a year. It’s the program that keeps on ruining. How many shops out there have a program with more than 20,000 lines of code? Probably most of you, right? Then you know how difficult it is to fix or modify a program of this nature. Business logic is mixed with presentation logic, which is mixed in with more, unrelated business logic. About 80 percent of the programming backlog is tied to this program, and it is the hardest program to fix. Worse, because it is such a house of cards, you can be sure that any modification made to this program will create more issues. The program is nothing more than a random bug generator. Keep the Advil, Mylanta, and scotch all handy for this doozy.

6. Poor or no testing.

Enough said.

7. Writing programs with little or no error handling.

Programmers love to assume that either the data is correct in the database or that the users are going to enter what is expected of them on their data entry screens. For this reason, we code without worrying about what will happen when that data is not perfect. The problem is that data in our databases is sometimes invalid, and users, given the chance, will always enter bad data over good (okay, only sometimes, to be fair, but it feels like always). Because our programs don’t catch, trap, or even fix data entry and integrity issues, they become the path to even more data problems. Soon our database is a mess and we are blaming the users. RPG, COBOL, Java, and CL have very good methods for handling errors. Yes, it takes a little more time to code these routines, but if you document well (see issue 1) and re-use code (see issue 4), the upfront work in designing these routines will be returned many times over as your application matures.

This issue might ruin more than just one day because by the time you realize that your data is bad, because of holes in your applications, it may be weeks or months before it can be fixed, both in the code and in the data. The best thing that can happen is that your programs bomb. This may be ugly, and can certainly ruin your day, but at least you will know about the issue right when it happens. I take back my earlier statement that these issues are all of equal value. This one might be just as bad as number 10, or at least will aid number 10 in ruining as many days as possible.

8. Writing spaghetti code.

Spaghetti code goes hand in hand with the modularization issue (see issue 5), but I made it its own issue because even modularized code can be poorly written. Spaghetti code is code that goes all over the place, with no rhyme or reason. It contains no structure and seemingly no thought. It’s as if you asked 100 programmers to pick a random spot in the program, add his unrelated business logic, make sure it compiles, then slam it into production. Maintaining or reading spaghetti code is nearly impossible and, just like poorly modularized code, the more you maintain a spaghetti-coded program, the more problems you add to the program. Your best bet is to stop maintaining this type of program and train the users on the current bugs that exist. Call them features. Either that or completely rewrite the program, keeping this article close at hand to help you with what not to do.

9. Doing in 100 statements what can be done in 10.

I wasn’t sure that I was going to add this one at first, because if the code works, should one care about the method used to get it to work? The answer is an emphatic yes. It’s not enough to get the code to work; it must work efficiently and be easy to read and maintain, as well. This way to ruin your day is closely related to poor or no comments, and that is why I added it. I see this happen a lot, and it leads to a much bigger problem. You’ve probably heard this statement a million times: “Let Joe work on that program because he knows that application.” That always leaves me perplexed. Why is it that only Joe can work on the program? Is it really because he is the expert in whatever business problem the program is attempting to solve? Or is the program written so poorly that Joe, who happens to be the original author, is the only one who can read it? Either way, your programmers must learn the proper techniques to accomplish a task. Sure there are many ways to do something, but there are usually only a few best ways to do it, and in order to limit the number of ruined days, we should strive to learn and then use the best way.

10. Writing programs that contain bugs.

This issue is rather obvious, but the fact is that your programmers can fail at the other nine issues and still produce bug-free applications that meet users’ expectations. They can also write the most well documented and efficient code known to man, properly avoiding all the traps mentioned in this article, and still write a program full of bugs. Nothing will ruin your day more than programs filled with bugs, and as plain and simple as that is, it still happens to us many times every day. Avoiding the first nine issues will go a long way toward limiting the number of bugs in your applications, but that is not enough. You also must understand the business issue at hand and then understand how to properly transfer that business issue into your programming language to best fit users’ needs.

There you have it. You are now armed with the knowledge that will not only make your programmers better but also keep the ruined days down to a minimum. As I said, there are more than 10 issues, and there are also other issues that don’t have anything to do with technical skills. However, this is a good starting point for some coding standards and templates in your shop. Programmers with good intentions and some well-written standards, templates, and procedures, can do great things. But with great power comes great responsibility, and we must all do our part to see that this responsibility is upheld, or guess what? We will all be outsourced.