I'd say your problem is test coverage in the UI side of things. It sounds like you have the classic problem of one thing being changed intentionally affecting other unforeseen parts of the app. Just because there isn't Serious Business Logic in the front end doesn't mean it doesn't need to be tested.
This in fact happens a lot- QA reports a bug- they fix it, and it breaks something else. Of course my first response is like yours- "if there were tests around that functionality, then we wouldn't have this problem". However, using TDD is being seen as a style difference, and "it's hard to teach experienced developers new tricks". And obviously TDD is not that same as test coverage, but it is how I (and a few others on the team) achieve good test coverage.
If I were joining your project with the goal of attaining a sustainable and predictable pace, I would try and combine the front and back end teams into one team with ownership of the whole code base.
Hmmm- this is interesting, as I was the one who suggested the more specialized approach. The reason being is that rather than having developers need to understand understand every piece of architecture within the app, they can focus on one area.
If the response is "well, the front end guys aren't as strong developers as the back end guys" then perhaps you've found your answer as to why you're having regressions only in the front end. The answer isn't necessarily to fire the front end guys, but is more likely to be to shuffle everyone, and get the front end guys understanding what the back end guys do, and vice versa.
That is definitely NOT the response, at least from the project managers. They view all the developers as equally strong. QA is starting to grumble a bit about the other team and I am trying to keep them calm, but they are getting quite frustrated.
This point is why I kind of made this post. One of the project managers asked me "Is it more difficult to work in the front end?" My answer was "if it is, it is because we made it that way- front end code is not inherently more difficult than back end code". After telling her that, I started to question myself- hence this post. My belief (open to being challenged) is that the abstractions we created to solve our front end problems are not as good as the abstractions we are using in the back end, so now working in the back end is indeed easier. But of course, that WOULD lead back to developer skill, as we are the ones who created these abstractions.
The first order of business would then be to get the front end tested as well as the backend. In my Ruby on Rails world, this would be Selenium for browser testing, Jasmine for javascript testing, Cucumber and Webrat for story level testing, and plain rspec for the controller and model level code. Don't be afraid to slow down and figure out what works for you - any code that's worth writing is worth test driving.
The front end is Silverlight (I know, I know- not the issue here!), so anything in C# is easily testable using the same testing framework we are using for the back end (the app is C# through and through). The problem is that unit testing is not valued by everyone- it seems to be one of those "if it works for you" and "nice to have" kind of things.
Previous Topic
Index
