1

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.

  • "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." Propose them an improvement covering these points. – πάντα ῥεῖ Sep 20 at 17:38
  • Yes, i've done that, as i said, but we can't anymore, as a data structure has been modified, making a change would mean to lose data. The most expensive alternative, would be to undo the changes, and migrate the data. – Ale Sep 20 at 17:40
  • Explain these expensive efforts to you boss, and the client. You are the one responsible to keep your code base clean. – πάντα ῥεῖ Sep 20 at 18:04
  • 2
    You have to work this out with the client and your boss, not wit strangers on the internet. And you should not insist that your point of view is the right one, and the one of the client the wrong one - there was surely a reason why the client made these changes by himself instead of informing you to do the changes for him. Try to find out what the reason was. – Doc Brown Sep 20 at 19:53
  • 1
    Personally, I would accept the code and ask if I can refactor it to standards. – RandomUs1r Sep 20 at 20:12
2

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
  • Thanks Christophe! Yes i've taken the time to carefully explain all the pros and cons and the impact of the change, and which options we have now. As to why they made a change, they do not have access to our source control, but they do ask for a copy of it for every release. When i found out about this, i was told to manually add their changes, because a new requirement was made, and this rogue change was live on production. – Ale Sep 20 at 23:04
  • @Ale, then you should incorporate the change into your codebase, with the code written according to your standards but with the database structure the client designed. After that you can make a proposal to migrate the database structure to something that fits your designs better. Either the proposal is accepted to do the migration now, or it will be done when a change request can't be accommodated without doing the migration. – Bart van Ingen Schenau Sep 21 at 8:16
0

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.

  • Hi Erik, thanks for your reply. The schema is currently under version control. The client took a copy of source code, modified it and implemented it. When i found out what happened, i was told to integrate those changes to my version control code, and continue to develop with them. – Ale Sep 20 at 18:15
  • Ok, good to hear! – Erik Eidt Sep 20 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.