This post hits a nerve for me because as a senior software architect for most of the last decade, I've often found myself in situations where I've ended up quite distant from the code. And I don't like that much. I don't want to just write code but I do find writing code to be both very therapeutic as well as a good way to experiment with some of my ideas and evolve better practices.
I realized recently that, although I created the engineering team that rebuilt macromedia.com (now adobe.com) using ColdFusion and Flash, I hardly wrote any of the code on that site! The RSS feeds on LiveDocs are powered by code that is based on an initial prototype I built but that's about it, in terms of live code. I wrote quite a bit of back end infrastructure code for our ERP integration project (lots of XML processing and JMS messaging). That was a while ago.
My new team is smaller and is trying to be more agile in style so architects write code too. It's really good to roll up my sleeves and write code again - it's really helped me confirm some of my architectural ideas about what we're building (both good ideas and bad ideas!).
BTW, this lack of coding at work is what fuels my contributions to open source projects outside work, such as Fusebox 5!
It's a very difficult task, finding appropriate justification and time to code on a project when you're the architect... but it's necessary. At least I personally believe it's necessary, especially for web application architects.
Though I'm sure it's useful for any software architect, the truth is that web technologies are evolving and being invented at a very fast pace, and this requires architects to be more hands-on on a regular basis. A web application architect from 7 years ago, without studying and coding between then and now, would most likely be near useless in a modern web solutions firm today.
If you're an architect, you've just got to stay up on these things (which change on a near-daily basis)... both intellectually and in practice (to a degree, of course). In my experience most architects feel the same as you and I, and won't object at all to rolling up their sleeves... though they might complain about the overtime necessary to allow this as, unfortunately, many of us have more than 40 hours of work to do each week NOT INCLUDING time to code. My scenario isn't always that extreme, but some weeks it certainly can be difficult...
I've been everything from a one man consulting firm to CEO of a tech start-up with 25 employees (8 programmers) where most of my time was spend raising capital.
I don't think it is practical to be an architect without staying profficient in coding. Unless you write something real, you start to lose track of the patterns of cutting and pasting and the snippets that suggest where you could write a generator or a dynamic pattern to abstract that variability into something that doesn't require programmers to write.
Architecture is intimately tied to the strengths, weaknesses and syntaxes of the languages you use, and I don't think it is possible to be a great architect unless you keep spending the time to stay an above average programmer.
Just my 2p (in Edinburgh right now!)
Best Wishes, Peter
I certainly agree time is one of the biggest issues. A management position tends to require you to be available to put out fires but coding (at least for me) requires chunks of 1.5-3 hrs to get in the zone and productive. I typically schedule specific times during the week when everyone knows I'll be coding. I give everyone plenty of work with some backup projects in case they get stuck, and I get someone else to cover the phones. It took a while to train employees (and clients) but eventually they understood that it was in their interest to wait a little longer for their 2 minute quesiton to be answered than to use a product that wasn't progressing because the architect couldn't get any quiet time to code! Best Wishes, Peter
I've also been spending more and more time looking at Enterprise Architecture within my company, which differs considerably from Software Architecture. While having knowledge of application development practices, it isn't essential to get down to the code level in the EA space.
I do keep current in AD trends via all of the blogs and trade publications I read, but I find that by not coding every day, my skills have definitely eroded. Things I used to do from memory now require a round trip to a reference book.
Like Sean says, though, my lack of coding at work is at least partially ofset by personal projects, although not at a level that even comes close to what it used to be.
I find this beneficial for several reasons.
1) They keep their claws sharp and continue to grow their understanding of the technology platforms for which they are designing applications.
2) They are less likely to design systems that are a pain in the a$$ to code and maintain.
- max
Thanks
As for structure, we have four internal software development teams. They all work on entirely different software applications, but as the organization is growing, we've found that all the apps are needing to talk to each other. Since these legacy apps were never designed to talk to the outside world, we're going to be doing a lot of reworking and exposing of functionality, hence the switch to Java from PL/SQL. We're using Flex for our new front ends, but ultimately I think we'll have a nice mix of Java APIs, Flex, and a little CF as glue code where necessary.
When it comes to prototyping applications or proofs of concept in code, this is something that our Architects will do entirely in the near term, but we're trying to create solid design skills within our development teams. As a result, I hope to see the tech leads on each team start to take on these sort of tasks as they get familiar with Java, in which case the Architect will review the solution and give guidance (rather than always being the go-to guy to create the prototype). Of course, the Architects will also continue to act as coders on projects to keep their perspective.
Hope this helps answer your question.
- max
- max


