This series started with the pie chart, a useful tool that graphically summarizes data. However, pie charts only provide a "snapshot" of a moment. This tip focuses on bar charts, which show the data's evolution.

Written by Rafael Victória-Pereira

In the previous TechTip, I provided an example of a pie chart similar to the one below, which shows, with a little humor, the most common uses of cell phones:

A picture is worth 1,000 words. In business, a chart is worth 1,000 rows of data. Learn to create charts in real time, just by pressing a function key. I'll explain how.

Written by Rafael Victoria-Pereira

It's common sense that a well-prepared chart can make a difference when you're trying to prove that the numbers are on your side. From the simplest of charts to the most complex, they all try to provide clarity to the (vast) amounts of data behind them. There are numerous business tools (MS Excel and SAP's Business Object, among others) that are able to generate charts on demand. However, you need to set up a connection or extract the data first. Wouldn't it be nice to see the data on your program's screen and then, just by pressing a key, have it displayed as a chart?

With a good set of tools, you can do more testing with less effort and lower the costs and risks of application modification.

Written by Steve Kilner

As a long-time developer, I have to confess that there is no aspect of software development I dislike more than testing. The curse is a blessing, however, in that I have worked hard to develop testing methods that achieve maximum benefit with minimal effort. I manage projects by the following maxims:

After many years, the advantages become clear.

Written by Steve Kilner

Thousands of active Synon, or CA-2E, applications are still under maintenance around the world. The 4GL had a surge in the late '80s and early '90s, but like so many such tools on all platforms, it had its detractors.

How do you deal with large, complex systems?

Written by Steve Kilner

The field of science that studies how programmers interpret programs is called Program Comprehension. With the world's ever-growing pile of software, it's an important subject.

Research has led to useful ways to understand what programmers do, especially those who work with legacy systems. This is particularly important in the RPG world, which exhibits persistent attrition of programmers with application knowledge.

Is it possible to manage a legacy system in a modern way?

Written by Steve Kilner

"Legacy applications are a goldmine of valuable business rules and design intelligence."

"Modern developers want nothing to do with RPG or the AS/400 other than get rid of them."

You've probably heard these seemingly conflicting statements.

Lots of development and no controls?

Written by Floyd Del Muro

One benefit of developing software for IBM i is that it's relatively transparent in terms of understanding application architecture. It's always been fairly easy to hire RPG or COBOL programmers to pick up a project where another developer left it. Of course, there's some ramp-up time while the new programmer learns the program and database schemas, but the architecture of most IBM i applications is similar enough to make this a nonissue. Therefore, organizations typically hire, retain, and eliminate many developers over the life of their IBM i applications. The penalty for using this approach has been extremely minor, given the relative stability enjoyed by applications that may have multiple versions lying around.