Both photographs of gates coincidentally. Both needed some retouching in photoshop, partly because I haven't always been kind to my negs - and these ones are 20 years old or thereabouts (not sure what that is in neg years). I'm going to have to figure out how to put nice borders around these jpegs to stop the white areas bleeding into the background.
This is a pretty old shot, I think around 1989... I don't recall ever having printed it, so it's good to see it enlarged finally. I didn't have to do much to this one in photoshop apart from retouch out some dust and scratches.
Shot this at the European using Kodak TMZ at 1600, I think it was at around 1/15th or 1/8th with a 50 f2.
It's my first attempt at playing with photoshop. If you look closely, (at least I hope you have to look closely), you may detect that the labels and the bottles came from two different scans of the same image. This was because the labels blew out under the exposure I needed for nice definition in the bottles. So today I learned to use layers, the magnetic selection tool, the stamp and also some 75% eraser... lots of fun.
The scanner, in case you're interested, is a Minolta DiMage Scan Dual IV. I"m very happy with it, but then - it's the first scanner I've ever used - so I'm not exactly an authority ;)
...oh yeah - you can click on the image to get a larger version - just in case you didn't already know.
Oh yeah - 'anyone can change any part of the code anytime...' - but how does that really work, how about when there are inexperienced developers on the team, or when the team is large, or when you can't pair, or when 'anytime' becomes 'anyhow'?
I took a look at the XP Rules entry on Collective Code Ownership to refresh my memory. I'm not going to repeat it here, since you can just as easily read the source.
Essentially it argues that since design is going to be done by developers anyway(Emergent Design), and there's an obvious problem with having one person be a bottleneck (Chief Architect holds vision) - all developers on the team should have the authority to make architectural/design decisions.
As an ideal, I agree wholeheartedly. But what happens when everyone is a Chief Architect? How do we come up with a coherent, consistent, easily refactored design if everyone is designing?
Surely you say - pairing covers that! We rotate pairs, and make sure All Production Code is Pair Programmed. Except that pair programming is in my experience generally the first casualty in any onsite consulting gig... and often we're pairing with beginners in a skills transfer exercise - not the best feedback on important design decisions. Not to mention the fact that not all people on the team may buy into the joys of pairing, or TDD, or high test coverage even.
So where does that leave us... with a problem in my opinion - a problem of how to maintain even a coherent design, let alone a 'good' one. But what to do? Emergent design is reality on all the projects I've worked on - and I certainly can't afford every design decision to be run through the Tech Lead or we'd never get any work done. So, given that we're being Agile (rather than Agile Practice Bigots), maybe we need to make some changes.
What might those changes be? Well, in the spirit of pragmatism - I'm going to describe some changes/practises that I've actually experienced:
0. Help people to communicate better - to collaborate (it's usually ok if you don't call it pairing) when they're not sure, or even when they are pretty sure. Keep an eye out for people who aren't good at this, they are probably your biggest risks. An inexperienced developer who knows when to consult is, IMHO, much better than an experienced one who doesn't. This in my experience involves looking out for opportunities to encourage people to ask questions, get involved in discussions and listen to the chatter. (You have to have a really good reason to be wearing headphones on my team). We've experimented successfully with having senior team members float - not taking on any delivery responsibility, but wander around making themselves available for pairing and generally sticking their noses in.
1. Implement some automated checks - actually implement as many as you can, every time a new problem comes up, write a check for it and run it every build. There are a bunch of 'design' checks included in CheckStyle, quite a few of which were written by my colleagues James Ross and Simon Harris. We've been using those to pretty good effect, however we're starting to wonder if we should be running them in every build - particularly if we should be running them on developer builds. I'll keep this for a later blog, because it deserves attention all of its own.
2. Learn by experience who you can trust to make good design decisions - or more importantly who you can trust to involve others and consult when they are unsure, or even if they are pretty sure. Assign these people as pairs or at least design/review partners to anyone who you know is breaking new ground.
3. Keep an eye out for untested code. This can be tricky and tedious, since JCoverage runs on all your code - not just the bit that changed, so there's a lot to wade through. In my experience, all of the untested code I've found on my current project that was more significant than a simple set/get had problems (this was a surprise for me, maybe I'm just naive).
4. Remind everyone of the practises you've collectively decided on. If your team does TDD, then make sure you know if someone isn't toeing the line and tell them about it. Remind them if necessary that it's 'collective' code ownership - not anarchic code creation.
5. Look out for GOF patterns, well their names anyway... are they the new code smells of the noughties? Maybe they're appropriate - but all too often they're a mask for not really understanding the problem... especially if someone you don't tend to have productive design discussions with is churning out factories and decorators like they're going out of fashion.
6. Keep an eye on the domain data model, assuming that you actually got to design it and it wasn't just foisted on you by a card carrying Data Modeller. I'm assuming that your domain data model will be evolving, and experience leads me to the conclusion that many otherwise quite effective developers are lousy (or maybe just lazy) at data design.
7. Do quick whiteboard design sessions on any stories that seem to need it, or if anyone asks for one. Likewise with technical reviews - we allow a story to be signed off independently of its tech review, the review is there for developer feedback and to do or propose refactorings.
8. Brown bag major refactorings - anyone who thinks they can do a major refactoring should be able to explain it to their peers. This should happen after the fact, because generally things change while you're doing the work and then you'd have to explain what really happened.
9. Do some mob refactorings, where the whole team gets in a room with a projector and contributes to refactoring some part of the codebase. Usually the person driving should be someone who knows what they are doing, otherwise it can get pretty tedious.
10. Check where everyone is up to on their cards, every day, twice a day. If they haven't made any progress on their card for a day, ask why. If the answer is refactoring, ask why - and who they're 'pairing' with. Not because you think they are dull - but because no-one should be 'improving' the codebase without consultation.
11. Insist on a common approach to solving common problems. If it's worth doing this one case differently - then really push hard to see why it isn't worth doing all the rest the same way, even if it involves a little more thought. This, above pretty much all else, is what allows for high productivity in less experienced team members, primarily due to less confusion. It also lends itself to rapid large scale refactoring, since everything is pretty much the same.
So, a few things that we've tried - generally they've worked. The one major downside has been a feeling of disenfranchisement by some team members, that the 'senior' team members were making all the design decisions and they weren't getting a chance to learn. I'm not sure what to do about this. On the one hand I have a duty to my customer to get the best quality and efficiency out of my team that I can, on the other I want to give people the best possible opportunity to learn and improve. I guess I phrase it as a challenge - I don't want one person making design decisions, so ante up with your ideas - subject them to the (sometimes pitiless and mirthful, however always respectful) scrutiny of your peers and if they stand up - then go right ahead. You'll have done what I expect of a 'senior' team member.