I'm processing data and writing in a database, that is used by my colleague, a designer, working on data viz.

How can I efficiently, say, add a new column for my colleague to use in their visualization?

I have a "production" output which they uses, and a "staging" output that I use to check my result, they also have a "production" visualization (website for instance) and a "staging" viz.

I'm thinking of 2 options:

    • Add new column into my staging output,
    • once I'm happy with my dev, launch this new feature (new column) into production,
    • then write some sort of release note to warn my colleague that this new column is available,
    • and let them do their part of dev/staging/production for their visualization.
    • Add this new column into my staging output,
    • warn my colleague that this new column is available,
    • wait for them to do their part of the dev
    • once we're both happy with our dev, launch the new column and the new visualization in production

Each method seem to have cons, so I can't make my mind about what to do:

    • A bit slow, my colleague has to wait for me to launch my feature to start working on their visualization
    • If I'm removing a column I need to be extra careful that nobody is using it, since it's in production
    • We need to deploy in sync
    • My colleague is working on changing data. Say I need to change the name of the column I'm using during my development phase, my colleague needs to update the source of their visualization.
  • Think of it from a risk management perspective. Who else is using the application? What is the impact if you make an incompatible change to the database? If your data viz person is the only one impacted by your changes, you might be able to justify option 2. If your application is being used by hundreds or thousands of users, option 1 is the only thing you can responsibly do. Feb 27, 2020 at 17:11

2 Answers 2


Your second option has less cons than you think:

  • You don't need to deploy in sync. As the data provider, you can deploy first as long as you don't deploy incompatible changes. An additional field shouldn't break compatibility, ever.
  • To avoid having your colleague work on a moving target, agree on an interface definition (in your case, name and type of the new database field) and stay with that unless there are very good reasons to revisit that during development.

So a reasonable sequence of actions would be (assuming that there is an actual request for that new field):

  1. You and your colleague agree on an interface.
  2. In the staging environment, you define the database field which will initially probably contain null or default values.
  3. You and your colleague can work in parallel. At some point, you tell your colleague that the data in the staging environment should be good, and he/she can check whether the visualization works. In this phase both of you can fix any issues that come up.
  4. When you're satisfied, you can deploy the new column to production.
  5. After that, your colleague can deploy the new visualization to production

The main takeaway is that you agree on an upwardly compatible interface first, then you don't need synchrony, just proper sequencing (i.e. the implementor of the interface must be ready before the consumer) in the different environments. Deployment in production will still most likely in very short succession since you both are interested in deploying the feature and being done with it :-)


This is about managing dependencies. The designer is dependent on your changes. Simply put, whoever is managing this project/product should be aware of these dependencies and put forth the appropriate schedule so that affected parties can remain in synch.

If there is no management, then simply communicate with your colleague so that your change and their change can be done in a coordinated manner.

It helps to have some documentation here (maybe a high level system diagram) to show who the consumers (dependents) of your application are so changes remain in sync.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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