Sun, May
7 New Articles

Training the Cross-Platform Team

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

The Two Ends of the Spectrum

So, let's call the first method the "distributed" approach. Another term might be "modular," but the "distributed" moniker has a more complete connotation, as I'll explain. In the distributed development model, developers are formally segregated from one another, and the development is controlled by highly detailed specifications that describe the relationships of each piece of the software to the others.

Communication occurs primarily through precise, formal interface specifications, which are "thrown over the wall" between people. The theoretical benefits to this approach include the ability to have distributed teams that work different hours and in different locations. Also, the project is supposedly more immune to the "hit by a bus" scenario because everything is completely documented and compartmentalized. If a worker quits, gets fired, or is otherwise no longer available, the project should be able to go on without skipping a beat by just plugging another worker into that cubicle.

This sort of development model, if it works, is primarily suited for outsourced projects. You substitute documentation for face-to-face interactions. This model is also the only viable approach in highly secure environments where only a few people are supposed to know the ultimate outcome of the project.

The other end of the spectrum is the group development project. In this environment, everybody knows at least a little bit about what everybody else is doing. Teams are assigned to different parts of the process, but they aren't segregated any more than necessary. You might call this the holistic model or the integrated model.

Documentation is still critical; just because you know what someone is doing doesn't mean it doesn't need to be documented. However, especially during the initial phases of development, specifications can be more fluid as strategies are floated and proofs of concept are explored. This fluidity becomes ever more important as the pace of technology increases and nearly every major software development project requires integration of new technologies.

A big requirement for this development model is team members' access to one another. In certain critical periods, just the realities of different start times or work weeks can be enough to cause great problems in development. In one large project I managed, one of my programmers worked a staggered shift; he was never allowed to check his own code into the production project after the primary shift left because it might break something critical and we wouldn't find out until the morning, when he was unavailable.

A Little Practical History

Speaking of past projects, let me give you a couple of examples that will better illustrate the point I'm trying to make.

Once upon a time, a company developed software for the AS/400 (I use the older machine purposely, because it was indeed once upon a time). I'm not trying to hide the name of the company, and I'm sure many of you can guess who it is I'm talking about, but really the name isn't as important as the story. That company was located in downtown Chicago, and all of its staff—from sales to operations—were in the same building. As the company grew, it added more floors, but nobody was more than an elevator's ride away.

Life on the Help Desk

This close unity led to a lot of synergies. Developers could talk to product managers to understand requirements. Sales people could talk to development managers to determine optimal deployment strategies. In fact, this company had perhaps the best approach for raising good developers that I've ever seen, before or since. Every developer had to spend time (typically a week) on the help desk, answering calls. This provided the help desk with some great help, since the developers knew the guts of the system and could often address problems pretty quickly. And with a good incident-reporting and -recording system, their expertise was saved for posterity.

But the real benefit, in my mind, was to make the developers see their code in action—and in the worst possible light. Programmers couldn't be defensive about it, either, or use phrases like "that's the way it was designed." If a customer's shop floor was down, they were losing real money and they really didn't care what the design philosophy was; they just wanted the code to work.

The beauty of this technique was that a programmer who spent a week on the help desk came back with a different view of his job. I spent a week and handled maybe 50 calls, many of which were from people whose jobs were negatively impacted by something I wrote. I suddenly realized that little things I didn't find important (a misleading abbreviation or a screen that required an unnecessary function key) were actually causing real people real problems. This was an epiphany.

That's because, without the reality of customer involvement, all programmers (and believe me, I'm as guilty of this as anyone) have a tendency to get invested in their code and lose sight of the real reason we do this: to make our customers more productive. This will sound a little harsh, but I don't care how elegant my code is or how beautiful the architecture; if it doesn't make somebody more productive, it's pretty much a waste of computer cycles. But that's because I'm a business programmer: I program commercial products for commercial use, and I need to be reminded of that now and then.

When Skunk Works Stink

