Should i accept that a client adds changes to sourcecode on an ongoing development?

Question

I'm currently in a situation (i'm a technical lead) where the client has modified on his own the source code, and i'm being told to accept the changes and keep working on that version. Technically he owns the code, but, he decided to make a change, and didn't made me aware of it.

His changes won't follow any convention, any good practice and in fact due to a report requirement, made a modification on the data structure.

My boss, told me to accept it and deal with it. I've replied to him by asking then why should I impose any sort of standard to my team if a client would just ruin anything that we've taken so much effort to maintain, which is, code quality.

The client did recognized that he would accept to undo the changes, but, data has already been created with this change, and to undo the changes would mean to lose them.

Regardless of the details, my question remains. Should i accept the fact that the client has modified the source code and I have to continue on with it, or should I remain true to the teams standards and refuse to continue.

Edit: I've researched on the matter but i've only found topics on sourcecode ownership.

Edit: As some have suggested that I should offer the client to refactor the code and improve it, I must clarify that as it currently stands, the client made a change to the data structure both on the database and code (changed a dynamic list type of structure to one of fixed columns resulting in 5 fixed items), the reason was just that they needed to make reports straight from sql. I've found out about this after it went live on production and approximately 1500 records had been created. Way before I suggested to clean the code, I realized that doing so would mean to either lose the data created, as it wouldn't be compatible, or that I would need to migrate the data to a new structure. The client did acknowledged that they did it to get out of a hurry and skip making a request to us.

Answer 1

What's the matter ?

I understand that this is extremely annoying. But this can happen when the rules of the game are not clearly explained.

Depending on contractual matters, the customer may or may not be allowed to intervene on the code. Even if the customer may not interfere, your boss may accept it for commercial reasons (e.g. your company is very small, and the customer is very big). So if told by your boss, you'll have to cope with it.

How to handle it ?

The project management keyword for such surprises is change management. Changes are natural and unavoidable in projects. Don't resist but respond to change, whether classical project management or agile.

But not at your own expense and not at the cost of your credibility. This change initiated by the customer has an impact on the work of your development team. You must clarify that.

The typical way of proceeding is to assess the unexpected change:

• What's the impact on your work ?
• What workload is required to re-engineer it, refactor it, make it compliant with your dev standard ?
• What additional work is required on your part of the job because the design is no longer valid ? Or to correct the database ? And perhaps even for additional documentation ?

Typically, you'd estimate the effort required for all of the above. And you should also estimate the effect on the schedule (after all, you might have to shift some stories to the next release whereas you would otherwise have been in time).

Report the impact assessment to your boss. Up to him to agree with the customer: commercial/financial matters are not your business. But at least the responsibilities are clear and all parties know what to expect. Handle this change as professionally as you would accept any change in the requirements.

Dammage containment and process improvement

You should also try to reduce the risk that it happens again in the future.

If the customer already accepts to withdraw the change, he/she may have understood the problem and not be tempted to do it again. But communicate clearly on the topic and ask your customer to inform the other teams if any.

Another way is to reinforce the delivery and deployment process. It's more difficult to set up if you don't have it, but definitely something worth to invest in:

• Use at least proper source code control with an appropriate workflow to prevent unauthorised people to change code as they want. (This would be a good move for improving also the general IT security - malicious software changes by insider is a real threat).
• Use CI for automating the build and test process.
• Use CD for automating deployment without undesired interference

Answer 2

Applications that maintain persistent databases need to upgraded from time to time.

Data versioning aka schema migration is a big deal, and y'all should have some sort of real strategy for it.

Having a strategy for schema migration is arguably much more important than enforcing uniform coding standards, since the latter is internal to development and the former goes more directly to customer experiences, like incorrect results or loss of customer data.

A strategy for schema migration might include:

• track all schema versions released into the wild (i.e. potentially in use by clients),
• version numbering for the schema, so a database found in the wild can be directly recognized,
• schema definitions should be maintained under source control versioned
  • so that they can be compared by tooling to identify differences, and,
  • in advanced cases auto generate migration scripts.
• Installation & upgrade should integrate migration scripts, e.g. for all possible schema that might need to be upgraded
  • Upgrades may involve additional down time during schema migration depending on how automated and comprehensive the approach.
• The installed application should balk if someone attempts to run it against a schema it cannot handle (by checking version numbers).

These thoughts pertain more to when you own the product and have multiple consumers, than when your one and only client owns the product, so, you may find only some subset of the above is applicable.  Still, some discipline about schema versioning is in order.  It seems likely that your client might have multiple separate installations (experimental, in production, others?) just on their own.