Developers’ take away from a support project

Developers usually tend to prefer development projects over production support projects. Developers always want new challenges in terms of technology and would like to be using the latest tech tools and platforms. As most development projects offer them this advantage, they usually prefer to get away from production support projects.  But in reality, the production support projects do offer them certain key benefits, which are very much required as they move up in their career path. Let us examine some of these here.

The real life business scenarios

A software project begins with perceived business requirements as drafted by the Business Analysts and approved by customers. In most cases, the requirements are far from complete and that leads the developers to live with ambiguity giving room for more defects in the product that they develop. How much ever the software is tested, when it hits the production use, the real life business scenarios will for sure throw the software out of gear and makes it fail. Thus, those involved in the support projects get the opportunity to deal with production business scenarios which will sharpen their business / domain knowledge. Given that the world has started embracing the cloud and SaaS applications, there will be less of development and more of customization and managing the configurations. That means that the need for domain skills with the developers will rank very high amongst the SaaS providers and consumers.

Better product / domain knowledge

In product development, it is quite possible that a developer or a team of developers would be working on just a small part of a product. That means, the developers associated with development projects have very little opportunity to have complete understanding of the product. Whereas the developers involved in the production support would get opportunities to work with all parts of the product and some times across other products too. They get better visibility on the operating processes / practices associated with a use case, there by getting a better product / domain knowledge.

Solution design skill

Developers tend to believe that support projects do not have much opportunity in the solution design space, which is a myth. A production defect is far more difficult to deal with than a defect identified during the development life cycle. Resolution of a production defect involves at a high level the following steps:

• Quickly come up with a data fix to maintain the data integrity if impacted by the defect.
• Perform a root-cause analysis and come up with the real life scenarios that could lead to this defect being encountered.
• Come up with an interim work around if any available to prevent it from recurring in the shorter term.
• Identify a best solution to prevent it from recurring – This is rather challenging as the solution has to be designed within the existing product architecture, with lesser efforts and least impact to the already working software.

Each of the steps when done well in combination with the real life scenarios add tremendous value to the abilities of the developers and that will lead them towards software or solution architects. Solutions in support project see production quicker than the development projects and as such high appreciation from business teams. 

Code Re-factoring

Learning from one’s own mistake is a good way of learning. But, learning from other’s mistake is a smart way of learning. Every time a developer attempts to resolve a production defect, he might be looking into the code written by someone else and may come across many different ways of achieving a result. Taking it positively, a support developer may enjoy reading through the code written by others and pick up some better algorithms and at the same time, how not to write codes. This will for sure better their coding abilities.

The developers in the supporting a production instance of a software product will realize how important the readability of the code is and hopefully they will be making it their habits to write readable code with appropriate comments and indents.

Trouble shooting expertise

Usually software products are moved to production environment after atleast three levels of testing. A defect in production means that it has slipped through all the testing phases during development. So the scenario under which this comes to surface is not something that has been visualized during the development phases. Some of such defects would be very difficult to reproduce without which resolving it would be a nightmare. Those involved in support projects would quite often exposed to such scenarios and they will over a period gain good trouble shooting expertise. Read one of my other blog on Debugging performance problems.

Collaboration with other teams

During development phase, a software developer would be looking up to his lead for any clarifications on the work that is assigned to him and would not get exposed to other teams. Whereas, those involved in production support get to work with various other teams like the infrastructure, IT security, subject matter experts, quality assurance, business analysts, end users, third party vendors when any of their components are used, etc. This collaboration and interaction brings room for acquiring some additional skills both in technical space and also on the soft skill space.

Conclusion

Being in production, support projects facilitates the enterprise to perform its operations and earn profits on an ongoing basis. They play a vital part in the business continuity of the enterprise. As long as a production software is well supported and maintained, the IT heads would not think of replacing it unless a major technology overhaul is expected.

Of course, there are certain downsides of being support projects too. For instance, one may have to be on call to support any emergency and some times, a hard to crack defect could result in tremendous pressure and stress. 

The skills that transform an IT Manager to an IT Architect

One of a typical question that an aspiring architect has to answer in the hiring interview is “how in your opinion an architect is different from an IT Manager?” Even I have been in the asking side, on many occasions and have not been getting convincing answers from many. This is very typical as in most organizations, even if one is titled as Architect, he or she end up managing IT as against Architecting IT. Let us attempt to compare and contrast the skills that these roles demand. Please note this is not an attempt to make out a complete list of skills of these roles.

1.       The Engagement

The Architect’s engagement starts with identification of a business pain point. At times, it would be the Architect who should spot the pain points and propose remedies. On the other hand the IT Manager is engaged the moment a project has been scoped and is ready for execution and implementation.  The engagement of an Architect starts with the challenge of making a business case (of course with the help of fellow architects specializing on specific areas) to the stake holders with appropriate quantified projections that lead to a positive RoI. When this task is done well, the projects that get shelved mid course would come down considerably.

2.       Big Picture thinking

The Architect has to be the one who can visualize the big picture of any given problem or a possible solution in line with the enterprise’s long and short term goals, the anticipated business growth and the technology trends in the related area. This visualization would help the Architects to appropriately prioritize the various initiatives and to draw out the short term and long term road maps. The big picture visualization is an integral part of the IT strategy lifecycle of the enterprise to determine the future state and plan for the transformations from current state to future state. On the other hand, the IT Manager is engaged only in the transformation tasks and there by leading the organization to the future state.

Some of the aspiring architects, when asked how would they do the capacity planning, their response was based on a pinned down Statement of Work, which in case of architect engagement would not exist and they could not think of a situation where they would be designing a solution with absolutely no requirements on hand.

3.       Project Execution

The IT managers will have teams to execute, implement and manage various projects, whereas, the Architect would be playing an independent and in most cases individual contributors. The Architects have to be with the project execution teams and help the teams by bringing in course corrections whenever they deviate from the intended plan. This role requires the Architect to possess hands on ability in the related technology, so as to hand hold the project teams during execution. The IT Managers on the other hand may not be required to do this and instead he would simply co-ordinate the engagement of Architects with the teams.

4.       Risk Management

While Risk management is essential in IT management life cycle, performing it early on adds huge value to the solution execution as it helps better decision making in terms of resource planning, training needs and of course will bring in the ability to remedy the risk. That is the challenge an Architect has to face in identifying all potential risks that the solution may lead to. IT managers also face challenges in risk management, but it will be a lot easier as many things would have gained concrete shape with less ambiguity.

5.       Staying on top of the trends

The IT Managers are not normally pressed to stay on top of the technology trends and it would be enough for them to stay on top of the technology that is mature enough and has good industry adoption. The Architect on the other hand has to stay on top of the trends and that would help him in measuring the longevity of the proposed initiative or solution. It also important for the Architect to have a good grasp of industry predictions and analysis and should have the ability to choose the less risky path to lead the enterprise to the future state.