What to say?

[chef]

Problem: Due to a bad installation (not made by me) part of the system is corrupt on the dev environment. A change needs to be made to that part of the system but the developers are concerned that we will migrate the corruption throughout Test and Production environments. Fixing the corruption is a large scale task that cannot be completed in a short period, an upcoming upgrade (Q1 2012) to the entire system will definitely fix the problem and therefore contract extended while I do the upgrade (kerrching). the problem is with this change due to go into a release mid December.

Options I gave the business were:

1) Migrate the change anyway (and therefore the corruption), it all seems to work but you would be migrating a known corrupted part of the system.
2) Hack around a short term fix for the corruption and add a lot of testing time to the change to ensure the hack works.
3) As the change was originally labelled as minor then remove the change from the release until the upgrade has taken place.

I recommended 3.

Business came back with
"You seem to have missed a fairly obvious option can't you simpy develop the change directly onto the production environment when you migrate everything else?"

My answer "yes, but that really isn't very professional developing directly to a live prod environment"

Their reply "Well what are the risks?"

Words fail me at this point, help? what can I possibly say in reply while maintaining a professional attitude?

[Pondlife]

Ask them what they think about the idea of making changes to aircraft systems whilst the plane is flying with them as a passenger.

[doodab]

Is it an option to reverse migrate the uncorrupted stuff from test or prod onto your dev server?

[d000hg]

If it's a really minor thing, operating directly on prod is an option unless it's some super-important system. The plane analogy doesn't fly () because a)you have backups and can make changes to correct after b)they DO make changes to a flying plane when something goes wrong

[chef]

Is it an option to reverse migrate the uncorrupted stuff from test or prod onto your dev server?

No, when we try to do that the import fails due to the corrupted field, as you know more about what I do, the form is the main Helpdesk form and the field is the main diary field of this form.

The hack around suggested was to export all data, remove the field, recreate the field and re-import all data.

[doodab]

As regards why you shouldn't do what they are suggesting, they clearly don't understand it's bad practice so you need to explain to them why it's considered bad practice.

You'll be developing and releasing untested code into production, jeopardising the production environment

It presents a risk to the entire release if the development can't be completed in the available window and the release has to be rolled back

Your various environments will end up even more out of sync, creating more work to fix

You will end up having to do the development twice. Once on prod and again on development post upgrade.

[doodab]

No, when we try to do that the import fails due to the corrupted field, as you know more about what I do, the form is the main Helpdesk form and the field is the main diary field of this form.

The hack around suggested was to export all data, remove the field, recreate the field and re-import all data.

Hmm. Seems quite likely this will be required before you do the version upgrade anyway. What is the error you are getting? What backend database are you on?

[chef]

If it's a really minor thing, operating directly on prod is an option unless it's some super-important system. The plane analogy doesn't fly () because a)you have backups and can make changes to correct after b)they DO make changes to a flying plane when something goes wrong

Depends on your definition of super important. In short it would mean that any complaints worldwide about bookcases by the name of Billy or any other flatpack furniture might not be ever received or dealt with after mid December, hardly Boeing or LSE but still a big player in their market field.

[SimonMac]

Whats your role in this?

Are you a developer, release manager, tester?

For me its simple, the change is not fit for purpose so your internal processes should pick this up and reject it going forward.

[chef]

Whats your role in this?

Are you a developer, release manager, tester?

For me its simple, the change is not fit for purpose so your internal processes should pick this up and reject it going forward.

me, im just a lowly developer brought in as an expert in my field as the system they are using is less than a year old for them (has been my bread and butter for the past 10 years) and no-one at the client site has a clue how/what to do. Lots of small dev changes to fit business processes and lots of hand holding with them nodding in a "whooosh over my head" sort of way when I even explain the bare basics of what it is im doing as part of these changes.

Your right, that was my initial report, we found this problem, it affects the change, although the change works I don't want to migrate it as it will take the problem with it and therefore we should exclude this from the planned Dec release. Their response was (predictably) "oh ok, fine" with 1 single person (as always) saying "noooooo, the cost to business in not having this is so so big it is worth more than my own child not to have it, we must find a way".. said by the person who 3 weeks earlier was all fine with not including it in the release if it took longer than 2.5 days dev time ????