Conway's Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

See http://www.codingthearchitecture.com/2008/12/07/conways_law.html

Powered by Qumana

Agile North

I'm heading to Agile North tomorrow, really looking forward to seeing Bob Marshall's talk on right shifting.

I'll also be covering for InfoQ.com. If you're going I'll see you there.

The Legend of Bruce Lee.

"Don't think. FEEL. It is like a finger pointing away to the moon. Do not concentrate on the finger or you will miss all that heavenly glory."

The man's a legend. And he epitomises the Expert. How many time have you sensed something and you were wrong? Indeed, how many times have you looked at a solution and said, there's something not quite right.

I worked on a project last year. The domain model was incredibly complex, and the calculations to derive payments to customers were extremely convoluted (based on geographical areas and the nature of borders on those areas). The business processing layer was well in excess of 100,000 lines of code. Every now and then, we'd come across a payment anomaly. A tiny amount, fractions of a penny in thousands of payments. We called it "The Bagel" because we didn't know what else to call it.

When I left it was still there, the bready, doughy ring of triggers, views and stored procedures. Its grew into such a complex mystical thing, almost always spitting out the right results. But it 'felt' bad. You just looked at it , printed out on a big bit of paper, and you knew it was bad. But you don't exactly what's wrong with it. And you know one day, it would bite you in the ass.

I just checked. Its still there. And people still feel bad about it.

That's what comes with being an expert, these things get emotional. And you don't know why.

What makes a Framework Rock?

I've been building an application to enable distributed teams to work in an agile way, and surprise surprise, I've been using Ruby On Rails. And this morning, I started thinking, why has RoR been so popular? Why have I, over the last2 1/2 years, been building all my webapps using Rails? Habit? Because it's trendy?

It's because the RoR framework enables the novice developer to pick it up and use it. Straight out of the box. The feedback loop is very short, and the rules of engagement are clearly defined - both ideal traits for novice adoption. And as the knowledge of the adoptee grows, as does the framework, opening doors (and at the same time encouraging good practice) for further learning, which in itself promotes learning.

So, to answer the question, what makes a framework rock? The framework must not only do what its intended to do, but must encourage the adoptee to want to become an expert in it, so that, with the adoptee, the framework can grow. That's how we raise the bar.

The good from the great.

One of the main things I've learned from my attendance at QCon is this.

Its not just about being bright, and having ideas. Its about being bright, having ideas and sharing them. So I've decided to write a little more about my experiences around running agile teams, and projects.

I spend a lot of time reading and formulating ideas about this subject, and as my knowledge has increased over the last few years, I have been able to become less able to justify in words why my advice is good advice. It makes me (and my team) feel good, and it enables us to deliver.

So I'm going to start keeping my musings on a more regular basis, so that when someone does ask me to write down my train of thought on my ideas, I can just point them to this blog!!

Open Sessions

The open sessions enabled QCon attendees to set the agenda. The board contained time slot for which participants wrote a meeting they want to facilitate.
I chose to facilitate a meeting on "What to do with what we've learned, when we get home." A few attendees turned up and we use a method for making a decision as a team.
It was soon realised that the things that each person had learned, was individually important to them, but as we'd come to this conclusion together, this was fine.

For me, its about being patient, and allowing change to resonate, at its own pace through the business. SO my big learning, in terms of change, is to be patient. Now I just have to put it into practice !!!

SOoooo now I'm on the train on the way back, a few things bouncing round in my head. I'll make a plan I think during my recuperation about how I can put some things I have learned into action.

In the words of whoever it was that said it, "its been emotional."

Thanks to all.

Herding Racehorses, Racing Sheep - Dave Thomas

Dave Thomas, ruby genius, founder of the pragmatic programmers range of books, speaks about the importance of recognising the knowledge in yourself and your team.

Using the Dreyfus Model as a method of understanding Dave spoke in what can only be described as a brilliant, inspiring pantomime, the levels and habits of people with different amounts of knowledge.

The importance of setting goals, rules and boundaries for novices, the criticality of enabling intuition in Experts by not questioning why, but just trusting them.

As good as he is in print. Off to another one.......:-)