I'm at Agile Cambridge 2013 this week. I participated in the review panel this year and there was a huge amount of quality submissions. The programme looks fab and I'm looking forward to the rest of the week. Here's my notes on the sessions I've attended on the first day.
Moving Towards Symbiotic Design
The opening keynote by Michael Feathers explored Conway's Law which states:
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
He gave some examples of this in action, and I found it easy to relate these to experiences of my own. When working with remote teams we've struggled with communication issues, and so has the code. The boundaries between "our" module and "their" module was as cloudy and wooly as the communication between the teams.
I've also seen the Tragedy of the Commons that Michael described. I've worked at some places where shared code had no clear owner and thus depleted over time. On the flip side, I've seen shared code be tremendously successful when a team was devoted to it full-time (and that team was highly communicative). Conway's law holds!
Michael's observation that people working on a code base for too long become immune to the cruft that's accruing hit home. Uncle Bob has this great metaphor of developers understanding the geography of their code when working with large classes (this function is just here, after all this whitespace, and the really long method beginning foo...). I think this kind of complexity is what developers who work on a project for too long get comfortable with. When you're a new person on that code base you don't have that historical knowledge and you struggle to pick it up.
So what would change if code were king and people were subservient to it? It's an interesting question. People working on the same code for a long time become immune to the cruft that's accumulated within it. The code is screaming out for someone else to tend to it and address this. With this in mind we should probably be more deliberate about moving people around between software projects
If code was a first class citizen in project discussions then we'd pay more attention to things like "death by 1000 features". There's a point at which adding features to a project becomes considerably more difficult. Perhaps we should push back more and do what the code wants sometimes and not just caving in and sacrificing the code base?
The takeaway for me that we don't do a good job talking about code as a party in the relationship between people and process. We're already happy to change project structure to deliver the product, but let's start to explore changing project structure to drive the code in positive directions.
Revere the code!
Unpicking a Haystack
I thoroughly enjoyed the Unpicking a Haystack session by Duncan McGregor and Robert Chatley. We took perhaps the worst example imaginable of legacy code (decompiled from binaries!) and tried to make sense of it.
There were different approaches tried. One group did a lot of reading (they only had a text editor, not an IDE). Another tried to get a foothold in the code, test it and test their way to success. The group I was in took a slightly different approach and leaned heavily on the IDE. I've touched on this idea before (You don't need tests to refactor).
Our approach was to crowbar out large lumps of code with repeated "Extract Methods", rename things to make sense and use the IDE inspections to fix all the silliness (e.g. redundant variables, constant parameters, unused methods). It seemed to work pretty well, but I think there was some skepticism among others as to whether this was a good idea or not.
I hope in the future development tools will evolve to become something more developers trust and code becomes malleable putty we can shape in seconds. As a thought experiment, imagine if you could put your IDE in "semantic lock" mode and just drag, drop and reshape code to your heart's content with the guarantee that behaviour would be preserved. How would that change your ways of viewing legacy code? How would it change your design process?
To wrap up the group discussed how they might change the way they write code in light of the problems of refactoring. I didn't say anything at the time, but I've thought some more about it. Decompilation loses names (not all names, but some names), but decompilation always preserves types. I've waffled before about Types and Tests.
With this in mind, we should be more aggressive about encoding information within types (e.g. compiler verifiable properties) rather than names. As an example, we found some code with a value that either referenced working directories (pwd) or a password. The type information told us it was a string. The variable name was str12345. We had no idea which one to choose. If the original authors had encoded that information in a type, then we wouldn't have had a problem, the type would describe the shape of the variable.
Rob and Duncan are organizing a Software Archaeology Conference which looks fabulously interesting.
Rituals of Software Engineering
Alex Shaw examined the topics of rituals in software engineering. Rituals have a long history, and the essential parts of a ritual are:
- Obligatory (not in the sense of being forced, but you feel like you should attend.
- Admit of Delivery (the style of delivery doesn't matter
- Consequence Free (measurable outcomes are not the goal
I guess rituals has a slightly negative connotation for me. When I hear rituals I think of animals being slaughtered and cargo-cultism (obviously not a healthy way to do things. From the wikipedia definition:
A ritual "is a stereotyped sequence of activities involved gestures, words, and objects, performed in a sequestered place, and designed to influence preternatural entities or forces on behalf of the actors' goals and interests"
By the end of the presentation I was more convinced that I was disagreeing with a word and not the content. The essences of great team 'rituals' included that members of the team know the context and understand the value and reason for the ritual. With all that in mind, I agree rituals are important for engineering teams and it's a really interesting idea to explore.
Growing XP Teams
Rachel Davies gave us a great insight to how the team work at Unruly media, a company run from the start on XP principles.
I love these kind of experience reports. Speaking afterwards, The Agile Pirate described it as voyeurism. I like that description (slightly sordid though it sounds). It's great to get an insight into how a team works and interacts.
It was interesting to hear how the "Lone Ranger" role worked at Unruly. The idea of having a single developer being available to answer questions from support/sales/product managers is interesting, and I can see how that could help protect the other members of the team from unwanted interruptions.
We don't know where we're going. Let's go!
Last, but by no means least, was a talk with an intriguing title by Neil Denny. This was my favourite talk from the first day, and had nothing to do with software whatsoever!
Neil's talk explored uncertainty, that "delicious discomfort of not knowing". Uncertainty is something we face all the time in software development (because no-one knows how to do it right), so it was great to explore this topic. The presentation style was fantastic with audience participation, touches of humour and an engaged audience.
What's more dangerous than uncertainty? "We are never more wrong that when we are most right". Once you convince yourself that you definitely have the answer then you become closed to better solutions, becoming dogmatic and rejecting alternatives. This is a dangerous place!
The point I left with is that we should treat uncertainty is a challenge to savour, not something to fear. When people are looking for answers, they tend to just want the smallest possible change (confirmation bias?). This often makes us go for the minimal change, rejecting the truth of what we need to do.
There were a few books mentioned which I need to add to my reading list
And then...
So there I am, it's the end of the day and I'm outside the college waiting for a taxi. I get talking to someone else waiting and I discover that she's a retired mid-wife. Nothing too strange yet. And a bit more talking and I discover that she's from the same area that I was born in. A few minutes later, we talk about times and ages, and realize that she would have worked at the same hospital I was born in. Putting more dates together we discover that I've just bumped into a person who possibly delivered me. Freaky
Looking forward to tomorrow!
Oops, should have mentioned we're hiring.
No comments:
Post a Comment