I spent far too many hours this week in meetings about how the software development process can be maniuplated or shortcut (read: ignored) to meet some arbitary date.

This scenerio starts about a month ago when a critical issue in an application is identified.  The issue was escallated as a data corruption problem and that it needed to be fixed immediatly to be able to service a major client.  My team jumped on the issue, worked to find the causes and implement a solution.  The problem turned out to be an AJAX related UI problem and not a serious data corruption issue.  A workaround was also identified and apparently used while the fix was implemented and tested.

We turned around the fix, QA testing and a release in about 3 weeks working nights and weekends.  After the release we had to retest a previous build after merging in the emergency fixes.  We completed this on time and are ready for the originally scheduled release date.

Now we turn our attention to the next effort.  The next business day after the above items were delivered the hammering about the next effort begins.  It starts out with "We need a schedule by the 3pm meeting!" which is only 3 hours away.  The main problem with producing the schedule was that the 2 weeks of planning and confirming scope we were going to have available to us was consumed by the emergency.

This past week everyone seems to have forgotten about what the team spent the past month working on dispite the daily updates and bi-weekly status reports.

The result of the meetings this week was that extensive overtime would be required an expected to meet a deadline that someone outside of the software team made up and committed to.  I'm sure said individuals will not be the ones working nights and weekends away from their families.

On top of this they are terrified of showing the client what has been built until it is imposisble to make changes with out impacting the release date.  This cuts against agile development and my personal best practices.

I hope that someday I get to work for an organization that embraces modern software practices and puts building quality software above politics and feelings.  An environment where software productivity is measured by delivery rather then the number of hours would be a big plus.

AuthorSam Butterworth