How do you maintain your coding skills?
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.
London User Group - August 2008
Flex, Silverlight or JavaFX - which should you choose?
Here are the details of the August London User Group.
- Title : Flex, Silverlight or JavaFX - which should you choose?
- Summary : Rich Internet Applications are a hot topic at the moment; with Adobe, Microsoft and Sun vying for your attention in a post-AJAX world. But which should you choose? In this session, Simon Brown will present a look at three major RIA platforms - Flex, Silverlight and JavaFX. A common example will be used to demonstrate each of the platforms, additionally acting as a baseline for an unbiased comparison of the code, development paradigm, flexibility, ease of use and so on. The format will be presentation followed by a roundtable discussion where you can ask questions and share your own RIA experiences. Come along and let the RIA debate begin.
- Date : Wednesday, 20th August 2008
- Time : 18:30-20:00
- Location : Skills Matter, 1 Sekforde Street
- Format : Presentation and discussion, with further discussion in a local pub (The Crown).
- Cost : Free, but registration is required.
Many thanks to Skills Matter for sponsoring the user group.
Update, 13th August : Registration link added and we also have Adobe stuff to giveaway!
Mind the gap again
You need to pin responsibility on somebody
I did some technical consulting/due diligence on a large software development project recently where I'd been called in to look at how the project team was dealing with some of the non-functional requirements. I'm not sure exactly how large the project team was, but it was somewhere over 50 people and the project itself was subdivided into a number of smaller teams, where each team was responsible for looking after a small subsystem within the overall architecture.
The summary of my review was that very little thought has gone into the non-functional requirements and that retrospectively performing some non-functional testing *could* expose a whole host of problems that are expensive to fix. One of the reasons for the lack of work on the non-functional requirements is that each of the subsystem teams basically doesn't have an architect. Instead, they have a Technical Project Manager and a Technical Team Lead, with definitions as follows (I'm simplifying this a little).
- Technical Project Manager : a generalist rather than specialist, and somebody that has a technology background but doesn't necessarily understand technology in great detail.
- Technical Team Lead : depending on the team, this person is either similar to the Technical Project Manager but working at a lower level of detail, or it's the lead developer.
This sort of team/resource profile isn't actually that uncommon and I see many project teams that are organised in this way. In essence, teams get in a Technical Project Manager because they think people in this role can successfully undertake the project management *and* architecture roles on the project. Unfortunately, my experience suggests that this isn't always the most successful approach.
In I Need a Technical Project Manager, Johanna Rothman talks about the dynamics of taking on both the project management and architecture roles. Specifically, she says that one of the roles usually has to give way, and I agree. Coming back to the project I was reviewing, the basic problem was this - the Technical Project Managers didn't have enough experience of dealing with the architecture aspects (including NFRs). As for the Technical Team Leads, the same thing applies (their focus is generally at a lower level), but in addition they don't have the authority to make architectural decisions. Also, with both roles, it's hard to ascertain exactly who has the responsibility for something like the non-functional requirements.
I see this pattern crop up fairly regularly, and it's a variation of what I talk about in my Mind the gap essay, where key responsibilities fall down the gap between team members. The easiest way to fix this sort of problem is to be explicit about the roles/responsibilities when starting the project. And that means pinning those responsibilities on somebody.
