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.