I'm interested to learn about what tactics you guys and girls use for dealing with multiple project developing on the same application on the same time.

We have an application in our organisation which the business really wants to expand upon. For the coming year multiple projects are on the roadmap to do development. Now the challenge is that they are all on the same application and are planned in the same time period. However OutSystems really poses some challenges when doing parallel development.
It's expected that these projects have different release dates, meaning that a project in development is not allowed to go to production together with another project that is finished.

Now we already try to avoid this problem as much as possible by using the following tactics:

- Planning: plan work on the same application after each other instead of parallel

- Divide into e-spaces: cut up an application in independent e-spaces and assign a maximum of 1 team to work on an e-space

- Code Branching: Use custom build code branching, by using if statements that are controlled by a site.property boolean, so that we can disable / enable parts of the code till it is ready to go live.

- Multiple servers: develop on separate servers and than merge the code together when done

However the thing is, no solution is perfect and they all have some downside. And with the current project coming the above solutions aren't enough. When multiple big projects go to work on the same application, it is expected that the same e-space, the same screen, function, entity is going to be touched by all projects. That makes automatic merging impossible and makes this a real challenge on how to bring one project to production while more then 1 project is being developed.

I'm interested to know what tactics you use to keep this problem under control?


Hi Paul,

Most tactics you name are indeed the ones we employ as well, or ones I could come up with. Truth be told though, if you're talking about changing the same screen for multiple projects, the business is doing something wrong. For example, I can't imagine a proper screen design (UI/UX-wise) that is totally independent of either project: if two or more functions need to be added to a singel screen, the design has to be taken as a whole, not as seperate, unrelated things.

As for the software development-side of things, I think allowing multiple teams to change an application is bad, for a number of reasons. Not just the practical reasons with merging etc., but also because one should have rather intimate knowledge about how an application works, be an "expert" so to speak, and having different teams making changes will prevent that. Also, from an architectural view, meddling by different teams/projects would be a big no-no, unless the same architect is present in both project teams.

So to sum up: the business must realize it can't have multiple projects working on the same core functionality without some strong co-ordination between the project teams on the business-side, and a single point-of-entry for the development side (i.e. a single UI/UX expert, a single architect, a single team etc.). And the software development team or teams must ensure that the application stays internally consistent (without creating massive technical debt), and development should really only be done by a single team (with again a single architect overseeing changes).

Then there's the matter of different go-live dates. If the changes to a particular screen are relatively benign, you can get away with some site property-triggered switches. If the changes have more impact, you could think of "branching" the screen by creating a copy, or two copies, that can be redirected to based on said site-properties. This will of course involve more work, both for development and testing, but may ensure a cleaner architecture and faster screens.

Kilian Hekhuis wrote:

So to sum up: the business must realize it can't have multiple projects working on the same core functionality without some strong co-ordination between the project teams on the business-side, and a single point-of-entry for the development side (i.e. a single UI/UX expert, a single architect, a single team etc.). And the software development team or teams must ensure that the application stays internally consistent (without creating massive technical debt), and development should really only be done by a single team (with again a single architect overseeing changes).

Recommended reading on this specific subject - which approves Kilian's opinion: "Scrum - The art of doing twice the work in half the time", chapter five (Waste is a Crime), Pages 91 to 94. :)


Kilian Hekhuis wrote:

Hi Paul,

Most tactics you name are indeed the ones we employ as well, or ones I could come up with. Truth be told though, if you're talking about changing the same screen for multiple projects, the business is doing something wrong. For example, I can't imagine a proper screen design (UI/UX-wise) that is totally independent of either project: if two or more functions need to be added to a singel screen, the design has to be taken as a whole, not as seperate, unrelated things.

As for the software development-side of things, I think allowing multiple teams to change an application is bad, for a number of reasons. Not just the practical reasons with merging etc., but also because one should have rather intimate knowledge about how an application works, be an "expert" so to speak, and having different teams making changes will prevent that. Also, from an architectural view, meddling by different teams/projects would be a big no-no, unless the same architect is present in both project teams.

So to sum up: the business must realize it can't have multiple projects working on the same core functionality without some strong co-ordination between the project teams on the business-side, and a single point-of-entry for the development side (i.e. a single UI/UX expert, a single architect, a single team etc.). And the software development team or teams must ensure that the application stays internally consistent (without creating massive technical debt), and development should really only be done by a single team (with again a single architect overseeing changes).

Then there's the matter of different go-live dates. If the changes to a particular screen are relatively benign, you can get away with some site property-triggered switches. If the changes have more impact, you could think of "branching" the screen by creating a copy, or two copies, that can be redirected to based on said site-properties. This will of course involve more work, both for development and testing, but may ensure a cleaner architecture and faster screens.

Thank you for sharing this. So to sum it up you basically suggest not to have parallel projects. I fully agree to this.

If however this can't be avoided, I wonder what solutions people here have found to deal with it.


Well, it depends on what you'd call "can't be avoided". You simply can't "deal" with two or more teams changing functionality in the same module at the same time. That will always result in chaos. You'll always need someone arbitrating, or overseeing, the changes. If your managers don't get that, try an anology: say you want your car to have a fresh paint job, but you also need to revise the engine. Anyone will understand you can't have mechanics digging below the bonnet while someone else is trying to spraypaint the car. Software is the same.

My take on this:

- Plan, plan, plan.

- Know the limitations of having multiple teams working on the same "modules", and plan for that.

- Try to make sure what each team is delivering doesn't cause conflicts in the platform.

- Did I say "Plan"?


I know we're all into "agile" and stuff, but a little planning doesn't do any harm.