Developer

Five ways to close the rift between engineers and developers

Still trying to get your developers and engineers to see eye-to-eye? Tim Landgrave recommends five ways that businesses can improve the relationship between these two groups.


Still trying to find ways to create some high-tech harmony between your developers and your engineers?

In this article, we will consider organizational and structural remedies that, by their nature, will require some effort to implement. But the payback will be a stronger technical component for your business—and more effective development and engineering teams.
Last week in “Help your developers and engineers work together,” we started the discussion of how to provide an environment that allows your engineering and development teams to work together to create supportable, scalable platforms for your applications.
Five ways to get your technical team focused on the same platforms
  1. The most important task you can perform is defining the core technologies supported in each deployment platform.

If you have applications using Windows NT, Windows 2000, and Sun Solaris, then do the work to document the operating system release levels, database and transaction services products and release levels, hardware requirements, etc. Next, document a procedure for extending the platforms that includes identification and resolution of operations, scaling, fault tolerance, testing, and other key issues.

The definition of deployment platforms should include your external Web farm, your authentication platforms, your mail or groupware platform, your line of business or financials platform as well as your data warehousing and analysis platform. Identify in advance any dependencies between the platforms that would cause applications to cease functioning properly if one side is updated.
  1. Identify and standardize on a development methodology that includes operations as a key member of the application design team.

This will ensure that applications developed are deployable, supportable, and affordable. It will also provide a mechanism for identifying which key technologies need to be integrated in the operations platform(s) going forward. It’s a common mistake to allow developers to create their applications without regard for the cost and complexity of deploying and supporting them.
  1. Add a development team to the operations group that assumes responsibility for documenting proper programming procedures for the existing platform. This team will also document basic programmability and best practices for any technologies added to the operations platform (e.g. Streaming Media Services).

If you don’t have a specific methodology for how features will be added to the supported platform(s), then developers will feel justified in adding them without asking. You’ll also get more support from the development group if they know that there are real developers involved in the decision and documentation of new platform features.
  1. Part of the initial training for new development and engineering employees should includecross training in each other’s departments.

Developers should participate in the configuration, deployment, and support of an application. For example, an engineer could take a basic HTML course and participate in the presentation services development for a new application.

Allowing each group to see what the other does on a daily basis will give them a deeper appreciation for each other.
  1. If you don’t have one already, then you need to create a new Quality Assurance (QA) group that sits between the development and engineering teams.

This new group can either be a physically separate group or could be a virtual team composed of representatives from both teams. Its function is to provide testing and support of new applications before deployment.

Instead of starting the testing process when the application has been completed (which is generally too late to make significant architectural changes), testing would start at the design phase and continue through deployment.

This ensures that products under development will work on the deployed platforms and will also give developers and engineers time to modify their applications or update the platform to support an upcoming business need. QA should also develop support plans and escalation procedures that will be turned over to operations and the help desk once the new system is released to production.

If you really want to make this work, you’ll have to enforce a hard and fast rule: “No application may be released to production unless approved by the QA team.”

The benefits
Even if you agree that these recommendations make sense, you’re likely to fight an uphill battle to get them implemented. In addition to the usual “but we’ve always done it this way” rhetoric, you also will have to deal with the cost of implementing the changes. When selling this to your company, you should focus on the benefits. These include:
  • Faster application development and deployment. If your platforms are well documented and your people are trained to use them, then you can create and deploy new applications much faster.
  • Easier future migration to new platforms as technology improves. With a fully documented platform and updating process, you can introduce new technologies without fear of destabilizing the existing applications.
  • Increased employee satisfaction. All technical people have one thing in common—they love to learn. If your company is seen as having a learning environment, then you will increase retention.
  • More reuse of existing systems. By documenting the system and its interfaces, you make the process of sharing objects between systems possible. This ultimately results in significantly reduced development costs through both reuse and the elimination of developing duplicate systems.
What have you done in your business to get engineers and developers to cooperate? Post a comment below or send us an e-mail.

Editor's Picks