Coding the Architecture - coding tag

How do you maintain your coding skills?

Fri, 15 Aug 2008 14:38:00 GMT

Jason Chambers has a great blog entry called Do Architects need coding skills?, which talks about why architects need to be able to code. Given that this site is called Coding the Architecture, our thoughts on this will come as no surprise. In addition though, he also asks the following.

However, a more contentious question maybe - Do Architects need to maintain their coding skills once they've achieved the lofty status of architect. Well, I think it depends. Enterprise architects - possibly not (more on that later). However, for application, solution or product architects - I would say yes. There are many reasons why I think this is the case.

Again, I agree with what he says - you need to retain a certain level of technical knowledge so that you can competently define an architecture using it. And that itself raises another interesting question - *how* do you maintain your coding skills as an architect?

One of the problems with being promoted to or assigned as a software architect is that you might find that you can't code as much as you'd like to. This may be down to time pressures because you have a lot of "architecture" work to do, or it might simply be down to company politics not allowing you to code. It happens, and when it does, you run the risk of introducing a huge great gap between yourself and the development team. All is not lost though, because some of my advice for addressing this gap also applies here.

There's obviously no substitute for coding on a real project, but getting involved with the code reviews is one way to at least keep your mind fresh with technology and how it's being used. Of course, you probably have more scope outside of work to maintain your coding skills; from contributing to an open source project through to continuously playing with the latest language/framework/API that takes your fancy. Books, blogs and podcasts will get you so far, but sometimes you just have to break out that IDE.

Think like an architect

Fri, 13 Jul 2007 09:08:00 GMT

IBM recently updated their Software Architect Kit and one of the articles it links to is entitled Evolution of Developer Skills Is Essential for Job Survival, which states that developers need to raise their game if they are to survive in the constantly changing IT industry. That's fair enough, the industry is evolving and we all need to evolve with it. Personally, I'm not convinced that the industry will evolve exactly how the author thinks it will, where traditional coding will become a thing of the past, replaced by SOA and abstract modelling techniques (e.g. MDA). There are some very bold statements in the article, but the one that struck me the most is as follows.

Since architects model and do not write code, modelling tools teach you to work and think like an architect.

I think you know my thoughts on this, although I do agree with the part that talks about modelling. Somebody once told me that the key characteristic of a good architect is the ability to think in an abstract way. You can also think of it as the ability to not get caught up in the details all of the time. To some degree, modelling allows you to escape from the detail and see the bigger picture, irrespective of whether you choose a "model everything" or "model just enough" approach and irrespective of whether you use a tool or a whiteboard.

While you might not agree with the views being put forward in the article, it's worth a read because it presents something that will be new to a lot of people. At the end of the day though, architecture is about abstraction, not modelling.

The non-coding architect

Mon, 02 Jul 2007 19:14:00 GMT

I found a great blog entry today by Frank Kelly called How to spot the dreaded non-coding architect (NCA), which is about some of the differences between architects that can code and architects that can't (or don't). Since this site is about "coding the architecture", I thought you might find it interesting too.

These NCA folks can be really quite dangerous and give dev teams a bad name ... But how can you spot one? For most developers it's pretty easy but just in case you can't I've compiled a list of example scenarios that should help - comparing the often dogmatic attitude of the NCA with the pragmatism of the experienced Coding Architect (CA).

Recommended reading and a little humour to brighten up your Monday.

The great rate debate

Wed, 23 May 2007 07:31:00 GMT

Here's an interesting one for those of you working for a consulting/product/professional services organisation. How many times have you heard the following?

The customer won't pay your architect rate just for you to sit and code all day.

Personally, I've heard this quite a bit. First of all, yes, there's a fair amount of truth and reality here; why should a customer pay architect rates for somebody to sit and code all day? Unless the architect in question has very l33t coding skills, the customer probably shouldn't.

When you hire a software architect, although you're getting somebody that might be a good developer (if they believe in coding the architecture), you're really buying into somebody that can define and deliver an architecture for you. I'm definitely behind the stance that you don't have to give up coding as an architect, but you mustn't forget about your primarily responsibilities either.

If you find yourself spending 100% of your time coding, you've probably forgotten about the other stuff (e.g. architectural conformance, non-functional requirements assurance, quality assurance, etc) and your customer isn't getting what they paid for. You can certainly get your hands dirty as a software architect, but you can't delegate *all* of your architecture responsibilities. If you find yourself in this position, take a step back and look at the bigger picture once in a while.

You don't have to give up coding

Tue, 15 May 2007 12:07:00 GMT

I've already written that architects should get involved with the code and there's a flip side to this where I'm constantly asked whether architects *can* continue to code if they are to climb the corporate career ladder. This is a shame, particularly if these people really enjoy the technical side of what they do.

My take on this is yes, absolutely, you can continue to code. For me, it's quite frustrating to hear interview candidates say, "well, I understand that I'll have to give up coding to become an architect or to progress further up the career path". There are lots of organisations where this is the expectation and it's reassuring that I'm not the only person to have been told that coding doesn't have a place in the senior ranks of an organisation. Something that really struck a chord was a quote from somebody at the closing QCon London panel recently.

We’re losing all of the senior technology mentors into management positions.

As a software architect, you take on a great deal of responsibility for satisfying the non-functionals, performing quality assurance, making sure the software is fit for purpose, etc. This *is* a senior role and coding is one of the very best ways to make sure the project is successful. I have some thoughts on the whole career progression thing that I'll save for another day, but I want to reiterate what I say to everybody that comes through our doors for an interview. No, you don't have to give up coding.