Let's take the other end of the spectrum. Again, many of you will know exactly which product I'm talking about, but the important point is neither the product nor the company, but simply the process. This same situation can come up in any business development project, so I'm just going to leave the names out.

As far back as the '80s, it was increasingly clear that software development was becoming so complex that developers needed tools to help them get their jobs done. At that time, the term Computer Aided Software Engineering (CASE) was used for such programming aids. Differing definitions of the term existed, but in general, CASE tools generated code in high-level languages (HLLs) such as C or RPG. Later, the term "4GL" (fourth-generation language) was born, which meant specifically a higher-level language, which in turn generated 3GL (third-generation language) code. (3GL is pretty much synonymous with HLL.) Despite the many variations on the theme, the general idea is that a 4GL lets programmers write code faster and easier, eliminating much of the drudge work, usually through some sort of templates.

So since a large part of the company's budget went toward software development, it made sense to pursue the idea of creating a software tool that would make their programmers more productive. And while this was a great idea conceptually, for reasons which I'll never really understand, this same software development company made the unfortunate implementation decision to develop the product in a skunk works—in effect, in a complete vacuum.

What occurred was something completely predictable, in my opinion. The skunk works team, having literally zero contact with the development team, went their merry way and designed a product that did exactly what they wanted it to do. From their standpoint, the tool was absolutely perfect, and from a neutral standpoint, they were probably correct: It did exactly what they designed. Unfortunately, what they designed had very little in common with the actual programs needed for the application suite, so the tool was nearly useless for actually developing application code.

This is as close as you can get to the old phrase "The operation was a success, but the patient died." It took many years to get the tool to actually be able to generate code that would work in production. And regardless of the state of the tool today, the root issue behind the initial failure was the fact that the team that developed the tool didn't have any communication with the team that was going to use it.

So It's Clear

It's clear—to me, anyway—that software development management requires more rather than less communication. The integrated approach leads to much better synergy and flexibility than the distributed model. The more you understand your customers, the better job you will do as a programmer. That's simply a fact of software life: I can write the most beautiful, elegant architecture ever designed, but if it doesn't make people's lives easier, it's really not a very useful architecture.

Relating All of This to Training

I think this is an essential issue when it comes to training, especially training cross-discipline teams. The title of this article is cross-platform, but really the concepts are even more encompassing. Today, applications can cross platforms, but they can just as easily cross languages on a single platform, or cross operating environments, or even cross architectures. Take a relatively simple application today: a simple storefront. You might have a Java Web application running on a Wintel machine in your DMZ that calls an RPG back-end. This simple application crosses platforms (Intel and System i), operating systems (Windows and i5/OS), languages (Java and RPG), and architectures (J2EE and ILE). And that's just a start.

But with multi-discipline software projects, the client/vendor relationship is not quite as clear-cut as it is in the traditional monolithic software development shop. When we wrote software, we already knew the tools and how they worked; we didn't really need new DDS keywords or additional RPG opcodes. Extending the manufacturing analogy, we took the raw materials and created the finished goods, and we didn't need no stinking vendors. We rarely had to go hat in hand to someone else to ask for something to get our jobs done (except maybe a few more cycles on the old CPU). We designed the system, and you dealt with it.

This has changed. In a cross-discipline application development environment, everybody is interdependent. The browser UI team has to count on the Web application server to be solid, while the Web app team needs the business logic to be in place, and the business logic team has to understand the needs of the UI team. Things get lost in the translation because somebody who works with integers doesn't always understand why someone cares about leading zeros. A UI designer might not understand that the colors red and black have significance on a ledger inquiry and consequently not understand why the application people are upset that positive numbers are now green.

Unfortunately, the software world has become quite splintered, with a whole new generation of programmers insisting that their particular language/platform/architecture is the only way to do things, regardless of the actual business requirements. Even in our own rather sheltered nook, we have the anti-SQL folks and the only-SQL folks, the PHP people and the RPG-CGI people and the J2EE people. Everybody insists that their own particular way to go is not only the right way, but the only way, so getting people to work together in a multi-discipline environment is a challenge, to say the least.

