Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We produce a number of analysis tools which we re-brand and customise for other businesses to include in their websites.

The tools are typically product comparison, data/trend analysis and report production (in a very particular sector). At present these tools run as a single instance in house, our clients redirect there traffic to us with a URL param specifying the client for branding and customisation.

Up until now we've been using an MVC approach with XSLT views. If a customer wants customisation we add switches in the MVC and/or imports&override in the XSLT. This was manageable for a while but now we have so many versions and customisations for sooo many clients, getting stable builds out the door is becoming a nightmare

We are looking to move to MS asp.mvc3 with using Razor for our views but before this I am wondering are there any standard practices or patterns for developing and managing the kind of mess we are sliding towards?

Cheers, T

share|improve this question

3 Answers 3

up vote 2 down vote accepted

If switching views causes application stability issue, you've coupled the view to the business logic too tightly. This also creates testing issues because of the view permutations.

This leads me to think that the Model-View-Presenter (MVP) pattern would suit your development needs better. You can read up on 2 derivations of them on Martin Fowler's site:

You won't be able to achieve what you want overnight, but hopefully with some planning and foresight you'll get most of the way there in a couple release cycles.

Also look into good continuous integration practices/tools.

share|improve this answer

Depends, what's the real problem with the system you have now? Why are builds unstable?

Sounds like your team needs to Get Organized.

I would start with documenting everything. Every current build and every change for every customer and customization. Before changing anything, consult the documentation. Make sure your changes don't break the system.

It's quite possible moving to an entirely new set up is the best way to achieve organization and stability.


Reminds me of a company in Genoa I spoke with once...

share|improve this answer

This may not be the answer you're looking for, but are you sure you are attacking the root cause of your problem? It sounds a bit like you are trying to solve a symptom. I get the feeling there is a much deeper issue.

I would suggest investing half an hour with your team into the 5 Whys to get closer to the root cause. The results are often revealing and surprising, and allow you to better solve the problem instead of just the symptom.

Once you know what the real root cause of your issue is, you can look, with the team, at ways to solve it. Nobody is better at tracing the problem and thinking about fixes than the team, as they experience and work with this all the time. It can be hard to find the right solution - try your best and always retrospect to see whether you can do better.

(That said, there's obviously nothing wrong with looking for inspiration for solutions outside the team.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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