Simon Brown - 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.

My role

Fri, 10 Aug 2007 19:31:00 GMT

Another week over and another two projects done and dusted. The first project started *and* finished this week. It was a two day technical consulting engagement where I helped out a support team fix some low level technical issues and assessed the suitability of a physical architecture of an FX trading system. The second, for another capital markets organisation, was the completion of a risk management system that we've been working on for the past couple of months. I've been working as the technical architect on a 3-days a week basis, where I've been doing everything including architecture, development, testing and support.

Although completely different, both projects have been fun in different ways and this is the thing that I really like about consulting. It does sound cliched, but I do like the variety of work. And that raises an interesting question that I *always* seem to get asked.

What exactly do you do?

I tend to introduce myself as a "technical architect" although, more often than not, I do clarify this by saying that I'm a "hands-on software architect" or an "architect with a technology focus". People ask me, particularly when I'm interviewing them, "what would be a typical role for you?". I actually don't have a "typical" role, but I do have a small set of typical *roles* that include the following.

"Hands-on" software/application/technical/system architecture, where I get involved in :

Requirements capture and architecture definition.
Delivery of the architecture, proving the non-functional requirements.
Design, development and testing.
Quality assurance.

Coaching/mentoring/training of aspiring software architects.
Technology consulting.
Technology troubleshooting.
Architecture consulting.
Architecture reviews.
Project audits and health checks.
Technical due diligence on projects and organisations (e.g. for venture capital companies, process improvement, consolidation, etc).

My biggest roles are certainly the hands-on software architecture roles, and I find that the other stuff fits in quite well in the spare time between projects or during those projects when I'm working in a part-time capacity. I also find that the experiences picked up from the shorter roles help when I'm doing the hands-on architecture work, and vice-versa. A good example came this week - seeing a support team in action has made my rethink the way that I architect new systems, making them more supportable and support team friendly.

So what do I do? Mainly software architecture, but then there's a whole bunch of other stuff that's also technical in nature. "Coding the Architecture" sums up my role well. ;-)

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.