A Novel Idea

So, looking over the past and seeing the issues today, I find myself trying to come up with a way to get people to better understand one another and so to be able to work together better. In a previous article, I discussed making sure we all used common terminology. Today, I am suggesting that all the members of a team share a common experience. For me, sitting on the help desk was probably the single most useful thing I have ever done to make me a better programmer. And in the old days, that made sense because nearly everybody wrote programs that were used by the end users, whether it was a newbie writing simple batch reports or maintenance screens, or the most skilled veteran writing the order entry program.

But in today's multi-discipline world, the consumer of a programmer's output is often another programmer. Job niches exist where a programmer could write for years and never see an actual application user. Because of that, we need to re-think the whole vendor/client relationship and realize that the Java programmer is the RPG programmer's client, and the HTML designer is the Java programmer's client, and so on.

That being the case, the best sort of training I can think of would be to have each programmer go through a tutorial in the languages of the other programmers on the team. I know this is contrarian thinking, especially in today's world of extreme modularization. While the trend in many programming styles today is to simply talk to somebody via the interface documentation, to my mind that contributes to a lack of closeness and an "us vs. them" mentality. Making everybody appreciate how each other's world works, at least to a minor degree, leads to better understanding and even to better communication. Java programmers might not be experts at coding a CHAIN opcode, but if they understand what it is, they'll be that much more likely to be able to understand an RPG programmer talking about a specific issue.

There are limits of course. A pure HTML designer will probably not be able to write a subfile program. At the same time, it wouldn't hurt that designer to sit down with a seasoned RPG programmer and walk through the steps it takes to create a subfile and for that same RPG programmer to watch the HTML person assign the styles to a table. That way, they'd both gain a better understanding of the other's job.

Implementation: The Cross-Discipline Boot Camp

So, what I'd suggest is that, rather than continue down the path of compartmentalization, companies begin to put together a cross-discipline boot camp. The first one would be at the beginning of your next major project. Identify all of the technologies and then create or locate what would effectively be "Hello World" types of programs for each of the technology areas (including cross-technology connections).

You then establish a curriculum for different job roles. UI programmers might go through an intro to green-screens, while Java developers might do some work with basic RPG variable types to understand packed and zoned and dates and so on. Your SQL experts and RPG database folks would sit down together and analyze some programs written in both SQL and ISAM. You could even have one at the beginning of every project that would incorporate old training for the newbies and new training for any new technologies you might be incorporating. And I'm not talking weeks of training; I'm talking just a few days of intense cross-discipline drills designed to make sure that people are at least using the same terminology. It won't turn an SQL bigot into an ISAM aficionado, but at least the two should be able to understand each other's position a little better.

This sounds like a lot of work, I know, but the good news is that a lot of this is already available to you. Heck, if you have WDSC and you're an IBM technology shop using things like Java and WebSphere, WDSC has a wide range of tutorials for most of the technologies required for the whole cross-discipline spectrum (with the notable exception of RPG). But realistically, each shop should have its own specific RPG example programs, since RPG programming styles are pretty widely varied.

So think about setting up a boot camp to teach your teams to work with one another. Don't segregate your Windows development from your System i development; instead, get them better acquainted. You may turn up somebody on your staff who can effectively bridge the gap and come up with new ways to combine the strengths of the various technologies. Because in the end, the role of a computer in business is to give you a competitive advantage, and that requires your whole staff working together.


Joe Pluta

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

Developing Web 2.0 Applications with EGL for IBM i Developing Web 2.0 Applications with EGL for IBM i
Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform.
List Price $39.95

Now On Sale

WDSC: Step by Step WDSC: Step by Step
Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction.
List Price $74.95

Now On Sale

Eclipse: Step by Step Eclipse: Step by Step
Quickly get up to speed and productivity using Eclipse.
List Price $59.00

Now On Sale



Support MC Press Online

$0.00 Raised:

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: