An interesting visualisation of this blog thanks to Wordle.
Created by Wordle under the Creative Commons licence.
Page 27 of 53
It’s about time I got around to reading the whole Agile Coaching book by Rachel Davies and Liz Sedley. I’ve owned it for at least six months now but has sat with a number of other books that demanded my attention. Fortunately long flights (like back to Australia) give you lots of time to pass with books to read. I’m glad I finally got around to reading it as well. The short version: if you’re interested in what agile coaches do, or if you’re working in an agile team, particularly a leadership role, this book is for you.
When you first open the book, it’s obvious it is a Pragmatic Press book. It jumps straight in with lots of helpful hints for those that want or are currently looking to be an agile coach. It’s broken up into four main areas, with smaller sections revolving around specific agile practices. This also means it’s fairly easy to digest it in smaller pieces (something I probably could have tried) doing the daily commute on the train.
I’ve been fortunate to know Rachel and Liz before and during their book writing. This book really captures the way they work, and great advice in the form of very practical tips for people. I hope that any readers, even without knowing the authors, can tell the wealth of experience both of them bring. I think writing a book on agile coaching is pretty tough. There’s a temptation to focus on the coaching elements alone, or to capture the distilled gotchas around introducing and coaching teams on specific agile practices. This book definitely gets the balance right for those new to coaching agile teams – enough background to the practice with helpful hints (it’s not meant to be a definitive guide on a particular practice) yet framed in a way that would definitely help anyone introducing and encouraging an agile way of working.
There are many other people this book wasn’t written for (more on that later) yet in its form is the best collection of wisdom steeped in experience that I see budding agile coaches benefiting from. I wish I had something like this when I first started out explicitly acting as an agile coach.
Like all the pragmatic books, this one is really easy to read. I think it took me about three hours on the first leg of my flight to finish it. Reading through each of the sections, the authors offer advice and helpful techniques. Many I’ve drawn upon over the years and draw upon often, a few I’ve never used and many that I definitely needed a reminder about using them. In other words, this book contain lots of practical advice that can really work depending on your team and circumstance.
There are many things that I like about this book – including the small personalised stories from both authors, named techniques that will help new coaches remember them better, and a very direct try this and see sort of philosophy that is both pragmatic and living by an agile way of working. I particularly approve of this book being, for the most part, methodology-neutral mentioning a broad spread of practices and principles individual methodologies espouse followed up with many other links to resources, books and references for agile coaches to then follow. I also like the hurdles section (there’s often much more than those listed!) as it hopefully prepares agile coaches for what happens when things don’t go to plan (almost always).
This book definitely fills a need – helping new agile coaches work out where to start with lots of advice that can be applied almost immediately. This book is also a useful reminder of tehcniques and a way of filling in some gaps for agile coaches who might have only experienced some of the agile practices and ways of working.
Like all well focused, practical books, part of what makes it so well focused and good are the areas that it leaves out (something I’m sure will be filled by other books to come). Some of these topics include:
- Setting up an agile coaching gig right (when they perhaps need something broader than agile coaching) – it’s no panacea for all organisational problems and coaching isn’t guaranteed to turn every situation in short timeframes
- Coaching larger teams or large organisations
- Coaching distributed teams
- Helping organisations “go agile”
- Different types of coaching engagements (full time – to part time)
- Working with other agile coaches as a team
I’m glad someone got around to putting this book together – and I’m happier knowing that it’s also written by practitioners grounded in plenty of real world experience and a variety of different contexts. To new coaches, many of these apporaches may seem optimisitc or impossible but I know that they’re all tested and can work in the right circumstances. Read this book as a way of starting off and refining your own agile coaching style – don’t view this as a definititve book to agile coaching, and as the authors put it so well at the end of the book – develop yourself continually.
Just a short note that I’ll be running a workshop for attendees of ACCU2010 this Saturday on understanding how to get the balance right for the testing aspect to build pipelines. We’ll explore the tradeoffs and conscious decisions we should be aware of when putting these into our feedback loops.
Slide deck to come, though it’s a classic me-style, participatory workshop (you learn more by doing!) so slides won’t necessarily make a whole lot of sense by themselves.
How many times have you heard, “We’re not allowed to do that because we need to follow the process”? I had a great example this morning when catching the train out of Kings Cross, dropping into the Carluccio’s chain to pick up the Italian breakfast of a coffee and pastry. Carluccio’s, hidden on the top floor of the St Pancras building, meant I went out of my way to try something different.
The entire shop was quiet, though the main door was open so I walked in. As I entered, the waitress, obviously setting up for the day by putting pastries on the shelf turned to me and said, “We don’t open until 8”. I walked out, empty handed and Carluccio’s lost another customer for the day.
This, by itself, wasn’t so much of a problem, if it wasn’t so rampant all over the world. Just another example of using the “process” to justify not being to able to give the customer what they wanted. This would never have happened with my normal coffee shop, the Farm Collective.
Imagine if, this waitress, explaining how they don’t normally open until 8, but would go out of their way to give me a coffee or, at the least, sell me a pastry for breakfast. Imagine the story I’d be telling now.
How often do you see this in the organisations you work with?
For the first several years at ThoughtWorks I ran an annual personal retrospective looking back at the year gone by. I value celebrating success, making time to reflect and finding ways of continually improving. I ran them for the first few years before collapsing them back into each New Year’s review.
So what has happened six years on?
When I look at first starting at ThoughtWorks, I was just another developer, almost considered a graduate, because I’d only a small amount of real world experience. I worked for ThoughtWorks in Brisbane when we had an office presence, staying there until itchy feet drove me overseas. I could have moved to another Australian capital city, but London ended up much more of a drawcard with so many more opportunities and access to more interesting aspects to life harder to reach in Australia, such as exposure to so many different cultures (music, food, entertainment), personal travel opportunities and the presence of many professional communities.
To this day, I still can’t fathom working with the same company for six years. When I left university, I assumed two years would be the most I would work for in any company. Being lost in one of Oracle’s massive divisions only served to reinforce this view. So what’s changed? Working for a consulting company brings a variety similar to working for many different companies, yet without being tied to any particular one. Each project brings with it plenty of learning opportunities to uncover new contexts, problems and solutions.
Since being based in London, I’ve worked on at least nine projects of great length (a handful of much smaller ones as well). Unlike many of my colleagues, I’ve worked on many projects beyond web technologies (although I’m sure they’re just as fun). Some of these applications integrated with lots of hardware (think RFID readers, barcode printers, scientific equipment), server side REST applications with extremely high performance requirements, lead several development teams, taught fellow colleagues through our lateral training induction programme in India, and coached some very large organisations on appropriately using and understanding agile methods.
In this time, I’ve been fortunate to work with plenty of bright people, both within our own company and at our client, and grown great personal satisfaction by helping others find a passion for learning and taking pride in what they do.
Seeing a variety of situations and working with lots of different people in lots of different roles has lead to significant growth as well. One of the aspects I appreciate the most about ThoughtWorks is the ability to move between roles and develop skills in different areas. Although we’re trying to put a little bit more structure in place, it’s not a place that thinks you have to grow up or get out like many other consultancies.
So the upsides:
Consulting – You develop many experiences and see many environments, giving you better insights into how people behave and how to overcome undesirable behaviour. This first hand experience is invaluable as you apply it to new environments and new clients. Not being independent means I don’t always get choice of what I work on, but I have to be thankful for some of the opportunities over the last six years (partly of what I’ve made it as well).
Growth – Not everyone takes the time to explicitly focus on learning from people around them. This is one of my core principles. Being surrounded by people who think and have great conversations helps me grow. Being put into new situations, slightly beyond my comfort zone increases my confidence and skill set as does dealing with difficult client situations. I can’t thank of many other organisations where I could develop facilitation and coaching skills whilst moving back and forth between hands-on technical work.
Opportunities – I’ve been fortunate to present at a number of conferences over the years. This isn’t an easy path and isn’t one that happens overnight. I’ll be the first to admit, fantastic story telling at the level of Dan North isn’t one of my strong points, but I like to think many people enjoy the experiential workshops I put together. Opportunities are about making the most of what you find yourself in, such as finding yourself, unwillingly, to work in Copenhagen over the summer lead me to finding that lone free booking at Noma, the world’s third best restaurant in the world and enjoying one of the best meals I’ve eaten in my life.
People – ThoughtWorks prides itself about hiring great people. That’s not to say that we always hire perfectly. However I’m glad to be surrounded by other people who take pride in their work, care about learning and passionately applying themselves in whatever they like. I’ve lost count over the years for the number of work colleagues who’ve inspired me to get better at things that I do, and challenged me to better understand the work that I do. I continue to meet more people like this everyday, and am thankful for that dimension.
And the downsides:
Support – Part of not having clearly well defined structures for people as they “advance” make it harder to plan for the right level of support and to time it correctly. I know of some people who moved on by not getting the right support at the right time, and those who failed to get the right sort of support. This isn’t to say that there is no support but it’s a bit random at times. I know that I was particularly let down during my last year although I recognise I have higher tolerances than most.
Travel – I primarily moved across to the UK because of the strong correlation between project work and the office. This has definitely changed over the years. Travel is a necessary part of consulting, yet made harder when traveling greater distances and amplified by the lack of support.
Consulting for clients is different from working in the office – This is definitely one frustrating elements for working for any consulting firm, and I don’t think that ThoughtWorks is any different here, with a different cultural divide between those working in the field and those working in the office. It’s taken me years to see some of the systemic effects, although I’m sure it will be much more before there is something significant I can do about it. Ask me about in person and I’d be happy to run through my current theory.
The key to retrospecting is about learning, so here’s some of the lessons I’ve learned:
Leadership is not about titles – People I talk to see leadership as a role you are explicitly given. I disagree. Leadership implies taking ownership of responsibility and this is true whether or not you are given it or not. It’s not about a role, or a title. It’s about the way you act and the things you say. The leaders I’ve most respected were those that owned the rewards and pitfalls of responsibilities, regardless of it not being an explicit part of their role. The best teams I’ve worked on ensure all responsibilities are taken care of despite the varying titles amongst the people on it.
Everyone is responsible for passing the experiences on – Working for six years for any consultancy is rare, and part of that comes with a certain responsibility of passing on the right culture, and creating the same opportunities for others new to the organisation. Every individual in an organisation should feel the burden of this responsibility. I’m grateful for feedback from co-workers the difference that I make to them everyday. It’s amazingly gratifying to know that I made a positive contribution to people’s growth, even more so when I already hold each one of them in high regard. It’s so gratifying to receive that random text or email from previous co-workers telling me how they’re still doing, or doing things differently as a result of the small investment I made with them.
People move on – People leave companies. That’s a fact of life. The way I look at it, an individual’s needs and wants change more quickly than what an organisation can adopt. I think it’s the organisation’s responsibility to ensure that it does as much as it can to keep people. I think an organisation’s failure is to not to do what it *could* have done to keep them there. This sometimes happens and it’s frustrating. I think we can also get better at keeping in touch with alumni because we definitely aren’t very good with that.
Consulting is a sharp, double edged sword – The change that brings about new experiences and opportunities also often requires travelling or something not quite matching up. Some people in our organisation believe growth will solve these problems, something I also disagree with. I think growth will simply make it much more complex to solve. Having more people on hand simply makes it harder to get the right people to the right place at the right time.
Learning is a lifetime endeavour – I continue to argue how our education systems force us to stop thinking and learning. We focus on teaching (push) over learning (pull) and worse, we focus on absorbing facts instead of thinking. Our environments offer learning opportunities all the time, yet we’re trained to turn a blind eye to them, or to fail to respond to them. Living and breathing agile methods has taught me to learn first, and judge later.
The pace of the conference and the speakers drinks event on Thursday night meant that I missed the first session on the final day. It’s a shame since I think Joe Armstrong would have been good to listen to. I look forward to reading anyone’s report of that session in the blogosphere.
Track: The Concurrency Challenge – Session: Embracing Concurrency at Scale
I really appreciated this speaker for being very pragmatic and conscious about helping people think more explicitly about tradeoffs. He encouraged people to actively think about what solution is most appropriate considering there is always some trade off.
This session resonated another one of those ideas that we use “models” all the time and that models are inherently limited by simplifying things. As the speaker said, “There are many models in science, all of them wrong but some of them useful.” He used time as an example in that there are many ways of looking at it although we have a tendency to want to structure it linearly. “When you admit time is a difficult problem, you will have problems with multiple actors”.
He talked about the ideas that we like convenient mechanisms (such as distributed transactions) because they’re easy to grok and we’re comfortable with those ideas but because they have implicit state, you’re throwing away the value of distributed systems. He went on to talk about how we’re taught about the goodness of ACID properties (particularly around database-centric applications). The alternative he presents is BASE (Basic, Availability, Soft State, Eventual Consistency). There’s apparently a paper on this found here (ACM login required). He referenced Pat Helland’s alternative definition of the acronym, Associative, Commutative, Idempotent and Distributed.
Once again, he emphasises the importance of making the decision on alternatives an explicit one and there is a real tradeoff. This was yet another time someone talked about the CAP theorem that describes three different system properties but you can only guarantee two of them. It’s great as a reminder and highly recommend you read about it as a refresher.
He talks about the world being Eventually Consistent and that “We shouldn’t try to model a world more perfect than it actually is”. He gave a number of examples of using this in practice, and there are ways to make sure that you try to do this. One such example was a Shopping Cart situation where a service should tell the “stock to decrement by 1” instead of “reduce stock from 99 to 98”. I think this is just another example of good OO (tell, don’t ask).
Track: Solution – Session: Scenario Driven Development
Our own Ben Butler Cole ran this session that attracted a huge audience considering it was running in the Solution Track. Ben attempted to help people understand how to use Scenario based testing instead of alternatives such as exhaustive acceptance testing or story based acceptance testing as the regression suite.
I think the audience were largely sceptical but Ben’s views align very similarly to the things I’ve seen on projects, particularly when doing development using stories. One of the misunderstandings about automated testing and stories is that everyone always views stories as additive. For me, you not only have stories that add functionality, you also have stories that change functionality (replace) and stories that also cause functionality to disappear. I tend to think the set of tests also goes hand in hand – if you’re deleting functionality, you should be deleting existing tests as well, or if you’re changing tests, you should be changing existing tests.
I think part of the problem is that stories are kind of fractal in nature and the scenarios that Ben talked about were like at an epic level (maybe even a use case level). What is interesting is how you go about enhancing, maintaining that scenario over time and how the team works around those scenarios – something we unfortunately only got a taster for in the hour.
I heard a lot of people still come away with lots of interesting insights and I would highly recommend everyone go and listen to Ben speak even if it’s just to hear him present. Totally worth it.
Track: The Concurrency Challenge – Session: Modelling Concurrency with Actors in Java – Lessons learned from Erjang
This session was fairly packed out, I guess given the hype of people working with or wanting to work with Erlang. This presenter’s take was interesting because in order to better understand concurrency and Erlang, this guy decided to implement an interpreter on top of the JVM (instead of simply playing around with the language).
The premise behind his talk was that Object Orientation as a paradigm brought with it plenty of productivity and that Actor-based modelling was going to be the thing to give us the next boost. Whilst I admire his premise, I don’t necessarily agree. I don’t think we’re all that good (as an industry) as implementing Object Orientation. I do think things like the JVM have helped raise the abstraction level so that we don’t need to think as much about the lower level memory management (although you have a memory leak in these languages if you’re not careful).
He spent a long time fascinating all the language geeks with his ability to run a simply Erlang program on top of his project, Erjang (Erlang on the JVM) but I really wanted to hear about the lessons learned from programming instead of the technical details of writing an interpreter on the JVM, something he spent a majority of the time on. I don’t think there were very many interesting bits other than designing parts of a system with different ideas. As he said, “Imagine treating parts of system as different actors with different responsibilities?” to which I was thinking, “That’s what good Object Orientation is about. Treating objects playing different roles with the right set of (small) responsibilities”. Nothing new unfortunately.
Track: How do you want to test that? – Session: Performance Testing at the Edge
This session brought a lot of mixed reactions. I agree that the start of it seemed a little bit commercial, talking about their product and the complexities of performance testing. I like discussing the importance of performance testing for applications because it’s one of those things that are often neglected and really not treated very well. This presenter eventually got around to talking about some of these aspects, but like many of the talks still ended up being fairly late in the talk.
I think that this speaker had a lot of great things to say and although much of it was very common sense, didn’t give people an impression about how they could go about doing it well. They had some interesting approaches to monitoring performance such as running it on the same set of dedicated hardware (that wasn’t even a replica of production). This has a trade off of being able to compare results over time which they had some interesting graphs, although it is at a cost of being a proper representative sample of what the software might actually run on.
I found that some of the good things he talked about were similar to the talk that Alistair and I had, although it still sounded like the performance testing team was a predominantly split responsibility that worked orthogonally to the actual development team. It also sounds like there was a big cultural barrier that they have been trying to break down by getting developers to write performance tests and have some more ownership.
The crowd also had a lot of scepticism about convincing a business to invest in the automation of performance testing.
Keynote: Ralph Johnson on Living and working with aging software
The final keynote of the conference kicked off the second day of QCon and presented to us by Ralph Johnson of the Gang of Four fame and whose students contributed to Fowler’s timeless Refactoring book.
Ralph was asking about the number of people who work on systems they created (versus systems that other created) and then argued about the meaning of maintenance programmer arguing for software evolutionists instead. Whilst I agree that no one likes to be labelled a maintenance programmer, changing the name doesn’t really matter.
I like the different perspectives that Ralph brought. He talked about Software Capital as about truly understanding how the software works. Code is one example of this, but actually there are many other things that go into understanding how the software works. He argues that the right sort of documentation (and other artefacts) that helps understand how the software works is another part of Software Capital. As a result, you also need the people around the software to help keep the story alive.
My observations of various organisations also backs up some of the things that he says such as, the larger a system gets, the more likely you need some form of documentation and social structure around the software.
I think a lot of people didn’t like Ralph’s keynote because he talked about refactoring as if it was a new idea and, unfortunately this audience is one that has been exposed to these ideas for a long time.
Track: Beyond Tools and Technologies
I spent the rest of my time on the track that I was speaking at later that day. The first talk of the day was Martin Fowler whose talk, “What are we programming for?” brought the tiny room to a stand still. The room was so full (although it was a small room) that they had to turn people away.
Martin used the talk to highlight the importance of going beyond acting like hired guns and actually thinking about how to use the skills for something good. He asked people to consider the essence of the firms that they work for and whether or not they are benefiting humanity.
Rebecca Parsons, ThoughtWorks’ CTO then talked about the importance of team diversity in her talk, “How to avoid ‘We never even thought of that’!” She talked about the role that diversity played in creating innovations in science and how too much of the “sameness” creates problems with creating too many assumptions. I like the idea of a balancing tradeoffs of not enough diversity leading to problems in teams and too much diversity to the point that the team don’t share the same vocabulary.
After the lunch break, I ran my session, “Building the next generation of Technical Leaders“. I was very happy with the turnout and had some great feedback from the participants. It’s an issues I think is sorely neglected in our industry and has a huge impact on the team effectiveness.
The next session was run by our Director of Social Engagement (Jeff Wishnie) and Merrick Schaefer of Unicef discussing the importance that technology has on developing countries and the significant impact it can have on the lives. They talked about the Rapid FTR project that is being developed to help capture information about children who’ve been separated from their parents with hope of quickly reconnecting them, and at worst, giving them legal status by registering them with an agency such as Unicef.
The final session of the day rounded out with Mick Blowfield with a presentation titled, “IT in a Low Carbon Future“.
Whilst there were many other potentially interesting sessions, I was really happy to hear about the issues that go beyond just Tools and Technology.
I’ve never been to a QCon before and being run by the same organisers of JAOO and the folks behind the ever popular InfoQ, I was looking forward to being both an attendant and presenter. Lasting three conference days and two tutorial days, this conference focuses mainly on being talked at – quite a different experience to the Agile 20xx and the XP 20xx conferences I normally run workshops/talks at. Being focused on the cutting edge and practical technologies side, I can really understand this because it’s hard to target people with the right level of experience.
Talking to most of the attendees, it also attracts a noticeably different side with the majority of people already in architect or senior developer roles with a relatively smaller proportion of people in other ancillary roles such as PMs, testers or BAs.
Feedback that works
I like the feedback note for the conference, asking people tweet, email or talk to people at the conference. I think some of the feedback mechanisms even worked as we saw a lack of caffeine/water during the breaks on the first day change for the other remaining days.
The Keynote
The first day’s keynote started with the evangelical Uncle Bob Martin. He’s a great speaker and channels a lot of opinion towards the crowd wandering back and forth on stage. I saw a version of this at the Agile 2009 conference. I’m glad he adjusted it somewhat more appropriately for this conference. He talked about some good principles that should be followed after a few bumpy technical glitches. He is all about the drama (which I guess is part and parcel of a keynote) such as showing us a video that scrolled through a single java class for something like two to three minutes backed up by a song from the movie from 2001 (thanks Ola!) that almost sounded like the flight of the bumblebee. The point of this showmanship was to demonstrate how we can sense bad code visually without even looking at the specifics. He went through a number of his mantras such as “The Boy Scout” rule, leaving things better than how you found them, or that functions should be no more than four or five lines long.
Whilst I don’t think I learned anything new, Uncle Bob Martin was entertaining and had good things to say, despite how preacher-like he comes across.
Track: Architecture’s You’ve Always Wondered About – Session: BWin – P5 a future proof poker platform
The rest of the day was split into six different tracks. I went to the first of these and was truly disappointed. The two presenters came from BWin, apparently one of the largest poker and gaming sites in Europe. They spent half an hour talking about their problems of performance (many of the -iliites) and where the history of their application came from. They even had to include a three minute video from their marketing folks. They finally flashed up a screenshot of their architecture diagram which I think everyone had come to hear about it. Unfortunately they moved onto the next screen very quickly and said that they couldn’t actually talk about their architecture. How disappointing! Indeed this might have been an “Architecture You’ve Always Wondered About”, and after this session was one to still, indeed, wonder about it.
They proceeded to pick a single example about two processes that concurrently wrote and read from the same database table and their architectural change simply transitioning it to a disk persistent queue and the reporting service reading from that queue and writing to its own database. Neither very profound, or a very interesting tidbit that failed to give the audience any more insight into any interesting part of how they architected their system.
I found it interesting they spent a long time (something like 250 man years) rewriting this version of their architecture so I asked the question about how they went about moving from their old to their new platform at which they pretty much described a big bang approach – neither iterative or incremental. Pretty disappointing.
My lesson learned from this: Regardless of how pretty your slides are, make sure your abstract matches what you’re going to actually talk about.
Track: Dev and Ops: A Single Team – Session: Devs and Ops Cooperation when the Worst Happens
My next session was much more fulfilling with Michale Nygard (author of Release It) describing some of the stories that were the basis for the book but wouldn’t have been publishable. Michael is really down to earth and happy to chat about many of the details behind the book. It’s really obvious that he is also a very pragmatic person, understanding that models are just that and recommending people look into the details because there is often something much more complex underneath.
Many of the things that Michael talked about also resonated very strongly with ideas that I’ve seen on applications. Many of them included focusing on ensuring documentation artefacts should be tested by those who will consume them. As he put it, “UML is virtually useless to the deployment and operations team”. Other gems included, “From a high enough view, everything starts to look the same”
His stories also reinforced the importance of having a ubiquitous language will all members of the company in the shared domain. One of his most successful rescue missions dealing with a production problem only worked because the architect (on the dev side) and Michael (on the ops side) understood enough to really communicate the real problems. Michael also kept (understandably) hammering home the point of lack of information on both sides really hurts the problem solving process.
A lot of Michael’s stories also described their successes working around the existing (organisational) systems in order to deal with the problems at hand. To me, this was just another great example of organisations that structure themselves for efficiency over effectiveness.
I like the way that Michael finished off his talk as well, focusing on the fact that you’re not just trying to build software, that you need to care about the organisation (and I would also argue, the systems and procedures in that organisation) that support the software. Design them for effectiveness, not efficiency.
Architectures you’ve always wondered about: Facebook
The next session I attended was by Aditya Agarwal (one of the engineering directors of Facebook). He shared some great insights and lessons learned into what things Facebook did that got them to where they were. Admittedly they had some strange choices like writing something that converted PHP into compiled C++ and using MySQL is a very “reliable bitstore”.
They have a lot of great things to say, like being very proud of the low number of engineers ratio to actual users. Like Alistair, I’m puzzled why they’re secretive of the exact number of their employees.
Aditya has some good things to say and although he means well, I don’t support everything that he says. it’s obvious a lot of what he says is based on a start up culture. Things like, “don’t worry about it until it becomes a problem” encourages the recklessness we see in many software companies. Same thing about the choice of programming language such as “every programming language will have problems at our scale”.
On the plus side, I was pleased to hear them encouraging the innovative engineering culture that I don’t see in many organisations.
Track: Non relational DBs and Web Oriented Data – Session: Social networks and the richness of data: getting it done with
After going through my notes the most interesting tidbit was about using a partitioning mechanism to deal with data updates based on the number of connections. There was plenty of buzzwords (both internal and external) that I think I had a hard time fitting it all together. Some things I’m going to look at include:
- Bit versus bloom filters – Not familiar with this term or how to use it.
- Tools – RESTeasy (I now see it’s a JBoss project). Redis and Voldemort – something they used heavily all over the place.
That’s about all I got out of this session though I’m not sure if it was about the lack of familiarity with the tools, or the excessive use of acronyms and unfamiliar terms or just plain tiredness.
Track: Functional Programming – Session: Demystifying Monads
Josh Graham did a great job stepping into fill in for his ill wife talking through some of the different ideas behind monads. I haven’t done functional programming since university and I’ll be the first to admit Monad’s are still a mystery to me but I came away with some key learnings.
Firstly, to understand monads properly, you really just have to see several examples in action. There’s a high barrier to entry because it means:
- Learning a new language
- Learning a new development environment
- Playing with plenty of examples
When I find some time, I’ll do those. In the meantime, I understand a bit more about the properties of a monad, and that they can be a powerful abstraction for functional languages.
Final keynote – Dan Ingalls: Forty Years of Fun with Computers
For being so late in the day, this was a very entertaining keynote. Just like any modern day small talk person, this entire demonstration took place in the Squeak development environment. Dan demonstrated some interesting and interactive elements.
I had a few key takeaways including:
- We’re really bad at learning the lessons from the past. Partially because we don’t have enough storytellers and that our generation doesn’t listen very well.
- I’m going to read this article at some point.
When you introduce agile methods to very traditional organisations there’s a side effect most people underestimate. This is, I believe, where the first line in the manifesto is most appropriate:
Individuals and interactions over processes and tools
Traditional organisations are geared for efficiency – keeping individuals busy to the point where you lose overall effectiveness if you ever need to synchronise between parts (which you inevitably do for software these days). Calling a meeting is frowned upon as it takes up lots of time, so out of necessity, most communication occurs over email or IM. As Alistair Cockburn pointed out a long time ago, these are pretty ineffective channels of communication. Relying solely on these types of channels only turns to a build up of frustration as issues go unheard by the right set of ears. In traditional environments, these often turn into build ups set to explode at the most random of moments.
Image from Nic Jacka’s flickr stream under the Creative Commons licence
Perhaps you’ve seen it? Think about when one person hijacks a meeting to highlight an issue (typically important one) not being addressed, or when someone spontaneously shouts at someone for no apparent reason. It might even be as bad as someone having a temper tantrum, literally throwing things across the room. Traditional environments often do not provide mechanisms as outlets for this.
Therefore, when introducing practices such as daily stand ups, planning meetings and retrospectives, the first few times you run them, expect an avalanche of unresolved issues and emotions to ensue. This is fine. Expect this from some of the quieter members as you give them explicit permission to talk about important things that need resolution where traditional structures have not given them that permission to talk about them.
Treat it as you would the opening of a previously shaken soft drink bottle for the first time. You’ll have to be ready to clean up some of the spilt liquid, but you don’t have to worry about picking up broken glass. Now that the bottle’s open, you can work to address the real issue at hand.
I first read “A Community of Thinkers” that Liz, Jean and Eric published late last year. I remember thinking that I felt strongly aligned to it, yet slightly uncomfortable with the exact wording. I toyed around with some words and now, a couple of months later, I am much more comfortable with a slightly abridged version.
It isn’t enough to be a member of a community of thinkers. We can philosophise and think ourselves to death. The world continues to operate in complex ways (yes, as in this, and this sort of complexity). It is not enough to sit back and only think. We need to experiment. We need to apply. We need to practise, then reflect and feed those learnings back into our thinking. This is the essence I respect the most about certain people in the agile community. This is what I want to keep alive. Remind yourself the Do is an important part of PDCA just as much as Check (Reflect) is.
For me, I am not just a member of a community of thinkers. I am a member of a community of thinking practitioners. If you’re not practicing and actively thinking, you’re not part of my community.
A Community of Thinking Practitioners
I am a member of a community of thinking practitioners.
I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
I challenge each community in the software industry to:
- reflect and honor respect the practitioners who make its existence possible;
- provide an excellent experience for its members;
- support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
- exemplify, as a body, the professional and humane behavior of its members;
- engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
- embrace newcomers to the community openly and to celebrate ongoing journeys; and
- thrive on the sustained health of the community and its members through continual practice, reflection and improvement.
I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.
I am a member of a community of thinking practitioners. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.
This one is based upon the original posted on Liz Keogh’s blog here. This licensed under the Share Alike Creative Commons License. All modifications/addendums I made are emphasised in italics.
Recent Comments