3 Rules to Avoid Problems due to Changes in Development

A software development company can be impacted when trying to modernize their development tools or environment - improper verification can lead to incompatibility with the code, a lot of lost time and energy and a whole lot of headaches for the teams and managers. Here is an analysis and mitigation recommendations how to avoid such a situation:

Example scenario:
Democorp is producing an ERP application written in Java, and running under the Tomcat application server.
The head of ERP development read about the improvements in the new Tomcat version 6, and instructed his core team to adopt this version for further development. Even though there were complaints from the team, everyone started the shift.

It takes 2 days to shift from version. 5.01 to 6, since the Tomcat's structure has changed. In the end, one of the lead programmers attempted to compile the application 3 times, simulating a boundary scenario of Democorp's customers.
The application run out of memory on a 8GB server. After 1.5 days of attempts by the core team, one of the programmers finds an entry in the forums that Tomcat 6 causes a memory leak in a library that Democorp uses in their ERP application.
After this, one member of the team is tasked with testing and correcting the problem, while the others are reverting back to Tomcat 5.01, which takes another 2 days.

Due to an unconfirmed idea by the head of development, the core team of 7 people lost 6 days - 42 man-days on attempting to migrate development platform to a new version.
At the end of the day, one person was dedicated to testing before further rollout - a solution that should have been used from the start.

Conclusions and Recommendations
This was a poor management move of the head of development - with all the new features available, his priority still should have been maximal efficiency of the team.
To avoid these situations and achieve maximum productivity during change in tools or technology, you should observe the following rules:

  • Treat the development tools as trusted - These are the tools you use to produce production grade code. Never change tools or environment in development simply because it's nice - test everything
  • Perform risk analysis - Consult all other teams and perform a risk analysis of all possible impacts of the change. There can always be something you overlook that impacts the other teams.
  • Make a phased introduction - even after everything is tested, don't make a big bang change. Have one or a small number of people within each team adopt the change and work with it, to weed out possible overlooked problems
Related posts

Information Risks when Branching Software Versions

3 rules to keep attention to detail in Software Development

8 Golden Rules of Change Management

Application security - too much function brings problems

Security risks and measures in software development

Security challenges in software development

Talckback and comments are most welcome

No comments:

Designed by Posicionamiento Web