Side Effects May Include...

Software development is complex. A lot of communication is needed to coordinate with users and between teams to synchronize efforts. On large teams developing distributed systems, effective communication is exponentially harder. In addition to the users and development teams, you also need to deal with system admins, DBAs, network, and change control specialists.

In many environments, this later group of people (the system admins, DBAs, etc.) do not get involved with the project until late stages. The development team might have free reign over development databases for instance, but when the code migrates to a certification environment things are suddenly very different. Teams move from surroundings where they have total control of machine settings, databases, and resources to an environment where they have none.

Often, during the migration to a test or production environment things are often "forgotten". Things that often don't make it into an application's change control system.... database schema updates, new environment settings, property file changes. If these changes are not documented for migration to production, it's a disaster resulting in an embarrassing mad scramble to remember and apply these changes on deployment day. No one feels good after backing out a bad production roll out of a system.

The knee jerk reaction when something like this goes wrong is to add more process - more forms, more user sign offs, an increase in role based access to systems. This seldom however fixes the problem - it just adds more overhead to getting the problem fixed once these problems rear their ugly heads again.

What's really needed is a better process through automation, not more process. Automate testing of the system. Create batch files to apply schema updates, change environment variables, deploy the application, and test in a single step. Use this script in your test environment and run the same script when you migrate to production.

All the time we try to sell the business on automating their processes through the programs we write. It always baffles me that, as software developers, we seldom take our own advice.

Comments

Popular posts from this blog

I Believe...

FRail :include

Performance Tuning JCAPS - Part 2