Well, another ACCU conference is here and I have just arrived at the hotel today and am settling in, meeting some friends and listening to a talk by one of them, Michael Feathers of ObjectMentor.

I am not presenting this year because I do not have my thoughts straight about some of my latest thinking – namely “My Thinking is NOT for Sale” – especially how I can even get our current business culture to start thinking about knowledge work in such a way. Although there are some signs.

One of the interesting things about these conferences is hearing some of the more vocal and opinionated people hold forth. Initially I start off feeling fairly intimidated, but then inevitably I find something to comment about and we end up having great conversations. In truth there is a nice balance between the more vocal folk and the timid ones. But here good logical thinking always get respect regardless of how quiet or noisy you are – unless of course the participants have stayed too long and late in the bar! Although thinking about it, John Lakos IS a force to be reckoned with!

Unfortunately another person I really really wanted to talk to was Jim Coplien. He was scheduled to deliver a keynote, but I was told he will not be attending due to illness. I was hoping to have heard more about his DCI work (See also his blog post and this video)

But back to Michael’s talk, which was called “Organizational Machinery around Software”. He was arguing for making the code architecture primary and structuring teams around that architecture. Basically saying to flip Conway’s Law and use it as a lever to get better results rather than having it inadvertently mess up your design because you did not structure your teams in the right way. The basic concept is simple. The implementation and convincing of management may be another thing entirely but it is an interesting view of basing your team structure architecturally rather than perhaps by market segment, or in some other way.

One of the things that he said was that we could take lessons from how the military manage personnel rotating through their teams (or crews I guess), and that business could do the same. As you might guess if you read my blog, I would find such a though unsettling, primarily because there is validity in what he says due to the fact that business is usually run on military lines, whereas I consider that there is a difficult tension between trying to write quality software and its usual economic context. More thought required…

I am looking forward to tomorrow, although I shall be breaking away from the conference in the evening to partake of some Argentinian Tango at some local classes! I might see if I can get some of the techies to come along – could be interesting… This will of course mean that any blog post may be delayed.

Here are some of the notes I made about the talk:

• Being too conservative with code mods will cause a very fast deterioration of the codebase. ie. not refactoring.
• Interface cruft. Easier to change code either side of an API, rather than mature the API.
• Legacy comment.
  
• Interesting research from Robert Smallshire in the audience: Developer halflife is 3.5 years. Code halflife is 35 years. (See this presentation)
• We should be able to visualise a system architecture for ANYONE in the organisation to understand. Not just the techies.

Until next time…