If 'Architect' is a dirty word - what's the alternative; when not everyone can actually design a good interface!

Question

Now - I'm a developer first and foremost; but whenever I sit down to work on a big project with lots of interlinking components and areas, I will forward-plan my interfaces, base classes etc as best I can - putting on my Architect hat.

For a few weeks I've been doing this for a huge project - designing whole swathes of interfaces etc for a business-wide platform that we're developing.

The basic structure is a couple of big projects that consists of service and data interfaces, with some basic implementations of all of these. On their own, these assemblies are useless though, as they are simply intended intended as a scaffold on which to build a business-specific implementation (we have a lot of businesses). Therefore, the design of the core platform is absolutely crucial, since consumers of the system are not intended to know which implementation they are actually using.

In the past it's not worked so well, but after a few proof-of-concepts and R&D projects this new platform is now growing nicely and is already proving itself.

Then somebody else gets involved in the project - he's a TDD man who sees code-level architecture as an irrelevance and is definitely from the camp that 'architect' is a dirty word - I should add that our working relationship is very good despite this :)

He's open about the fact that he can't architect in advance and obviously TDD really helps him because it allows him to evolve his systems over time. That I get, and totally understand; but it means that his coding style, basically, doesn't seem to be able to honour the architecture that I've been putting in place.

Now don't get me wrong - he's an awesome coder; but the other day he needed to extend one of his components (an implementation of a core interface) to bring in an extra implementation-specific dependency; and in doing so he extended the core interface as well as his implementation (he uses ReSharper), thus breaking the independence of the whole interface.

When I pointed out his error to him, he was dismayed. Being test-first, all that mattered to him was that he'd made his tests pass, and just said 'well, I need that dependency, so can't we put it in?'.

Of course we could put it in, but I was frustrated that he couldn't see that refactoring the generic interface to incorporate an implementation-specific feature was just wrong! But it is all very Charlie Brown to him (you know the sound the adults make when they're talking to the children) - as far as he's concerned we don't need to worry about it because we can always refactor.

The problem is, the culture of test-write-refactor is all very well and good - but not when you're dealing with a platform that is going to be shared out among so many projects that you could never get them all in one place to make the refactorings work. In my opinion, sometimes you actually have to think about what you're doing, and not just let nature take its course.

Am I simply fulfilling the role of Architect as a dirty word here? I believe that architecture is important and should be thought about before code gets written; unless it's a particularly small project. But when you're working in a team of people who don't think that way, or even can't think that way how can you actually get this across?

Is it a case of simply making the architecture off-limits to changes by other people? I don't want to start having bloody committees just to be able to grow the system; but equally I don't want to be the only one responsible for it all.

Do you think the architect role is a waste of time? Is it at odds with TDD and other practises? Can this mix of different practises be made to work, or should I just be a lot less precious (and in so doing allow a generic platform become useless!)?

Or do I just lay down the law?

Any ideas/experiences/views gratefully received.

UPDATE

At the time of accepting the answer, I'd like to point out that all of the answers provided are excellent - I've chosen the one relating to communication because I feel that as the lead on this particular project, I have to communicate what I want; and at the same time the team must communicate back if they feel it's wrong.

Certainly, though, it's good to get clarification that there's no reason for the development practise (i.e. TDD etc) to interfere with the role of an architect.

Answer 1

I would say that if you already had the architecture in place when he came to join the project, then simple common sense, decency, and manners would tell you that he should conform to the way that it is already being done and implemented. It just simply wouldn't be fair to the rest of the group to expect everything to change every time a new member is added to the team.

Speaking directly about your question I can not, but simply from a team work point of view I would say you would be in the right to lay down the law and continue as you started.

Answer 2

I'm not sure that your question is really Architect vs TDD. I think it is more specific to the individuals in the story.

TDD is not an excuse for what has taken place - the primary purpose of TDD isn't "make the light go green at the expense of quality code / design". The purpose of TDD is that you don't write the code until you've written the test. How you then make the light go green should be as good (or better) than if you didn't use TDD.

TDD and solid Architecture are not mutually exclusive.

TDD does not mean you dispense with patterns and good practices.

Answer 3

I agree with you that architecture is very important. I think you should try to make everyone else understand what problems can arise in the future by breaking the architecture. Actually I had common problem on my current job and simple examples of "good" and "bad" architecture worked for me.

Answer 4

An architect role isn't necessarily a waste of time, nor should it be at odds with TDD or Agile practices.

I think that these work best when you have an idea of the overall framework and use these techniques within that constraint.

When I pointed out his error to him, he was dismayed. Being test-first, all that mattered to him was that he'd made his tests pass, and just said 'well, I need that dependency, so can't we put it in?'.

There's nothing in TDD that would necessarily force this to be the case. He needs to sit down (probably with you) and work out why he needs that dependency. If he can make a good case then you'll have to rethink your architecture in this area, but I suspect that you'll reach a solution that doesn't need the dependency after all.

Answer 5

Communication / Design Goals

The developers really need to undersand the project's design goals. As an architect (and developer) it's your role to ensure that the communication of these goals is clear and they're understood by everybody in the team.

You summarized why there is this particular design goal of your question very well here - that's what they need to understand:

The problem is, the culture of test-write-refactor is all very well and good - but not when you're dealing with a platform that is going to be shared out among so many projects that you could never get them all in one place to make the refactorings work. In my opinion, sometimes you actually have to think about what you're doing, and not just let nature take its course.

So you need to discuss this with him and other developers until everybody is on the same page. Communication is key here.

Answer 6

I'll likely be demonized for this, but personally I think that TDD is way overrated at this point in time except for smaller, trivial projects. In my opinion Agile/TDD are simply another extreme which sprang from the opposite extreme, which is big-corp bureaucratic committee-ism. In your case, assuming you know what you are doing and your team is of moderate size, then there shouldn't be a problem designing all your interfaces first and having a firm conceptual understanding of how all the subsystems interact before you write a single line of code or unit tests. From there on out, find a good mix of TDD and traditional unit-testing (code first, then unit test) to get the job done. However, being totally dogmatic about a coding style and relying solely on TDD is duct-tape programming and will leave you painted in the corner. My motto is "big hollow design up front." Just my 2 cents.