Well, it’s not me. Despite my best efforts at blogging over 2 years (and a bit of Search Engine Optimization), a Google for ‘Paul Browne’ shows that I am only number 3 on the list. Even worse , the ‘Dr Paul Browne (PHD) DCU’ hasn’t been updated for 3 years. What do I need to do to get to number 1, get Twenty Major to take out a hit on this guy?
On a related note, Jason Kolb has a list of things to do to protect your online identity (good). John Breslin has a list of (bad things to avoid) and we’ve blogged about this notion of ‘blogs as the new CV‘ in that future employers will want to be checking out your blog (as a harder to fake version of your CV).
Update: As of Sept 2007, a Google Search for Paul Browne now shows this blog in No 1. position (unless Google are doing some fancy personalisation of searches. Next step will be to trademark (or even better find a way to Patent) the name and charge all the other Paul Browne’s for it use.
The best thing about doing presentations is the questions you get asked at the end. Apart from the stomach churning moment of ‘will I be able to answer this one?’ they give you a new angle on things that you may have always assumed, but force you to think of in a different way.
Take one of the questions after yesterday’s Enterprise java presentation at DCU. One of the topics mentioned in the final ‘putting it all together’ was the Agile and RUP (or other upfront design) methodologies. The question , coming from an attendee that was keen on using Agile , was ‘How do you do Architecture in an Agile project?’
On the face of it this seems a contradiction. Agile in it’s most extreme form is ‘make up just enough design as you go along’, with automated tests to make sure changing things later is a relatively low cost and pain free process. In real life most projects are a balance between Agile and need some element of a more formal process (often trying to answer the question ‘how mucn is this going to cost?)’
So , how do you merge Agile with an upfront design process? It’s easier than you think.
Most systems built the ‘traditional way’ do not get all their design done in one go. They might start out with the best of intentions for phase 1 with a clean sheet but over the months / years people come and go, business requirements change and different phases try to deliver different things. Over time the original clean design twists and turns and you work hard to try and make it work out ok. Some of features you thought were key may end up getting thrown out as too complicated.
Now Agile architecture is a similar situation. Each weekly / monthly iteration is like phases on the larger project , with twists and turns that may be unexpected. The difference now is that you have a safety net comprised of your (J)Unit tests, to allow you to make radical changes if your blueprint ends up in a cul-de sac.
Yes, it is ok to have an idea the bigger picture and where you like to go with the design. Yes, a good architect will find reasons in the current release to build towards that design. And yes, a good architect may admit that some of the design features he / she thought were required weren’t actually needed. The difference between Agile and Upfront architecture is in when you find your ‘Don’t really need it’ point. With Agile , you find it just before you build it. With upfront design / architecture you find it when it’s already too late.