Can’t developers and engineers just get along? Is this a familiar lament in your organization? I’ve spent the last couple of weeks talking with CIOs about the recent developer series published here on TechRepublic (see below), and it’s becoming one of the most common questions.
What’s causing the friction? What are some educational and structural remedies that may help? Here are some answers and suggestions for dealing with the problems between engineers and developers.
What’s the big deal, anyway?
The ability for your development and engineering teams to work together will ultimately determine the number of disparate platforms you have to support and the robustness of the applications you can develop. Why? In most organizations, the engineering team is charged with creating and maintaining a data center environment in which all applications (packaged, internally developed, or hybrid) can run successfully. The development team, on the other hand, is responsible for integrating packaged applications, developing new ones, and providing a mechanism for installed applications to share information. Unfortunately, the line between the two sides is becoming less distinct every day.
Who’s responsible for developing test scripts for applications? Who tests load balancing and scalability? Who writes installation routines for desktops? For file servers? For application servers? Who decides what new features get added to the supported platforms? If these questions go unanswered, then you’re virtually guaranteed to have a hodgepodge of systems with limited support and standardization.
In part 1, Tim Landgrave discusses some of the sticking points between engineers and developers and the training you can use to help them work together. Next week, he’ll cover some of the structural and organizational changes you can make to foster more cooperation.
What’s behind the problem? First of all, developers and engineers have different goals. While developers want to be creative, engineers need to keep the existing platform running.
Running on “Internet time” doesn’t help the situation either. We’re challenging developers to have “start-up” mode thinking, but most developers (especially those who grew up in the PC development world) aren’t cognizant of the issues involved in maintaining a large-scale production environment.
There’s another interesting issue here between generations of developers. PC-desktop and client-server developers, who know the visual languages and can hack together a solution quickly, tend to look down their noses at their colleagues with mainframe backgrounds. But the tables are beginning to turn. I’m finding that developers who already understand concepts like transactions, queuing, and limited bandwidth (can you say “CICS, MQ, and Terminal?”) actually become productive in an n-tier environment faster than those “GUI-trained, snot-nosed hacks” (as one old-timer so eloquently put it).
If you want to read more about the developer shortage, hiring and retaining good developers in your enterprise, or building your development team, check out these recent TechRepublic articles by Tim Landgrave:
- “The IT job shortage: The developer and the enterprise”
- “How to organize your development team to ensure success”
- “How to build and retain great developers”
- “Beyond the want ads: Creative ways to hire developers”
- “Better ways to retain your developers”
What’s your platform?
Another issue is the developer’s tendency to introduce new technologies without consideration for whether the products required for deployment are a supported part of the currently installed platform. In fact, many of the developers I spoke to couldn’t tell me what platforms were currently supported. They were just happy to keep installing new service packs and versions and watching their operations staff jump through hoops to get their applications running.
By not defining and publicizing supported platforms, the engineering group not only limits their ability to run applications on a single platform, but they also virtually eliminate the option of creating applications that share data or objects across platforms. So the utilization of cross-platform functionality (for example, sharing code or functions between UNIX/EJB to/from Windows/COM+) is minimal. It also limits the level of technical capability of the developers and engineering staffs.
It’s not that anyone doubts the technical capability of their engineering and operations staff(s). It’s just that while most engineers in this new environment have the knowledge to create robust solutions, they don’t have the knowledge or experience to create test and implementation plans that guarantee smooth conversions and deployments. Without the benefit of standard platforms, these plans have no chance of succeeding anyway. Thus begins the death spiral that most companies end up dealing with by throwing everything out and starting over with a new platform. What can you do today to move toward fixing the problem? One of the potential remedies lies in education.
The first step towards working together?
The first question you have to answer in order to get your developers and engineers working together is, “What should everyone know about the platforms your organization supports?” At the very least, both groups should have a common lexicon.
In order to accomplish this, I recommend that the operations staff and the developers take courses that focus on common principles across platforms (e.g. transactions, message queuing, scalability, fault tolerance). If you can’t find courses that you like externally, then consider developing them yourself and presenting them using your own engineering and development staffs. This will save you money and build camaraderie among your technical team.
After covering common topics, focus on the specific platform implementations that you support. Don’t be afraid of having developers of disparate platforms learn the fundamentals of other platforms. If you need to develop applications that use the features of Windows/COM+ and UNIX/EJB, then your developers and engineers need to understand the basics of both platforms.
You should also develop a “Core Services” course and associated documentation that outlines the basic capabilities exposed in your supported platforms. This training should first address product and release levels for all included hardware, firmware, and software and define APIs, and sample code to access platform features in your environment, then cover best practices for using the services.
These courses can be based on platforms-specific curriculum (e.g. Microsoft or Oracle certified training courses) but modified to reflect the implementation of your core services. They should also include basic philosophies and common practices such as security, service placement (DMZ vs. Internal servers, data vs. business vs. presentation tiers), and legal issues regarding content designated for external access.
In addition to these fundamental training issues, you may need to make organizational decisions in order to ensure your success.
What do you do in your business to keep both developers and engineers working well together? Is friction between the two groups inevitable? Post a comment below or send us an e-mail .