We've turned into a culture in which writing code that's already been written has become standard operating procedure. It's no wonder the adoption of subprocedures, while increasing in recent months, has been slow at best.

In virtually every shop I visit, people claim they would rather use a tool than write their own version of a routine, but in practice, even when such a tool is available, they write their own version anyway--effectively reinventing the wheel. Maybe it's boredom or too much free time.

Yes, this hypocritical practice is becoming disturbing. We say we want to use routines that are already written and proven to work, yet when push comes to shove, many programmers sit down and start writing routines from scratch. Oh sure, there's code "stealing" that occurs, but that's been a part of programming since the beginning and is to be expected. It is the rewriting of routines that are readily available as "canned" in-house libraries of stuff or even low-cost, third-party packages that is confusing to me.

When I wrote the CodeStudio editor (a Windows-based editor to replace SEU), I wrote it in C++. It was common practice for me to look for prewritten routines to do certain things; if I couldn't find it, I wrote it. For example, the "tabbed dialog box" (now common in Windows XP and other platforms) was not available as a native interface under Windows 3.x or early Windows 95 implementations, so I developed one. Later, when everyone moved to 32-bit Windows platforms, I migrated my own code to the native interfaces. Of course, my implementation was "better" (tongue in cheek), but why use my code when native interfaces were more than good enough?

Another thing I needed was "tooltips," those little yellow pop-up windows that appear over a toolbar icon when you move the mouse over them. Originally, this feature was not included in the standard set of interfaces, so I started to write one. But then I found a company that already wrote a similar interface that also had a lot of extra features--not that I needed those features, but they were cool nonetheless. So rather than reinvent the wheel, I purchased this "tooltip control" from the vendor and incorporated it into my application.

Instead of spending a month or so tweaking tooltips in my application, I worked on adding a Procedure Wizard to the package. Which one do you think added more value to the package? Tooltips or a Procedure Wizard that allows you to generate the source code for a procedure and its prototype? Needless to say, I continue to use the Procedure Wizard to this day.

My point is that we have to weigh the cost of spending time reinventing compelling but irrelevant routines in our code versus using an in-house library of prewritten routines or a third-party solution. It is pointless for all 600,000 iSeries installations to, for example, write a routine that creates a user space or convert a value from and to hexadecimal notation.

Why not use something that has already been written? If it's an in-house routine that isn't coded very well, then I understand attempting to reinvent the wheel. If it's a third-party solution, it had better be well-written.

I think some of the problem stems from the myriad examples on the Internet. Many of us are now in the habit of asking for free example code via email and online forums. Many times, they take that example code and present it as their own to their employer, thus effectively being paid for someone else's work. But that situation will have to wait for another article.

In other situations, people are presented with "free" solutions off the Internet. If they get a solution from someone else, they often take it, modify it, and get it to work the way they want. But if it's available as a third-party solution, they rarely go to their boss and ask to purchase that solution. Instead, they will spend time rewriting the same solution. Often, their labor costs as much as or more than the third-party solution and rarely is as well-written.

Even if a third-party solution is available, programmers often think that their employer is paying them to write code, so why not have their employer pay them to write the solution? In other words, they personalize the cost of the third-party solution. This, in the iSeries market, is the absolute wrong thing to do.

Some people will also compare the cost of a third-party package to that of a PC package. This is also an invalid comparison. PC software is typically priced on a per-user basis. It just so happens that per-user also means per-PC. Do the math and see if iSeries software is really much more expensive than PC-based solutions.

Let's look at a hard example of the cost of rolling your own. Of course, salaries for programmers vary widely throughout North America, but for the sake of argument and easy math, let's say that programmers everywhere make $1,500 per week (gross pay), or $78,000 per year. This means that each day a programmer works on something, the company pays $400 for those services. That includes the programmer's $300 base salary, plus the typical one-third overhead for benefits and whatnot. This comes to about $50 per hour. And remember, your company is paying $50 an hour for your time even when you are perusing online news articles, checking sports scores, reading informational articles like this one, planning your vacation, talking on the phone, or visiting with a colleague.

So at $50 an hour, how long would it take an average programmer to write a program that creates a user space? There is an API for it, so you will call the API. There are at least two free CRTUSRSPC (create user space) utilities on the Internet, but one of those free ones requires that you pay an annual magazine subscription to get the free code. There are also CRTUSRSPC CL commands included with TAATOOLS and RPG xTools. So if you own either of those, you can use them. But remember, we want to reinvent the wheel here to prove a point.

I was able to create an RPG IV program that creates a user space in QTEMP, including setting the auto-extend attribute on, which is required by most OS/400 APIs. The program took about 60 lines of code and about 90 comment lines. I did use prototypes to call the QUSCRTUS and QUSCUSAT APIs, which I know most people don't bother using. But I found free versions of the prototypes for these APIs on the www.rpgiv.com/downloads Web site. Since I found them, they are mine, and I can say that I wrote them. Right? (Well, actually I did write them, but let's forget about that for now.)

So how long will it take the average programming to write this Create User Space routine? I would say anywhere from 4 to 16 hours. If the programmer isn't all that experienced with APIs, getting it to work flawlessly could take 20 to 24 hours. The programmer might also spend an extra half day to an entire day trying to figure out why you have to specify both the REPLACE and the ERROR parameters on the QUSCRTUS when you only want the REPLACE parameter. So let's agree on it being a 20-hour task.

That's $50 an hour for 20 hours, or $1000, for just one simple CRTUSRSPC program.

OK, now suppose you want to create a list of field names in that user space. Is that another $1000? Probably not. It could be less, but it could also be much more. To transverse the output from a "list" API in a user space is an intriguing programming challenge at best. I would guess that, with all the nonproductive time added in, it takes one or two weeks to build the CRTUSRSPC program, add in the part to create a list of fields in that user space, and then retrieve the fields into some usable format.

So that means a simple "give me a list of field names" routine could cost your company an average of 60 hours, or $3000.

Below is the code for the CRTUSRSPC program, so you don't have to reinvent that wheel.

What Would You Do with $3000?

The question is, why waste $3000 reinventing the wheel? Certainly, as an employee, you don't truly think spending $3000 on these kinds of results is worth it, do you? I don't.

During those 60 hours, you could have inserted a /COPY or two and called a routine to do what you wanted to do. Then, after that two minute period, you could continue to do what the company is really paying you for: writing application code that solves problems or automates function--you know, things the company actually needs.

Using a prewritten in-house library of routines or a third-party package of tools could save you $2998.33 over doing it yourself. Where'd I get that $2998.33 figure? It's the difference between two minutes at the $50 base hourly rate and nearly 60 hours at the $50 base hourly rate.

Of course, you also have to add in the cost of the third-party package, if you go that route. Let's assume most are priced at about $1000 to make things simple. So on the first project alone, you won't save $2998.33; you will only save $1998.33. But after that, you're on your way to consistently saving money for your company by getting projects completed while using rewritten routines that do cool things for you. And after all, isn't that what they are paying you for?