Coding the Architecture - Quality

Re: Quality

Kevin Seal — Wed, 03 May 2006 10:48:40 GMT

How far I want to push it and how far I should push quality are often very different things.

That said, it will often be easier to strive for higher quality by inspiring the team and getting involved. I'd see this more as taking on the lead developer role (which is certainly not mutually exclusive to the architect role) - but someone definitely ought to be doing this.

The situation I described in my "first experiences" entry refers to an offshore development team - a team which hurls code over the wall for review close to a deadline. Ideal? Not at all! Getting involved would no doubt remedy a lot of this but would naturally raise the cost of development considerably and would probably be contrary to a rather fine balancing act between various external companies.

I'd agree with Richard; inspiration is often one of the most effective means of mentoring. Every so often, though, you meet a team member or, as I've found, an entire team that is just not inspired or motivated by the same things you are. No doubt there are then other more effective approaches to try...

Re: Quality

Simon Brown — Wed, 03 May 2006 10:48:37 GMT

I here what you're saying and I agree that just one person leading by example can have a massive influence. But what happens when you don't have this one person on your team?

Re: Quality

RJaques — Wed, 03 May 2006 07:27:58 GMT

>>If you insist on nothing less than perfection, how do you get your team to achieve it?

Inspiration.

Often someone on the team with real attention to detail can inspire the team to deliver higher quality products. They don't do it by preaching, or dictating, but by inspiring the rest of the dev team to deliver something of real quality.

Caring about the codebase and the product is infectious.

This is clearly easier as a developer at the coal face, than as a TA in an ivory tower... but that's another problem.