Mark Needham

On Wednesday evening my colleague Mike Wagg and I presented a variation of a talk I originally presented at Developer Developer Developer 8 titled ‘Mixing functional and object oriented approaches to programming in C#’ to the London .NET User Group at Skillsmatter.

The slides from the talk are below and there is a video of the talk on the Skillsmatter website.

These were some of the lessons I learned from this version of the talk:

• I recently spent a bit of time flicking through Scott Berkun’s ‘Confessions of a Public Speaker‘ and one of the suggestions he has is that people aren’t interested in how you got to your current opinion – they’re more interested in hearing what you’ve got to say.

  While I think a story based approach is more fun to watch, in the original version of this talk I felt I spent too much time detailing where ideas had come from even though that information didn’t add much value to the talk. We cut that out this time and I think it worked better as a result.

• I haven’t done a paired talk before but I found it a much more enjoyable experience than when I just presented on my own.

  Mike took the role of the object oriented guy interested in how functional can work in that context while I took the role of the guy who’s really interested in functional programming and wants to put it into C# code whenever possible.

  It was quite fun playing those roles especially when I was showing some of the slides on passing functions around and continuation passing style as the code became more and more difficult to understand.

• Zi suggested that it would work better next time if we paused at the end of slides with code on so the audience would have time to let it soak in and ensure they understood what was going on so this is something to try for next time.
• Mike and I were unsure whether the introduction where he covered how C# had evolved through the different versions would be useful but this was a part of the talk which got a lot of positive feedback and several people mentioned that they had done something similar at their work place when explaining LINQ to colleagues.
• Liz Martin pointed out that the talk was effectively about knowing your language and how to use it an effective way without causing yourself too much pain. I think this is probably a fair summary and if taken further perhaps explains how we end up with different idiomatic patterns of use in each language.
• Next time I’d look to explain some of the more complicated functional code a bit better and perhaps build up to it with some simpler examples. This time it was more to demonstrate how impossible the code can become if you take a functional approach to the extreme in C#.

  It also seems like there is some overlap with some of the patterns of Domain Driven Design and how the fit in with these two approaches to programming.

We had a discussion afterwards about some resources for learning functional programming. These were some of the things mentioned and resources I find useful:

• Real World Functional Programming – I started learning about F# from this book and it provides a nice introduction to functional programming concepts with examples side by side in C# and F#.
• Functional Programming Fundamentals – Erik Meijer’s series of lectures on functional programming based mainly around Haskell recorded for Microsoft’s Channel 9. I’ve only watched a couple of these so far but they seem to provide a decent introduction.
• Planet F# – a syndicator with posts by various people about what they’re doing with F#.
• Structure and Interpretation of Computer Programs – a computer science introductory text used in introductory courses at MIT. It’s not only about functional programming but there are relevant sections.

I recently came across a really interesting article written by Ralph Stayer titled ‘How I Learned to Let My Workers Lead‘ about his experiences at Johnsonville Foods.

It describes the way that he was able to help change the company culture from one where he made all the decisions and took all responsibility to one where everyone in the company was involved in decision making, resulting in a more successful organisation.

One of the interesting early parts of the article talks about how the problems created are entirely the fault of the author who is the CEO of the company:

I started by searching for a book that would tell me how to get people to care about their jobs and their company.

And yet, I told myself, why not? I had made the company so I could fix it. This was an insight filled with pitfalls but it was an insight: the fault was not someone else’s, the fault was mine.

It reminds me a lot of the following quote which is attributed to Dr Paul Batalden (although apparently also to several others!) who was influenced by W. Edwards Deming.

“Every system is perfectly designed to get the results it gets.”

I think this is something which is very easy to forget and we probably end up placing too much emphasis on the individual and forget the context in which they are operating.

For example, it’s much easier to perform well working in a team in an organisation which really buys into the agile/lean way of doing things than it is in one where a strong culture of hierarchy, a tendency to favour the big up front approach and a culture where politics and politics and bureaucracy are rife.

Another interesting observation is that his employees were so used to him solving their problems that even when given permission to solve problems they struggled to do so:

They were good soldiers, and they did their best, but I had trained them to expect me to solve their problems. I had nurtured their inability by expecting them to be incapable; now they met my expectations with an inability to make decisions unless they knew which decisions I wanted them to make.

I wonder if this explains why when you try to work in an agile way with a team which is used to a strict hierarchy they will initially find it difficult to challenge any decisions and solve their own problems.

This links well with another thing I noticed as I was reading the article - it takes a long time to change a system. The article covers a period of around 5 years and still there is more that can be done to make the organisation even better.

Another good insight is that we don’t need to have a grand plan in order to initiate change – we can just do it:

These system changes taught me two more valuable lessons. First, just start. Don’t wait until you have all the answers…if I had waited until I had all the answers, I’d still be waiting. A grand plan was impossible…I just knew I had to change something in order to alter expectations and begin moving toward my goal.

This links closely to the idea of asking for forgiveness rather than getting permission which I’ve had drilled into me by my more experienced colleagues over the years! I’m sure there are situations in which that advice doesn’t apply but the majority of the time it seems like a pretty good mantra to follow and encourages you to be more active and try and make something good happen.

There is a tendency when coaching that as soon as someone isn’t doing something as well as you would/think you would to immediately take back control of the problem which the author identifies:

I wanted coordinators who could build problem-solving capacities in others rather than solve their problems for them…I took every opportunity to stress the need for coaching skills…whenever someone became a coordinator, I made sure word got around that the promotion was for demonstrated abilities as a teacher, coach, and facilitator.

This new promotion standard sent a new message: to get ahead at Johnsonville, you need a talent for cultivating and encouraging problem solvers and responsibility takers.

The problem with doing that is that you encourage the wrong behaviour but equally we need to ensure that
it is safe to fail otherwise people will be scared to make the wrong decision.

In software we can design this into the system by ensuring that we have tight feedback loops and by automating out the possibility of human error.

Another observation which I imagine will be fairly familiar to anyone working in software development is the following:

In our early enthusiasm, we had played down the technical aspects of our business, encouraging everyone to become a coordinator, even those who were far better suited to technical specialties.
…
A career team recommended that Johnsonville set up dual career tracks — one for specialists and one for coordinators — that would enable both to earn recognition, status, and compensation on the basis of performance alone.

ThoughtWorks seems to do this pretty well compared to a lot of companies where you end up becoming a manager if you are a very strong technician a.k.a The Peter Principle

Stayer ends with some interesting ideas on improving performance in organisations of which the stand out points for me were:

• People want to be great. If they aren’t, it’s because management won’t let them be.
• Learning is a process, not a goal. Each new insight creates a new layer of potential insights.

He also introduced a learning and personal development team to help employees improve themselves which seems like an interesting idea and one I hadn’t thought about before:

The traditional personnel department disappeared and was replaced by a learning and personal development team to help individual employees develop their own Points B and A — their destinations and starting points — and figure out how to use Johnsonville to reach their goals.

The summary of his learnings is perhaps the most insightful though:

I’ve learned that change is the real job of every effective business leader because change is about the present and the future, not about the past. There is no end to change. This story is only an interim report.

This is the idea of continuous improvement that lean thinking encourages us to embrace – it’s all about the journey and not the destination.

Reading this reminded me a lot of the way my colleague Pat Kua works in helping other people in his teams developer their skills and I’m hoping that InfoQ have recorded his talk from QCon London ‘Building the next generation of next leaders‘ which I’m told covers similar ground.

The Poppendieck’s also have an interesting video recorded at Google where they cover the role of leadership in software development.