I'm in charge of defining an XML schema for some data; the plan is to have various systems (all under our control) upload XML files that match this schema to a central server for processing. I don't have much knowledge of the design of these other systems, so I'm working collaboratively with those system experts to make this XML schema reasonable to both consume (on our side) and produce (on their side).

The schema is not entirely clear-cut, and I'm defining the data we want to collect at the same time as defining the schema. There are a million ways to do it so there's a definite "do something, think about it, talk to so-and-so, refactor, repeat" process in place.

All of that said, we have an unfortunate situation where myself and a few others are defining things and a few other developers are implementing it. I'd like to write some code but haven't found the time. This leads to the frustrating cycle whereby the design changes in the ivory tower and then the guys writing the code have to go and change it again and again. Avoiding details for various reasons, the developers writing the implementation aren't in a position to effectively define the requirements of the schema and the data we must collect.

Should I be the one writing and playing with this stuff as I figure out how it should be done? This would be ideal to me, but we're under pressure to get things done and it's quicker to have a few people working on it rather than just me.

Do we have too many cooks in the kitchen with the XML file providers influencing the schema? Ease of XML file creation should be a consideration of the schema, right?

Is there a better way to solve this problem, or is churn a necessary evil when you're trying to fly the plane as you build it?

What is the correct development process to apply here which will minimize wasted time?

  • How much time elapses between schema changes and implementations of the changes in the code? How often do you all talk? In my experience, churn is a necessary evil in situations like this, but there are some processes or environmental changes that could be put in place to help mitigate the evil (depending on what your environment is like already).
    – jcmeloni
    Apr 23, 2014 at 15:30
  • Is writing the code part of developing the schema design? In other words, are you adjusting the schema based on how easily and effectively it can be used in code? If you are, then there's nothing you can do; the churn is part of the process. If you're not, get your developers to work on something else while you refine the schema. Apr 23, 2014 at 15:36
  • I don't understand why you need to "implement" your schema before you know if it will work or not. Also, if you use a tool to generate "usable" classes based on a schema file then the impact of changes to the schema should be minimal. That is, unless the changes are frequently drastic, in which case you have other bigger problems. Assuming you know "what" your system is supposed to do, those other developers could be working on the "what" without regard to how the "what" gets initiated (e.g. the xml files).
    – Dunk
    Apr 23, 2014 at 20:05
  • As for the process, I would pick 2 of the most varied other systems and nail those down. That should get you to the point where the changes from the remaining other systems should have minimal impact on your nailed down interface.
    – Dunk
    Apr 23, 2014 at 20:13
  • 1
    I think it is what it is, then. Apr 24, 2014 at 16:31

2 Answers 2


I am not sure if it is a way to definitively reduce churn and how applicable it would be to your current situation, but these are some things I would try to do -

Minimum Viable Product

I am not sure if this is fully relevant to your current situation since it looks like you are already in the middle of things but I am going to put it in anyway since it provides a context to some of the other points.

I would push to identify the bare minimum of data needed and try to build the smallest end to end integration possible first. Once that is done it becomes a lot easier to handle further changes as a lot of the initial questions around approach and risk have been addressed.

Tight communication loop

Since you have mentioned that you are not in a position to work on coding the modification to the systems or building a prototype yourself the next best thing is to work closely with the people who have to do this.

While building up the schema specification I would try to keep the communication loop as tight and small as possible. Identify a small team that can handle the project end to end and work closely with them (preferably in the same room).

If you have multiple teams for different systems I would identify certain folks from each team and work with them. If the teams are too small for this I would try to get a specific block of time to focus on the schema integration and build it in focussed sprints.

Build for easy modification/extension

Since you know this is a rapidly changing and sometimes ambiguous schema it is important to design the schema and the code to generate it such that they can be easily modified.

If this is done well, after the initial minimum viable product built out, it would be much easier for the developers to extend the system and reduce the churn time.

  • Thanks, I think this is a close enough answer. The question seems to be a process question whereby a tight, iterative approach with a high communication overhead is the necessary way to move forward, which is what we've been doing.
    – Eric
    May 2, 2014 at 14:04

Add a version element or attribute up near the root of your xml. Each time you publish a new schema increment this version. Producers set the version and use the corresponding schema. Consumers read the version and apply the appropriate shredding. This works best if the position of the version tag doesn't change between versions.

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.