JRuby with Andrea Provaglio

PBT Group and the Johannesburg Centre for Software Engineering are hosting a JRuby master class led by Andrea Provaglio.  I met Andrea at the Software Architecture Workshop in Arosa, Switzerland this year and I cannot speak more highly of him.  Just check out his web site for details.  It’s not often that we get a chance to have such learned architects and practitioners in South Africa.  Let’s take advantage of this opportunity.  The greater the support, the easier it is for us to pull in heavy hitters in this industry for future events.There is a class scheduled for Johannesburg on 16 January 2008 and Cape Town on 29 January 2008.  Registration is online at the JCSE website.  Just follow the links from the front page.See you there!

*Camp Cape Town

UPDATE:  Massive overload on the work front means a I can’t make this event 😦


The Cape Town Geek Dinner folk have managed to pull off *Camp, an unconference for all things tech-worthy. It’s happening on 8/9 December 2007 in Muizenberg in Cape Town.  I may be doing a bit on SOA 101, and OSGi (depending on demand, I guess).

Geek Dinner Feedback

So I did go after all and it turned out to be a rather interesting event. There was a great turnout of about 60 or 70 people. The venue, The Wild Fig, was great, wine was sponsored by GETWINE (very generous of them), and WiFi hotspot by SkyRove. The talks were well timed, not too long or short, with a good mix of socio-political-technical chatter. The format was perfect: Quick intro to everyone, orders placed, 2 talks, starters, 2 talks, main course, 2 talks, desert, open mic. Just perfect!
Antoine van Gelder did a silent (self-inflicted-ducktape-on-mouth) talk on the One Laptop Per Child project. The point: children are taught to learn in silence, without expression. But expression online cannot be silenced. Very noble cause which I hope will get the time/publicity it deserves amongst the other fundamental challenges (hunger, health, etc) that children and families in Africa face daily. And he brought one of the laptops along for us to play with.

Bryn Divey did a well timed Python-bashes-PHP bit. If you ever liked PHP, you’d wish you didn’t. Very convincing argument against PHP, but I am still not convinced about Python. His delivery and style reminded me a lot of Dan North.

Tania Melnyczuk did one of the best project management flyovers I have seen. Nice to see that she touched on agile methodologies relevance in project management. At least I know one more project manager that I do not have to explain what a user story is and why I need to do a release planning session.

Nick Coyne did a really nice intro of Ruby on Rails and managed to evade the obvious Ruby-is-better-than-Python-is-better-than-Perl-we-all-hate-PHP dissidents. What was great to see was his pitch for having fun again and writing beautiful code. Something I relate to a lot.

Alan Levin spoke about the lack of socio-political endeavour attributed to lack of caring. In this instance, caring about bandwidth costs in South Africa … we all want more bandwidth cheaper but we really do not put our energy to make it happen. Very true. Are social and consumer causes dead in the post-apartheid South Africa? Or is it that only fundamental human rights violations warrant the mass protests of the 1980’s in which I grew up? Sri Sri Ravi Shankar will most likely pose the simple questions: What is your responsiblity and for what are you responsible?

Ian Gilfillan  did a bit on emerging mind games such as Go and Marabaraba (sp?).  He reckons that checkers, chess are dead ever since Deep Blue overpowered the great Gary Kasparov.  It was nice diversion.

The open mic spot was seized by Robin Ronne who chatted about the Ripple project.  I did not get the low down but it was something along the lines of a social network where the trust relationships have credits attached so that you can cut out the evil banks for all your money based transactions.

Neil Blakey-Milner mentioned that he will like to pull together an event in September over a couple of days.  Sounded like an Open Spaces style event even if he did not use those words.

Overall: Interesting event.  Was a bit disappointed initially with the lack of detailed technical content.  Upon reflection, I reckon that the content suited the format.  Highly recommended.

Lean Software Development Webinar

I will be joining Kent Beck and Henrik Kniberg on July 20, 2011 for an SD Times webinar on Lean Software Development.  As usual, Kent has put up a great abstract for the event.  I’m absolutely certain that Kent will set the scene with his usual deep insights, and Henrik  has some amazing “from the trenches” experiential material to share.  Overall, we will explore this concept of waste vs value and how lean influences application development.
Personally, I want to cover what flow and waste mean to me, and examples of the huge piles of waste that I ended up manufacturing or walking into blindly and then struggling to dig myself out at great expense.  If the time allows, I want to weave in some models of flow that work for me and those that contributed to waste.  All of this fits into my rather weak thoughts on designing feedback loops.

 

Two Angles to Sustainable Pace

