Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Transition Issues
Let's examine some of the issues that arise when transitioning developers to new application architectures, programming languages, or development methodologies.
Mainframe to Client/Server
During the 1990s, many development organizations made the transition from mainframe development to client/server development. Here are some of the lessons learned from these organizations:
Mainframe developers generally have acquired much better data center operations disciplines than have their client/server brethren. Make sure that these disciplines are not lost when transitioning to a client/server environment. A portion of an application may run on a distributed end-user desktop rather than in a glass house data center, but the same application testing, version and baseline control, error-checking and recovery, and security needs to be built into enterprise-wide applications, regardless of where they ultimately execute. Developers who grew up in the client/server world developing engineering or personal productivity applications where a software error affected only one or a few users—versus hundreds or thousands—tend to lack some of the mainframe development disciplines mentioned above.
Client/server developers often are accustomed to operating with greater flexibility, allowing them to respond to new customer requirements in a more timely fashion. Part of this is because they don't always carry out all the mainframe disciplines mentioned in the point above. Another part is the fact that client/server development tools and environments often afford better productivity. The challenge in a transition from mainframe to client/server is to combine the best of both environments.
When transitioning a developer organization, be sure to get everyone involved. This means the developers, of course, but also the system administrators, database administrators—even the office administrators and the receptionist. Even those not only directly involved in a transition of skills should be aware of the transition and clearly understand the business reasons that are driving the change to the new technology.
Most organizations transitioning to a new client/server development environment don't get rid of their mainframes—at least not on day one. This means that mainframe developer experience will remain an important skill in order to continue maintenance of legacy mainframes. There is no better way to develop a mainframe–to–client/server interface than to have the developer who wrote the original mainframe application on your client/server team.
Mainframe to Web-Centric
Since web-centric software development is newer than client/server, there have been fewer examples of this type of transition to study. In general, all the points discussed for mainframe–to–client/server transitions above hold true. Here is an additional point to consider for this type of transition:
Many software experts have commented that web-centric software applications really hark back to the mainframe days, as now both data and applications are be in re-centralized into larger servers. The water is further muddied as IBM and others release Java virtual machines, web server software, and other web-centric applications that allow actual implementation of web-centric design on a mainframe. Independent of hardware platform, however, the software architectures used on traditional mainframe applications and web-centric applications remain entirely different. Don't think that your mainframe development staff can become instant web-centric experts simply by purchasing a web server for your mainframe.
Client/Server to Web-Centric
The transition from client/server to web-centric application development is much easier than either of the two previously discussed transitions. As with the transition from mainframe to web-centric, it's still too early to draw many specific conclusions regarding the transition from client/server to web-centric in large IT organizations, but following is an interesting observation:
Web-centric applications tend to start small, with stand-alone prototypes or simple pilots. Many web-centric applications make software packages, operating systems, or hardware choices early on that are inherently non-scalable. As the web-centric software marketplace is still immature, it's easy to write off lack of scalability with the comment that it will get better in the next release. Unfortunately, by their very nature web-centric applications are often deployed in environments in which user load is the hardest to judge and scalability is more important than ever. In mainframe or client/server architecture, the application developer typically has a fairly good idea of what types of loads will be placed against the system. On the Internet, a web-centric application can go from 100 to 1 million users virtually overnight. Scalability at the software, hardware, and operating system levels should be of utmost importance in any web-centric application.
Procedural to Object-Oriented
Transitioning a developer from a procedural to an object-oriented environment is both difficult and time-consuming. This doesn't mean that it can't or shouldn't be done; it just means that you'll need a lot of patience. Managers often underestimate the time required to make this transition because learning the syntax of an object-oriented language can be a simple task. But truly understanding object-oriented technologies and becoming a skilled object-oriented designer are much harder tasks. When developers are simply taught an object-oriented language without learning object-oriented technologies, some problems occur:
Without a strong foundation in object-oriented design technologies, developers often may not see the real advantages of object-oriented programming and will revert to their level of comfort. For instance, you can write a C++ program that uses absolutely no C++ unique language features, and in fact compiles correctly with a standard C compiler. After a short course in C++, many FORTRAN programmers can program in C++. All too often, however, their C++ coding structures look surprisingly like FORTRAN, complete with liberal use of goto statements and a lack of classes.
In some cases, developers learn object-oriented design, but senior software architects continue to design in a procedural model. One possible result is that low-level design details that are implemented in an object-oriented fashion, but overall the application behaves very much like a procedural program.
Language-Specific Transition Issues
While it's more common in scientific programming groups than in commercial IT organizations, many developers have transitioned from FORTRAN programming to C programming. Without a doubt, the hardest concept for a FORTRAN programmer just starting out in C is pointers. C provides a tremendous amount of programmer flexibility in its ability to use pointers. As in the case of transition from procedural to object-oriented programming, some FORTRAN programmers learn C and are very happy to program away without ever utilizing the C pointer facilities.
Perhaps more common in commercial IT organizations is to find developers who transitioned from COBOL programming to C programming. Like the FORTRAN–to–C transition, this is a major change. There are typically many more ways to write a code fragment in C than there are to write the code implementing the same functionality in COBOL. A C programmer may describe this as flexibility, but the COBOL programmer may define it as "more ways to make an error."
One of the simplest language transitions to make is from C++ programming to Java programming. The Java language reduces the complexity of C++ while remaining instantly familiar. While Java syntax is similar to C++, the Java language doesn't use the concept of pointers. Instead, true object handles reference all objects. In addition, some of the more complicated object-oriented features of C++, such as implementation inheritance and templates, have been removed from the Java language. Java's rich set of application programming interfaces (APIs) also provides programmers with a wide range of predefined extensions to the language.
The transition from C to Java programming is only slightly more difficult than from C++ to Java. As there are no stand-alone functions in the Java language, all application functionality must be implemented as methods within a class. This at least forces the programmer to start thinking about object-oriented design. By contrast, as previously mentioned, a C programmer could start writing code verbatim in C++, without ever using classes, methods, or any other object-oriented structure.