Pencils Down

We have all been on projects where management decides to change resources, time and/or features of an ongoing project.  The old chestnut used to be these are the 3 things you have control over, pick 1.

Thinking about this I looked at what would need to happen if we changed one variable:

• If you reduced Resources then you would need more Time or less Features
• If you reduced Time then you would need more Resources or less Features
• If you increased Features then you would need more Time or more Resources

But thinking about this, changes in Resources usually make no difference in the short term.  Adding another developer does very little until the developer comes up to speed.  Depending on their expertise this can take a while.  So, what if we treated Resources as a constant?

We end up with a relationship like: Resources = Features over Time (R = F/T).  Sounds really pretty nice.  Kind of makes sense.  Can be looked at as a productivity measures, quality measure, etc… as well.  Again you don’t expect the productivity of your team or their quality level to change much in the short term.  Walking through the cases above we get relationships to still work.

I think this is a nice clear mathematical argument even the most demanding manager can understand.  Oh, you want to increase Features this late in the project.  That means we need more Time – see here…  Yes, we can increase our productivity, but not in the short term (phase) of this project.

We bought a Sony World Tour game for someone this Christmas.  This is one of the most popular games this past season.  Typical out of stock problems for a popular seasonal item.

It never worked.  Tried replacing various components about 6 times.  Finally returned the whole thing to the store.

At the store one of the clerks mentioned, “Oh, yeah.  Those don’t work a lot.  Be thankful you didn’t buy an XBOX.”

This prompted my curiosity, “What do you mean?”

The clerk said, “Oh, the XBOX’s fail about 75% of the time”.

Being in software I was a little flabbergasted.  “How can that be?  These are extremely popular items; that YOU sell.”

“I just work here.”  Realized he had revealed too much and proceeded to hush up for the rest of the transaction.

Being in commercial software I have lived through the horrors of bugs in software that persist well past the FCS date.  Some of these can be fatal, most are doggedly consistent errors in logic that just mess things up.

Maybe I am being stuck up, but the game software DOES NOT START!  This is not even close to an FCS quality level.

Do game software writers not work in the same realm as the rest of their brethren?  Are they immune from the QA/QC police?  Management/marketing breathing over your shoulders about typos and nits they found over the weekend?  Heaven forbid your application does not start, boot, begin correctly for them in whatever strange configuration they manage in their household.

The more you think you understand something the less you actually know.

For one of my clients a certain feature was broken that had been working fine for months.  My initial reaction was that the front-end changed.  Upon testing I tracked it down to a session variable no longer being set during login.  It turns out in the conversion from username/password to SSO a number of session variables were no longer being set.

For another situation a database job that had been running for some time on the first of the month apparently stopped working.  Upon investigation, the job had been completely removed from the system.  This was done when another client’s data was moved onto the database server.

In both cases New things, that are good ideas, were implemented in such a slipshod manner that existing, functional aspects were trashed.

Thinking about this some it seems like this is a very common occurrence: the developer of the New thing has the priority of getting the New thing done.  Old things take a distant second in anyones mind – developer, pm, client – anyone.

I know you can use a regression test suite to verify you didn’t break something, but this is an afterthought.  It is not in the developer’s frame of mind to determine what else might be affected by the New thing.  From my own experience if you happen to think of side effects you get looked at with squinted eye, not a team player, naysayer, problem child.

Further, fixing the broken Old thing after the fact is also looked at as a good thing.  “Yes, we fixed the Old thing.  It turns out the New thing broke it.”  Everyone is happy that the Old thing got fixed.  No one asks why this wasn’t discovered beforehand.

You can see this on software developer web sites.  Everyone can develop something New for you.  Or even more interesting they can debug your code or evaluate your system performance.  No one is advertising they will maintain your current system.  System maintenance is not valued.

Maybe this is just a trickle-down of the quarterly hockey stick affect working into how things get coded.  Imagine that, developers modeling their behavior after sales people.