I'd argue that erasing the division between front and back end developers will make the question of "which is harder" irrelevant. It may slow you down at first, as people get up to speed with the parts they're not familiar with.
The only reason I'm asking the question in the first place is to pin point why the UI team is struggling so much. A project manager directly asked me whether they should be having a harder time of it due to working in the front end.
I'm of the opinion that by far the best way to accomplish this is by pairing. Start with asking them to help you on something you'd normally work on. Show them how a failing test makes the job easier. Once you've got some buy in, try following the feature through the front end, all the while using tests to "prove to yourself" what you're doing is working.
I'm a fan of pairing, and this is something we did a lot of at the beginning of the project. I have actually paired with each person on the team (except for one guy we added last week). Unfortunately, a lot of the early pairing devolved into arguments over "style" and productivity really struggled. I still tried hard to pair as much as possible until the teams split in effort to get everyone on the same page.
After the teams split, though, pairing virtually stopped. For me I have stopped pairing because the other guy on my team and I have worked together for a couple of years now and both write very similar code. We communicate regularly on development questions (we work in the same room) and review each others code quite a bit. Pairing didn't seem to give us the value it has in the past (we have paired in the past when we first started working together).
The other team has stopped pairing as well- I think mainly due to speed pressures.
I think we had to split into sub teams, though, because with QA, BAs, and everyone else we are currently at 20 people on the overall "team"- this makes for very painful stand ups and it is easy to get lost in the mix.
There a
nice video from Velocity on creating cultural change that's worth watching, even if not directly relevant. If at all possible get people to join you, don't tell them what they should be doing.
I agree 100% about creating cultural change; however, this is where I have to note that cultural change is going to be valued less and less as we approach the "end" of the project. That is, the team is currently being augmented by several contractors that are all going to be gone in about six months. At that point we will scale down to three developers and an architect, all who have worked together and share a similar culture (big fans of TDD, etc.). So changing the habits of temporary employees doesn't seem worth expending too much effort. That being said, we still have to make sure we hit our immediate deadlines and end up with the quality we want.
I'll still watch your link though when I get a chance.
Previous Topic
Index
