The Four Hundred

"Will it scale" is a question rarely asked during the iSeries software development cycle. Worrying about scalability is usually left to systems administrators, because they're in constant communication with the application developers and are involved in testing and analysis during development. But, as with most development issues, scalability is more often dealt with at the back end, when users complain about response times or the systems group notices CPU or disk usage is approaching capacity. Then everyone scrambles to figure out why.

By then the developers may have moved on to other projects and left their house of cards to a technical support group, which would have more luck in learning the Russian language than in figuring out some other developer's code. So the developer is brought back in to help decipher the code, which delays his current project. Even if the original developer has not moved on to another project, the fact remains that his original code was not designed to handle the scalability issues at hand and the band-aid solution devised to fix the problem may do more harm than good in the long run.

Your answer should be yes, unless you're a liar or it's your first day on the IT job or you are not in IT and are only reading this column because you heard it tends to piss people off. The fact is, IT is notorious for the scenario I've just described. We all know it. And when it comes to scalability in iSeries applications, we're able to reach new heights in our ineptitude.

Bravo! The Java/Web development world seems to have this problem solved. (They have other issues that need to be addressed, but I will save them for another column.) When they design their applications, they constantly discuss scalability. They work with their systems admin department to load test, to ensure that the application can handle the maximum number of concurrent users. The question of whether it will scale is often asked and affirmatively answered in the Java/Web development world.

Now, I realize that in the wide world of the Web, the number of users cannot be predicted, and therefore testing for scalability is a must. You've got to know what kind of load your application can handle. The argument can be made, and is probably being formed as you read this, that most applications on the iSeries are used by internal users, which allow IT experts, or people who simply know how to count, to predict the maximum number of users that might use a particular application at any one time. But this argument falls flat for many reasons.

First, even if we could predict the number of users, we usually don't. I have been involved in many technical design reviews, and in most of those reviews, performance and scalability based on the number of users is not discussed. If some savvy technical person suggests a performance enhancement, many times, although not always, it is either brushed aside completely or only taken into consideration if the timeline is not affected (timelines, don't get me started on those).

Second, it is no longer the case that internal users alone use the iSeries. E-commerce and e-business have changed the way we use our iSeries boxes. Our DB2 data and legacy applications have been opened up to the outside world, and therefore the number of users that can access that data and those business rules can no longer be predicted. Producing scalable legacy applications is now as important on the iSeries as it is for that new-fangled Java stuff.

And yet, we on the iSeries choose to go on developing the way we always have. That is to say that we spend as little time upfront as possible designing for scalability, only to deal with it on the back end. This is not just true for scalability issues; it is how we design and test in general. But that's a topic for another column. We have not learned from our mistakes. In fact, it is so commonplace to have software errors, deficiencies, and performance issues after implementation that we don't even realize we are drowning in the very mistakes from which we should be learning.

I have seen this happen so many times. An application is designed and coded, then it is promoted to the quality assurance team, which runs it through a few scripts with small data samples that would make an entry-level-programming instructor proud. The first time that the application is run for real, with real data, on a machine that is already working hard--BAM!--you're getting paged in the middle of the night and your spouse is kicking your butt to the couch.

So what do we do? We throw more memory at it, or maybe more hardware. We assume that if our applications don't scale, there's got to be something wrong with the machine. Now that's not to say there isn't something wrong with your machine and that more memory and hardware isn't exactly what you need, but there are so many things that we as designers and developers can do to ensure that our code scales effectively without adding significant time to the development cycle.

In fact, often times improving the code or, heaven forbid, designing more appropriately in the first place will add very little time to the development cycle but may save a significant amount of time on the back end, and that's a good thing, because the back end is usually where the customers and users are angrier, your manager spends more time in your cube, and your code gets uglier.

If you throw memory at poorly designed code, the code is still poorly designed, right? You've just covered it up a little. Depending on where that memory came from, you may have caused pain somewhere else. So not only does the poorly designed code still exist, but you may uncover additional poorly designed code as well, or make something that isn't that poorly designed not perform so well anymore. It's like trying to get rid of your headache by smashing your big toe with a hammer. Sure, you may not feel the headache for a while, but it's still there. In the meantime, you now have a sore toe to deal with. That's not scalability; it's stupidity.

So what can we do about it? Are we doomed to a life of angry customers who noticeably age as they wait for their applications to respond? The answer to that question is probably a resounding "Probably!" But our intentions and efforts should dictate otherwise.

Plan ahead for scalability issues. Assume--yeah, I said assume--that your users no longer live inside your company's walls. Analyze how you access data and process that data inside your applications. Build the components of your application with scalability in mind. Maybe that means employing some new technologies such as SQL and ILE; maybe it just means removing data selection logic from your code and letting DB2 do more of the work. Maybe it means a complete revamping of your architecture.

Whatever the case, invest some time to figure it out, so that in the future when someone asks "Will it scale?" you'll not only know what the heck that means, you'll be able to provide a well-thought-out answer, and maybe even answer "Yes."