Independent Thoughts

In software development and deployment world if the application life-cycle responsibilites are not properly divided and various stages of application share actions from single team the application management becomes hard and the software itself can be seen with full of bugs and patches. The cost of maitaining application grows overtime thus reducing productivity and missing oppurtunities for newer application as most resources are busy in managing current ones.

This scenarios is found is mid-scale companies where the resources are less and anticipated scope of the application is long. Indirectly it affects the internals of the company to produce more software and services and causing horizontal graph line always struggling to rise high.

Lets review an example
Company XYZ had a project launch meeting with total of 3 team members consisting , project manager and 2 developers. The company recently higher 2 top notch developers who had a whole lot to contribute to writing codes and making application work. The deadline for compeletion is within 2 months. The first month and half are exprienced very smooth and the development is on schedule. The last weeks (week 7 and 8 ) the initial deployment is done on staging systems and to run pilots. The deployment is performed by the developers who write the code. These 2 weeks are also considered to be a bug fixing and minor enhancement period and the disaster starts here and following things start happeneing

1:- Minor configurations are performed on the fly and sometimes missed and do fail to become part of documentation as developers have always editted the files directly in development and staging systems.

2:- Bugs are now fixed in developoment environment and staging environment manually as developers are lazy to go through the deployment cycle again and that causes reconfiguration issues which were done in point 1 , but again have to be done

3:- Last minute minor requirements changes gets in on development and deployment at the same time but without any proper testing.

At the end of 8 weeks system is handed over to QC, QC is satified and now the deployment is done again by developers simply due to the lack of proper deployment team.resoruce.

In the above situaiton , notice that there is constant lack of deployment proceedures and SDLC rules are handled by development team and once the software is in production the same development team also starts supporting it live. In that case the following happens

1:- Fixes are done on the fly in production to keep the system running and often those fixes do not make into the development and next deployment again breaks those.
2:- Most of the fixes start by-passing QC as QC returns the software back to development team for deployment, development team always filled with confidence deploys the code from their current stage thus the software which ends up in production has actually by passed QC.
3:- Every deployment configuration issues are taken care on the fly thus adding to deployment time.

In overall the software has now taken a long highway to its disaster by just laking of proper deployment team and being dependent on development team, thus consuming most of the development staffs time in managing the production and focus on enhancements and new software possibility explorations.

If the company had take a step ahead and had drawn a line between production and development by adding a proper deployment proceedure and seperate chain of responibility, the management and expansion of the software would have been much easier.