Bill is asking how he can improve the work process of his team. The worst thing in his tale (aside from 1,500 lines of code in a set accessor!) is that there isn't somebody that is in charge for the team, at least not someone who is technical. Unless a person is in a position of authority (preferably well established, rather than ad-hoc one), making significant changes is difficult.

I get a lot of milage from giving the client a link to the continious integration machine. They check to see what progress we made routinely, and the most common request I hear from them is to make the CI build more stable. (The answer to that is to give me a staging machine, but that is another story).

Doing something like this can prove to the stake holders that it is possibl deliver something that they desire, therefor, they will back the requirements when demands are made. In this situations, hiring the boss can be an interesting approach, go look for someone that you really admire, and then convince them to come work as the team leader /architect. Other ways include bringing in a coach, or sending the team to training.

All of the above assume that there is some sort of backup from above. If this is not possible, then support from the team members is crucial. From Bill's post, it doesn't sound like the other members of the teams are interested, but this may be because it wasn't presented in the right manner. It is very easy to give advice about people I never knew, but broadly:

• Show Mort how he can be more productive using smarter tools
• Pair with Jade to get stuff done.
• Challange the Primadona to a duel at sunrise.

More seriously, since Jade is apperantly the most experiance guy in Bill's shop, a good way to start would be to sit with him and try to work incremental improvements. "For the next month, we are putting in continious integration system, month after that, we start working on our design debt, etc". Define a certain level of quality that you will not go beneath. When two developers are collaborating, it should be easier to guide Mort into the fold. To begin with, the Primadona can be ignored, but once stuff started to roll, and the Primadona breaks it, take his code out out. I have reverted changes that broke unit tests in the past, much to the angst of a developer who didn't consider what would happen when I come in to a broken build with no idea what had happened.

Failing all of that, starting to carry a 5Kg hammer and speaking softly always worked for me.

Bill also mentions:

Bill, if you are really serious about that, get another job. To start with, you will need to educate the rest of the team about what is happening. They need to be able to go to your code and understand what is going on. If you aren't talking at the same level, this is a problem. And you are the guy to fix it.