Add a comment

 

Re: Everybody is an architect, except when they're not

My best experiences by far of distributed design responsibility is in open source projects that I've run and participated in. The in-built peer review, combined with a longer than average vision horizon for developers (it's assumed by all that an open source project will be around for many years, so design quality carries greater weight) tends to naturally encourage better quality architecture. No-one wants to be the guy whose designs, which are displayed very publicly, look like the back end of a donkey. I've also worked with teams at the two other ends of the spectrum (in corporate projects) - no design knowledge at all, or some rock-star architect with a resume that looks impressive until you realise he's basically grazing the surface of every project he's been on. I have absolutely no time for dedicated architects - those highly paid consultants that flit from project to project without ever deploying anything (because they move on way before you get to that nitty-gritty stage) and have seen many an architecture that looks beautiful on paper that totally fails in the real world, or ages really badly just because it was 'best practice' in theory 5 years ago but those theories hadn't had time to be proven properly yet. Real design isn't done until the code is running live, and preferably until you've been through a couple of post-live cycles. Even if your architect really is an ace, and sticks around for deployment & revisions, vesting that amount of responsibility in one person is extremely bad risk planning. What if he's ill? Or leaves? Who's next in line, and have they really been *doing* it, rather than just watching? Senior developers who have a strong grasp of architecture and design and guide / mentor other coders, but most importantly implement this design by example, are where it's at. And you need more than one of them, otherwise where is your peer review, or your succession plan? Design is a never-ending process - people talk about pair programming, code review, agile development, but if there's anything that needs reviewing, revising and revisiting regularly, it's the design that everything else hangs off. Building an architecture-aware team that doesn't need a single dedicated architect is absolutely doable - almost all large open source projects operate with multiple people at the design helm. They may well 'own' particular submodules individually (casting vote, elevated authority), but the design process is most definitely collaborative, and all the better for it. In practice this isn't confusing or chaotic at all, so long as your communication is good - which is likely the actual root of many failed attempts at such a setup.

Re: Everybody is an architect, except when they're not


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).