At the Scrum User Group South Africa meeting last night Marius de Beer did a really good talk about Software Development Practices.  It’s been a long while since I saw anyone attempt to draw so much from such widely spread corners of wisdom.  In one slide Marius mentioned the practice of Sustainable Pace.  Many take the view that this is about cutting back on working overtime and that it supports the principles of energised work, and work-life balance.  Marius did make the same point, and it is correct.
But there is another angle to Sustainable Pace.  As a developer, you need to build a rhythm, or flow.  It’s a cadence that you establish as you are writing code.  It’s a cadence that TDD helps you establish itself.  This cadence is also sustainable pace.  And one thing that kills this cadence and your pace in a flash is a mid-stream meeting.

In the panel discussion afterwards, there was a question at the end regarding ways to reduce the number of meetings which I just glossed over.  If you schedule meetings with developers for only the first hour in the morning, you not only reduce the number of meetings but, also, you don’t destroy the sustainable pace built up from the morning.

So, don’t think about pace as just working 7 hours a day, it’s about what you do in the 7 hours that matters.  Get the rhythm going and be anal about things that can kill your flow mid-stream; especially meetings.

Trust Everything

Trust has popped up in so many of my conversations recently.  It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course.  And I got a one line email that said this.

The entire world lives on trust. Every aspect in life moves with trust.

The more I think about situations in life that will prove this statement false, the more it seems to hold true.  Even in design it holds true.  Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.

It’s true for code too.  If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.

I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up.  Here again, aspects and the classes into which they get woven, need a trust relationship.  It may seem like a stretch to make that statement, but I think it holds true again.

So, how do you gain trust?  I am not sure, but I think you have give up something first.  Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space.  Then, perhaps, they will let you in to their space too.  When ego walls are erected, then trust finds it hard to grow.  By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear.  Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.

In code, trust lies in interfaces and types, not in implementations.  It’s really about trusting the implementation that makes types worthy.  When you trust the type and send it a message and it behaves as expected, then you trust it.  If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type.  You don’t hope that it does behave consistently, you trust that it does!

Trust is tied in with ubuntu too.  You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them.  I think ubuntu coding needs trust as one of it’s values.  It’s already a value in XP, and Scrum, and families.  It needs to be in teams, and organisations, and communities and nations too.

Behaviour Driven Development at Cape Town Geek Dinner

Earlier this year I got to hear about Behaviour Driven Development from Dan North at the Software Architecture Workshop in Arosa, Switzerland.  Since then, I’ve been using BDD to various degrees on various projects, and I have to say that it works for me.A few nights ago, I presented BDD at the July GeekDinner in Cape Town. I had no idea how this approach will be received, but I was quite surprised by the interest and chatter that I had with others after the talk, especially around rbehave. I wonder how the conversation would have turned out had I used JBehave examples instead?The rest of the GeekDinner was, as always, an interesting mix of techie, geeky things. Jonathan Hitchcock has a nice wrap-up of the evening.Download my presentation here (PDF format).

Geek Dinner

A colleague of mine, Anne Botha, gave me a heads up on the Geek Dinner that’s happening in Cape Town on 28 May 2007. It’s been 2 years going on 3 living in Cape Town, so maybe it’s time to join the geek crowd. From the blogs about past dinners, it seems to have a good balance of high quality techie talks and social networking. It will be interesting to see how this compares with the Software Architecture Workshop (convened by Jimmy Nilsson) that I attended in Arosa, Switzerland earlier this year.  Jimmy’s event was over over three or four days as compared to one evening.  I have a feeling that the tech talk at GeekDinner will be of equivalent quality to that at SAW.

Modeling out Loud Deep Dive

For those of you that attended the Modeling out Loud deep dive at the S.Africa Scrum Gathering today, here are some things that I discussed.  It’s in no particular order, and it only makes sense if you attended the session.

  • BDD Stories that are authored outside the team contributes to a hand-off which influences design decisions.
  • Because we understand something does not mean that we know how to design it.
  • Be aware of when you are analysing and when you are designing.
  • Be concrete and abstract late.
  • Use the scenarios to close the loop with product owners, stake holders, etc.
  • Developers should write BDD stories and scenarios.
  • We are less ignorant at the end of the sprint than at the beginning.
  • Use code to close the feedback loop for your story.
  • A story and it’s scenarios can be a representation of your model, just like a picture, UML, test code, production code.
  • Seek out the behavior and express intentions.
  • Use the value statement to explore alternative needs.
  • Product owners should not write BDD stories
  • Recycle stories if there are scenarios that you cannot commit to.
  • Keep out the technical jargon.  The moment you get technical, then the story shifts to an implementation.
  • Evolve and accept that it is ok to change … your story, your scenario, code, anything.
  • Login is not a story

There was a lot more which we all discussed, so feel free to add what you got out of it as a comment for others to grab.

The slide deck which contained the code example is available at http://bit.ly/bhNkvQ.

And lastly, thanks for joining in.  I sincerely appreciate you making the time.

Remember that writing stories is a really difficult thing to learn, because is design is hard.  Persevere.