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.

New Knowledge vs Productivity

Update: 08/22/2007: add references to J curve

I can get task X done using knowledge I already have. I would take longer if I used a technique that I don't currently know.

However, if I learned a new technique I might complete task Y so fast that the slowdown on task X is insignificant.

This is the balance of the J curve. The J idea proposes that your productivity remains flat until you learn something new. At the beginning of your learning your productivity decreases until your skills are sufficient to surpass your original productivity.

The amount we produce is related to our current position on the J's learning curve and the number of J's in our past.

So, worst case, you could imagine living on the downward slant of the J forever. There is always something new to learn after all, why produce when you can learn. I guess pure research organizations work like this.

The other worst case, is never entering the J. Living your life with a static set of knowledge.

OK, so how often should we dive into the J?

Life needs to exist,
In a rising J,
With every day,
Finding another rise.

If the bad poetry doesn't make sense then consider learning 5 things at once and every day push one of your tracks past the base of the curve.

Growth ends with the belief that you will be less productive by learning.

Do something new today, even if it hurts. Oh, and it will hurt.


Meilir Page-Jones: The Productivity Curve

Gerry Weinberg: quoted as part of his pinball analog

Amazing Image Integration

This movie has been around since May but I just found it and just in
case others havn't seen it, here it is.


The future of connected imagery is here.



Yes, I am now sending tweets. Not sure why but it appears to be addicting.

Twitter is another social network but is far more focused in its goals. It just asks "What are you doing" and with frequent updates you end up with a general idea of what your friends are doing.

Perhaps this is just too much information and no one really cares but I think that is what it is all about. Why does and now much will they be able to pay?

With a simple beginning there are now addons to the twitter service like a search of all the things that people are doing and, my personal favorite mashup, TwitterVision which merges the posts with the geo locations of the poster and swoops you around the world from language to language and irrelevant activity to irrelevant activity.

But don't count this thing out yet. Check out my personal twitter vision. There are many times that we need to keep track of things. Oh, did we think this was limited to people? When are you going to get that new watch that will tweet so you never loose it. Should FedEx make their packages tweet? It's just a 140 character piece of text but twitter vision encodes ":L[position]" into it as a really simple way to track things.

FexEx, of course, built their own package tracking system back in the days when web services were new and SOA was a Canadian SO. If the task was started again today would they have chosen to leverage existing web services.

Each web service we build we examine granularity as an architectural problem. Perhaps the success of twitter indicates we should stop examining and just think smaller.

Who knows perhaps your next watch will make a request for the time somewhere.

Visual Studio 2005 and ReSharper

I have used ReSharper with VS 03 in the past but decided to try the new VS 05 features before installing the new ReSharper version. After fighting with the stupid stupid VS features my course is clear.

ReSharper is to C# what Eclipse is to Java. A rebirth.