Quality
How much is enough?
Kevin posted a great entry about his first architect experiences and it's inspired me to write a follow up about quality.
Contrary to my expectations, I've found that being separated from the development team has made me more tolerant of their mistakes, despite being less able to address these mistakes directly. This I attribute, in part, to being better able to see the value of less costly development. Of course, this is not to say that code quality, mentoring and review aren't still very important! However, I find that I'm less exacting and more pragmatic - if I were to press for the quality that I'd deliver myself (as a lead developer) then I'd be negating some of the cost benefits of having got someone else to do it in the first place! As a lead developer I knew when things weren't up to scratch and I'd do something about it; as an architect I have the context and obligation to determine when things are "good enough" and be confident not doing anything about it. Sure, it's frustrating not being able to roll your sleeves up and show everybody how it should be done ;) but there's also satisfaction to be taken from making a call on whether something's fit for purpose.
This is something that I can certainly relate to and I also feel the same frustration at times. So, let's explore the quality aspect further. Imagine a scale that measures quality. What Kevin is saying is that, as a lead developer, you always strive for the ideal level of quality. Call it perfection if you wish.
Take a step into the architect's shoes and you have to think about the cumulative/average quality across the whole development team. Clearly, asking everybody to achieve perfection isn't realistic, so it's your job as an architect to ensure that quality across the board is adequate. Perhaps that's the wrong word, but let's say the quality has to be as good as you can get it within the given time and budgetary constraints.
Getting the quality towards the top end of that scale would be my own goal, but how far would you try to push it? How much is "just enough"? If you insist on nothing less than perfection, how do you get your team to achieve it?
Re: Quality
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.Re: Quality
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...
