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.