7/28/2007

Waterfall Symptoms

As I stand in a sit down status meeting to listen to another hour long discussion I ponder what is going on to see if I can offer some help. The obvious suggestions have already been ignored: stand up during the meetings; stop designing the system in meetings; stop with all the detail please, just a summary is all I need.

This meeting is a little special though. We have a list of components to be completed before we go live and another list of the outstanding bugs. 20 of one component and 197 of the other. We go live in 6 weeks.

An analyst, that doubles as QA tester, spent their weekend testing but entered bugs like "couldn't test" because of environment problems. The release process is still pretty new and untested.

Our leader asks for QA of a new module and the same dedicated analyst asks for help. There is none, of coarse, just a few extra of their hours in their day. They were allocated to their kids, but they are dedicated folk. Dedicated to their work I mean, can't be dedicated to work and kids on a waterfall project. Laughable.

They mention code freeze, except for bugs of coarse; you understand, can't code freeze code that doesn't work. Laughable.

6 weeks left and now we start raining in scope. Oh wonderful, just in time. Laughable.

QA has no automation so there will be no regression, just wild retesting. They do a great job, work really hard and find lots of bugs. I just wonder how many are missed for the next go around.

The project plan is stored in MS Access, a horrible solution, that few people use. We just code anyway, why should we know what the plan is, we weren't part of its creation, or its revisions. It was presented to us once, I asked some questions about it which had the usual optimistic answers.

Question: "There isn't enough time to complete coding and QA testing before the release date"

Optimism: "Oh, that's ok, they will run in parallel. Each component we finish will go into QA test."

It all sounds so logical. Of coarse, I am an Agile developer, parallel coding and testing are the norm but my Agile projects are setup to support that feat. Waterfall projects aren't, well this project isn't anyway, seems a shame to speak for all falling water.

Of coarse the reality has proved itself over the optimistic plan. It has a way of doing that. The QA regression testing is required and is being attempted. Best of luck to them. They work so hard. They deserve success.

I try to get the ant scripts to release to production. Not to big a job, shame I couldn't get them to work on it 6 months ago. Anyway, I am talking to the tech lead and we have to have this finished by tomorrow. There is a problem with my ant properties so he exclaims that he will manually complete the production deployment so we don't need ant.

"We don't release to production often anyway, so it doesn't matter"

I suggest that the less you deploy the more important the scripts, after all we got dev deployments reliable months ago, and we really want production deployments to work first time every time right?

"Yes, that's right, but we need it by tomorrow. We can try again in two weeks."

He really does have the best intentions. He has been put in a predicament. No production release practice for 10 months, now we have about a week to get it right.

Why does our industry do this to itself? They can't predict where the next problem will be before it arrives. Experience? No, they have lots. Understanding? No they are smart people. They have always done it this way. This is how software projects always work. This is just the life of a software developer. It is all we can expect. Why change.

If it weren't for change,
I couldn't tell that I am standing still.
If it weren't for standing still,
I couldn't tell that the world around me was leaving me behind.

I see what I see with clarity,
I understand what I understand with certainty,
With this clarity of certainty,
I stand and watch and re-affirm my motionless state.

If I stand on the certainty,
That my knowledge is true,
Then my only conclusion must be,
That all that I see is foolish change.

The gulf between knowledge and change, stands in a persons need,
A persons need depends on their situations urgency,
A situations urgency is created by those who don't change,
so the lack of change is our choice, because that has always been our situation.

1 comment:

Anonymous said...

In my opinion, unless one is totally desperate for money, agreeing to work in that type of environment is, in my opinion, not a good work environment.

For example, before taking on this type of job, state the methodology to be used, and form an agreement over that methodology. Define how the team will operate.

Easier said than done. Sounds like a tough assignment. Your very good at what you do, I wish to see you leading agile products rather than stuck in this type of environment.

Steve